Playing the incorrect audio track despite the option selected being different.

[nathangur]

Describe the bug

I have the Office on my JF server and I watch it across jmp web, jmp windows, android tv app (chromecast), and swiftfin. For only certain episodes (maybe 20-30%) the audio is selected as the default audio, but the audio playing is instead the extras or interview recording. I go and play it on anything other than swiftfin and I encounter zero issues. This has been pretty annoying because it means I can't watch on my phone anymore.

Application version

1.0.1(78)

Where did you install the app from?

App Store

Device information

iPhone 10 somethin

OS version

iOS 16.1

Jellyfin server version

10.8.10

[holow29]

Please provide mediainfo for an episode.

[nathangur]

[LePips]

Don't worry, I've seen this and this still happens even after the refactor. This happens because the media stream index from the server sometimes differs from the available stream indices in VLCKit. I've seen this happen in both direct play and transcodes. I found this to somewhat be expected for transcodes, but I don't need to transcode my media much to really tell. With direct play however this was unexpected and I almost want to just blame VLCKit.

However, I implemented a brief download feature to watch movies while I was traveling. I had downloaded a movie which didn't work previously with this same issue just as a test, but when I went to watch it it had worked. So I don't really know there.

Since we use the stream information defined in the metadata by the server, the first solution would be to instead switch to the stream information as parsed by VLCKit on the media itself. However, the problem is that the titles differ and in events, like this one, where the stream indices between the metadata and media information don't match, the playback information will be incorrect when we send playback events to the server.

[nathangur]

So basically there is no fix.

[LePips]

Unsure, I just haven't investigated much into it.

[StefanVDWeide]

I was wondering if any progress has been made around this. I'm also facing the issue where no matter what audio track I select on TvOS, the first one on the list is picked.

[swadeshp]

It happens with subtitle too. Even when external subtitle is present in the folder, it always prioritize the local subtitles. The video doesn't play in sync with subtitle on official jellyfin app, and swiftfin player which works so well with every other content, struggle with multiple audio. This is the only thing bothering me when I switched to jellyfin from plex.

On the other hand, the official app on android and desktop is such a breeze to use. I wish I knew enough coding to fix this myself.

[ipsi]

I've noticed a similar issue, but not sure it's exactly the same:

With some media files, it will play the default audio and use the default subtitles but won't change the audio or subtitle stream in use until I back out of the video and go back in again. The other quirk is that it'll display the "Scenes" button with the default audio but not the other one. Example Media Info (container: mkv):

When playing, Swiftin (or more likely the AppleTV?) can't play the file as-is, so Jellyfin transcodes it, which is the root cause of the issue.

From a quick look, Jellyfin only asks FFMPEG to include one audio, one video, and one subtitle stream in transcoded files (presumably for maximum compatibility), so trying to switch mid-video does nothing at all. Using the web UI, this is handled by pausing briefly and restarting with a new transcode (very obvious from the log files) - I'm not sure how Swiftfin could/should handle this, but that appears to be the issue for me, at least.

As long as Swiftfin asks Jellyfin for the right audio and subtitle when the video is opened, everything works as expected.

[ShyViolets]

Just writing to said I also have the same issue with subtitles (switching the subtitle language on tvOS doesn’t work - even if restarting the episode or clearing and restarting the app).

[ojsef39]

same issue here

[whompyjaw]

Yup, same issue here...