Respect disabled audio passthrough codecs - #1377
Conversation
|
Thanks for this, and for the write up. The Media3 crash you found is real and worth chasing and I appreciate you flagging the AI assistance up front. I can't take this change though because of what the flags mean by the time they reach the profile builder. The backends don't pass the user's toggles, they pass In auto, Building the profile through the real resolve path on a stock install with nothing changed in settings: Three realistic cases: So on defaults every desktop, web, phone and Smart TV user would stop direct playing anything with a Dolby or DTS track, and the server would transcode audio on most surround files. The last line is its own problem: "passthrough disabled" is meant to mean decode locally to PCM, not make the server re-encode. It also turns 12 existing tests red, including "a detected 2ch speaker route no longer restricts direct play (the AAC 5.1 transcode bug)", which is a regression we already fixed once. The test this PR removes, I looked at whether scoping the rule to manual mode would be enough and it isn't. Entering manual seeds every unwritten toggle from the same detected profile, so on a machine with no probe you get: which means a Windows user who just opens audio settings and switches to manual would lose all six codecs immediately. The real issue is that one boolean is being asked two different questions. "Can this HDMI chain take the bitstream" and "do not send me this codec at all" are separate intents, and the passthrough toggles only answer the first. Two things I'd rather do instead, and I'm happy for you to take either:
|
|
Thanks for your quick and detailed answer! Here is the mkvinfo in the meantime: and some info i could extract from jellyfin: |
7e9bbd3 to
a6cf7e3
Compare
|
Hi again @RadicalMuffinMan, i implemented the two features you mentioned. In the first commit is the new opt-in flag to "Server transcode unsupported audio". I had issues here understanding the full flow of If we set server transcode to true and enable AC3 passthrough, but disable EAC3 passthrough, this is the resulting startup The second commit is an automatically working error catch adn fallback to audio transcode. After some more indepth analysis of my mkv i together with the ai came to this conclusion: // Some MKVs contain trailing zero padding after the last real
// cluster while the Segment size extends to EOF. Media3 then reads
// 0x00 as an EBML length byte, but it has no leading 1-bit and is
// therefore not a valid varint length mask. A server audio
// transcode rewrites the stream without that malformed tail, so
// allow one retry for this specific parser failure.
PlaybackException.ERROR_CODE_IO_UNSPECIFIED ->
if (errorIsNoValidVarintLengthMaskFound(error)) {
if (audioFallbackAttempted) null else "unsupported_audio"
} else {
null
}With this fallback in place there is a quick reload of the stream if we happen to fall into the varint problem and we try to transcode audio only. Here is a log of that happening Feel free to leave any comments or suggestions. I really want to see this in the main source even if the error might be "rare". It happened with 3 MKVs for me now. |
|
Thanks for turning this around so quickly and for the detailed logs. I checked out the branch and ran The varint fallback in the second commit is good work and I want it. It walks the cause chain, matches only that one parser failure, retries once through Which is why I'd rather not take the first commit. It still keys off the wrong signal just for fewer people now. The comment you put on the new gate has it exactly right: and then the condition drops the codec precisely when passthrough is false. It also sits above the So someone who ticks a box labelled "Server transcode unsupported audio" loses all six and gets a server audio transcode on every surround file while FFmpeg would have decoded all six locally. Nothing in that list is unsupported, and the label promises something else. If you want to keep the setting, the condition that matches its name is My preference is to land the varint commit on its own and leave the profile alone. Your files play either way once the fallback is in |
✅ Build SuccessfulAll platform builds passed. You can download the test artifacts below.
|
2 participants
Summary
Disabling an audio passthrough option did not previously remove that codec from Moonfin's Jellyfin device profile.
This was particularly visible on Android TV with Media3 or mpv, which use software audio decoding. Because those players can decode many codecs locally, Moonfin continued advertising EAC3 as direct-play compatible even when EAC3 passthrough was disabled. Jellyfin therefore selected Direct Play and delivered the original EAC3 bitstream instead of transcoding it to the configured fallback codec.
This is problematic when the downstream HDMI audio chain cannot reliably handle EAC3 passthrough, even though the playback device itself reports that it can decode or pass through EAC3.
The device profile now treats passthrough-disabled codecs as unsupported for direct play. Jellyfin can consequently keep the video stream unchanged while transcoding only the audio stream to the selected fallback codec.
This also avoids a separate Media3 playback problem observed with the affected EAC3 MKV. When Jellyfin sends the original EAC3 stream, Media3 fails during playback with:
Switching to the mpv legacy engine allows the file to start, but EAC3 handling and audio-track switching remain unreliable. The Fire TV itself supports Dolby Digital Plus output, so this is not simply a lack of EAC3 device capability.
This PR does not attempt to fix the Media3 parser or playback error directly. Instead, it ensures that users who disable EAC3 passthrough do not receive the problematic EAC3 stream in the first place. Jellyfin transcodes EAC3 to the configured fallback codec, such as AC3, while leaving the video untouched.
Example:
The change applies consistently to AC3, EAC3, DTS/DCA, and TrueHD/MLP codec variants.
AI Disclaimer
As i dont know the codebase i had help from AI and reviewed the changes it did. Manual testing also confirmed that what AI did works.
Related Issues
Type of Change
Changes Made
Platform
Testing
Test Steps
Screenshots (if applicable)
Not applicable.
Checklist