Remove invalid item id usage as media source id

[Kevinjil]

Looking at the change history, it looks like an accidental || item.Id was introduced in 4c31742 to query for the item, perhaps not realising it is later used in the query later on for server-side filtering. This was partially fixed by c54db60 and
ca47635 for Live TV by not setting this variable in that case.

Changes
Only use the fallback item id in the API call

Issues
Fixes #6395

[jellyfin-bot]

Cloudflare Pages deployment

Latest commit	a0f0a0d
Status	✅ Deployed!
Preview URL	https://6d4fc6fb.jellyfin-web.pages.dev
Type	🔀 Preview

View build logs

[Kevinjil]

Marked as draft as I want to test some more scenarios, and perhaps get some insight from the original commit authors as to why it was added.

[viown]

#6166 (comment)

The server returning no streams when mediaSourceId is defined is believed to be a server issue. See #6166 (comment)

[Kevinjil]

#6166 (comment)

The server returning no streams when mediaSourceId is defined is believed to be a server issue. See #6166 (comment)

I believe this is not a server issue: we are querying for streams that match the given media source id, where the id we give is not a media source. An empty result is expected from an API point of view.

[viown]

This should be a case specific to Live TV (which should have been fixed). Omitting item id might cause a regression of the original issue (#3994) due to PlaybackInfo not respecting the provided indices.

We might instead need to check for your scenario here

[github-actions]

ESLint doesn't pass. Please fix all ESLint issues.

[Kevinjil]

This should be a case specific to Live TV (which should have been fixed). Omitting item id might cause a regression of the original issue (#3994) due to PlaybackInfo not respecting the provided indices.

I think that selectively applying the fix might be a better idea than trying to figure out all scenarios where is does not apply. I do not have the data to test the intended scenario but this seems like the solution.

We might instead need to check for your scenario here

I propose to only apply the fix if the tracks are selected.

[Kevinjil]

@viown As I agree with #6166 (comment) that is might be a weird place to do this logic, I kept the needsTrackWorkaround boolean to indicate why we are doing this here.

[viown]

@Kevinjil Could you re-target your branch to release-10-10.z?

[Kevinjil]

@Kevinjil Could you re-target your branch to release-10-10.z?

Done

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dmitrylyzo]

We might instead need to check for your scenario here

There was BaseItemKind.Channel, but Bill suggested removing it.

If Channel is supposed to work as a LiveTV channel, we should just add it to the list. I am not familiar with Channel plugins, so I could be wrong.

[Kevinjil]

We might instead need to check for your scenario here

There was BaseItemKind.Channel, but Bill suggested removing it.

If Channel is supposed to work as a LiveTV channel, we should just add it to the list. I am not familiar with Channel plugins, so I could be wrong.

Adding Channel will not solve the problem, the items provided by the channel themselves are Movie items.