There seems to be a case where the currently-playing track gets requested from the server multiple times within a single session, rather than being fetched once and resumed from what’s already buffered. The result is noticeably higher mobile data use than your bitrate cap would suggest, and it’s the kind of thing that’s easy to miss unless you’re checking server logs.
I first noticed this chasing down unexpectedly high mobile data on my own setup, but the behavior itself looks general enough to be worth others checking too.
What happens: the same transcoded track shows up as several separate stream requests within seconds. Sometimes just twice, but I’ve seen a single track requested 5 times in a row. Neighboring queued tracks each get fetched once, as expected, so it’s specifically the active track that repeats.
I’ve already disabled the obvious culprits:
Force Instant Transcoding: OFF
Pre-caching: OFF
Even with both off, a proper test window still showed roughly 1.9x more requests than unique tracks played (132 stream requests for 69 unique tracks over about 98 minutes on cellular). That’s what makes me think it isn’t purely those two settings.
Log sample (server-side, Navidrome, from an older session). Same track within about 6 seconds:
I also tried to recreate the problem, and the Symfonium logs I’ve attached are from that fresh reproduction attempt, so they should show the client-side view.
Device type
Phone
Media provider
Navidrome
Steps to reproduce
Connect Symfonium to any OpenSubsonic-compatible server with server-side transcoding enabled.
Set a mobile bitrate cap so tracks transcode on cellular.
Disable Force Instant Transcoding and pre-caching, to rule out the obvious sources of extra requests.
Play a queue or album on cellular for an extended session, ideally on a connection that isn’t rock-solid (borderline or fluctuating signal).
On the server side, compare the total number of transcoded stream requests against the number of unique tracks actually played over that window.
Observe whether total stream requests meaningfully exceed unique tracks played, indicating the same track is being re-requested more than once.
Additional information
Question:
With both instant transcoding and pre-caching disabled, what else could cause the current track to be re-requested this often? Could transient network-state changes still be triggering stream restarts even when those settings are off?
Setup:
Symfonium: [version, check Settings > About]
Device / Android: OnePlus [model] / [Android version, check Settings > About phone]
Server: Navidrome (self-hosted on a Debian LXC), connected via OpenSubsonic (not the dedicated Navidrome integration)
Transcoding: opus profile, 128 to 192kbps on mobile
Force Instant Transcoding: OFF
Pre-caching (mobile): OFF
Rolling cache: OFF
This is due to the navidrome change to the new transcoding engine and Symfonium miss reading the media details. It’s was fixed but Google never approved the version.
Thank you, I installed the beta version, and it works better. But there is still some overfetching. I ran through maybe 30 tracks on mobile and followed the logs in Navidrome, where i see that there are still times where the same transcoded file was fetched 3 times. In Navidrome i did also try to disable the Symfonium/Android and only doing transcoding on the Symfonium/lavf which also seemed to help.
You must not change anything server side and configure client side. Do not force transcode or whatever. Else the app can’t detect and will request verifications.
I may have misunderstood, but i turned off the Opus transcoding for my phone on the navidrome side. It’s requesting the transcoded file, but when i check in symfonium it still shows as if its streaming flac. Where before it would say ogg/opus.
I want to note that i didn’t set a max bitrate. I did read another thread and some reddit posts where that just means everything is transcoded. I do think it’s getting transcoded the way before. Its just the overfetching problem.
In Symfonium you set the max bitrate for mobile and it will be used.
This is the only proper way to have a proper transcoding decision that always work. Forced transcoding server side can’t be properly detected, leads to no proper seeks and cache issues.
Okay but i don’t understand that when i then look under the file format when i go to the info about the track. It doesn’t say that the format is ogg/opus? It’s still just flac.
It’s all in the docs if you go to songs details it shows the details of the source song not what’s playing.
Transcoding is dynamic and depends on many factors, if you cast to something that does not support opus like a Sonos device then it will transcode to something else. The now playing screen shows what’s playing.
Okay so i did a test. It seemed to go quite well, almost didn’t use any data. But then there was a giant spike where it requested a song 94 times.. and that was primarily from background activity. The current song that was playing seemed to only do like 10mb ish but then that giant spike came in.
I uploaded the newest logs which is a reproduction of the last event. Not as servere though.
Logs: CharlesLogs3
and here are the navidrome logs. The song i was playing is “oh my god” and that requested as expected but then about half way through the song it started mass requesting the next song “the knife”
Ok thanks, seems you manage to trigger a small race that goes nuts due to Navidrome returning a non stable transcodeparams despite the input and output being the same.
