On every track start, PlaybackProbe pulls the entire source FLAC from the Jellyfin server before switching to the transcoded Opus stream

App version

Production

Issue description

On every track start, PlaybackProbe pulls the entire source FLAC from the Jellyfin server before switching to the transcoded Opus stream.

Debug log evidence (one track):

StreamingServer-Proxy: <-- 206 Partial Content stream.flac?static=true (263ms, 28471058-byte body)
MediaMetadataService: FFProbe[Playback/PlaybackProbe] [566ms]: size=28471058 [.../stream.flac?static=true]
SwitchingDataSource: stream.flac?static=true -> stream.ogg?...AudioCodec=opus&AudioBitrate=64000...

Settings: mobile max bitrate 64 kbps, force instant transcoding ON, transcoding engine OFF (no change in behavior).

Device type

Phone

Media provider

Jellyfin

Steps to reproduce

  1. Jellyfin provider, cellular max bitrate 64 kbps, force instant transcoding ON
  2. Disable WiFi, play any FLAC from the start
  3. Observe full source file transferred in addition to the Opus transcode

Additional information

  • Symfonium 14.1.0, OnePlus 13, Android 16
  • Jellyfin 10.11.8 via nginx reverse proxy (proxy_buffering off)
  • Jellyfin reports playback as Transcode → 64 Kbps OGG OPUS (correct)

I searched existing issues first

on

I understand that logs are mandatory

on

Log upload name / description

khynir01

The full file is absolutely not read :wink: It just read a couple of bytes at the start for the probe. But yes even those little bits should not be read, seems there’s still a possible small race here will fix.

Thanks for checking it out, I also have matching nginx logs that do show that the full file might have been sent:

GET /Audio/.../stream.flac?static=true HTTP/1.1 206 28471058 bytes "Lavf/62.12.100"

The main reason I noticed this was that after just starting playback of 3 songs I haven’t played before, my mobile data usage jumped by over 100 MB.

This just shows that the app request the file with open range absolutely not that it have transferred the full file.

It can happen when the file have issues being detected by ffmpeg but this is rare. You can update to the beta version that have more security around that after the ffmpeg 8.1 update.

After further testing on beta, the FLAC probe issue seems fixed, but data usage is still high due to a different cause. AmplitudeService is retrying in a loop for the entire duration of playback because the Opus transcode is served as unknown-length. I uploaded logs as khynir02, not sure if another thread should be started for this?

AmplitudeService: DirectProbe [1839ms]: Error Failed -5: av_read_frame failed :: I/O error [stream.ogg]

This caused ~50 MB of bandwidth usage for a single song.

No need to open another one it’s the same race, it should not even try to get the amplitude as you are on mobile without the option to extract them on mobile.