Arbitrary Jellyfin opus albums fail to cast to Nest Mini

Issue description:

Casting from a Jellyfin server to a Google Nest Mini does not work for certain albums seemingly arbitrarily. When it fails there’s a spinning progress bar around the play button that never advances.

I cannot find any pattern corresponding to which albums do or do not play (codec, encoding settings, offline cache status etc.). The submitted logs cover a variety of these combinations both working and not.

Neither “Proxy via Symphonium” not “Prefer offline cached versions” are enabled for the cast device.

The Jellyfin media provider is configured with two connections. The primary being https with a valid LetsEncrypt cert on an IP only accessible from outside my home network (jellyfin.edpe.nz), with the secondary being essentially the same but on an IP only accessible within my home network (lan.jellyfin.edpe.nz).

Logs:

Upload description: edpenz

Additional information:

 

 

Reproduction steps:

 

 

Media provider:

Jellyfin

Screenshots:

     

Well Jellyfin randomly says container not supported and transcode to something that is probably invalid (Jellyfin logs would tell).

Please upload some of the songs not working to https://upload.symfonium.app but check Jellyfin logs and verify that those oga are actually real oga and not some other format with that extension.

ffprobe and opusinfo confirm the format of both are ogg/opus, only with different libavformat versions, but only one is triggering transcode from Jellyfin logs (the song that does not work). Both songs have been submitted via the support upload page.

Triggers transcode, doesn’t play:

[ogg @ 0x55dc5a40df00] 6516 bytes of comment header remain
Input #0, ogg, from '.../x01 - Written In Lightning.oga':
  Duration: 00:05:17.54, start: 0.000000, bitrate: 139 kb/s
  Stream #0:0: Audio: opus, 48000 Hz, stereo, fltp
...
New logical stream (#1, serial: dd5f1a9c): type opus
Encoded with Lavf58.20.100

Plays natively:

[ogg @ 0x55ff24c89f00] 3346 bytes of comment header remain
Input #0, ogg, from '.../x01 - Ichi.oga':
  Duration: 00:02:08.81, start: 0.000000, bitrate: 147 kb/s
  Stream #0:0: Audio: opus, 48000 Hz, stereo, fltp
...
New logical stream (#1, serial: ab839286): type opus
Encoded with Lavf60.10.100

There’s no transcode errors in Jellyfin, but it is done twice in short succession:

[00:35:05] [INF] [21] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: ffmpeg -analyzeduration 200M -probesize 1G  -i file:".../x01 - Written In Lightning.oga" -threads 0 -vn -ab 256000 -ac 2 -acodec libmp3lame -id3v2_version 3 -write_id3v1 1 -y "/config/transcodes/adeb45b43b13e4ffb8b78c2674aaa200.ts"
[00:35:07] [INF] [21] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: ffmpeg -analyzeduration 200M -probesize 1G  -i file:".../x01 - Written In Lightning.oga" -threads 0 -vn -ab 256000 -ac 2 -acodec libmp3lame -id3v2_version 3 -write_id3v1 1 -y "/config/transcodes/60ea40ce6e94859d592ee0ae72c41a23.ts"
[00:35:18] [INF] [43] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: FFmpeg exited with code 0
[00:35:19] [INF] [19] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: FFmpeg exited with code 0
[00:35:47] [INF] [21] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: Deleting partial stream file(s) /config/transcodes/adeb45b43b13e4ffb8b78c2674aaa200.ts
[00:35:47] [INF] [21] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: Deleting partial stream file(s) /config/transcodes/60ea40ce6e94859d592ee0ae72c41a23.ts

Casting to the same device with a different app does not trigger transcoding for either song and both play back fine. Disabling audio transcoding in Jellyfin also makes both songs cast fine via Symfonium.

For now I’ll leave transcoding disabled in Jellyfin as a workaround, but it’s curious why Symfonium is trying and failing to transcode select files.

That’s not how it works :slight_smile: Symfonium sends a question to Jellyfin with the ID of the song and the Chromecast profile. Jellyfin decide and say you can direct play or need to transcode here’s the URL for the transcoded content. And Symfonium send the url to Chromecast that talks directly to Jellyfin.

Symfonium is not really involved in the decision here, except for the profile details it sends for Chromecast.

I don’t know if Jellyfin can fully log the reasons of the decision to transcode but it will give the source of the problem.

For the record the fact that it tries to transcode to a .ts means that it think it’s a video as normally there’s 8 audio profiles it should have selected before that one.

Edit: The different is the mjpeg progressive or baseline, probably the same issue as How do I transcode only FLACs? - #14 by Tolriq where they seem to add the image size to the bitrate.

Did some more digging and found the underlying cause.

Jellyfin had inconsistently detected the container as “ogg” or “oga” across the files, with the ones detected as “oga” triggering the failing transcoding. Refreshing the library with “Search for missing metadata” normalised the container for all files to “ogg” and now they cast fine.

I’m did not find any reason why transcoding does not trigger when casting the same library & files with Yatse instead of Symfonium. The only difference I could see in Jellyfin HTTP debug logs was different values of AutoOpenLiveStream provided to PlaybackInfo queries.

This is like Jellyfin API is including metadata image when calculating bitrate when transcoding. · Issue #14801 · jellyfin/jellyfin · GitHub

It seems they break something with the detection of the images, if the images are progressive ( “Profile”: “Progressive”,) then they think it’s a video and fails their transcode engine.

Yatse should use mostly the same profiles but have more profiles for video as it support video too. I guess it transcode but to something that works better. Can you provide logs from Yatse to see what Jellyfin answers ?