It would be awesome to have a feature that allows us to manually set a timeout for a response from the server before switching to local playback (e.g. “I need to start receiving data from the server in .75 sec or else switch to local playback”).
A better (yet more complicated to implement, I’d imagine) feature would be a minimum bandwidth and time limit (e.g. “I need to receive 100KB of data in .75 sec or else switch to local playback”)
Problem solved:
My library is currently setup in such a way that Jellyfin has FLACs of all (read: most) of my music and Symfonium is configured to automatically transcode and cache everything locally. I love the ability to stream lossless audio when I’m internet connected and fallback to a lossy transcode when disconnected. However, I’ve noticed that on many occasions the app will try to stream for a number of seconds when the internet connection has been severed before properly reverting to the local transcode.
Brought benefits:
This feature would allow for more sophisticated “stream or fallback” functionality, as it would prevent the user from waiting for playback to start and/or manually toggling to “offline only”. This could also serve as an alternate way to determine if local playback is necessary instead of relying on phone connectivity (as it isn’t always clear if the server is accessible or not).
Ah, my apologies, I wasn’t very clear! I have both mobile internet and wifi set to original quality (as most of the time my mobile connection is stable and fast enough to support lossless streaming). However, occasionally the strength of the network signal (both mobile and wifi) will become very weak and, while i am still technically “connected”, there won’t be enough bandwidth for actual playback.
What i would love is if Symfonium could automatically switch to the local transcode in those situations instead of trying and failing to stream. For me personally, a simple check at the beginning of playback would be more than enough (versus constantly checking during playback of the audio).
Well this is not really possible. You can’t really switch during playback based on BW without a server sending the proper hls playlists this would not work for this use case.
And downloading 100k before start would just delay the playback, but would absolutely not ensure that the BW is still the same 0.1 sec after the download and would still present the same issue.
Right, that may be a bit complicated. Would it at least be possible to set a buffering timeout? The app is aware when buffering is occurring and playback hasn’t started yet. It will eventually switch over to using a locally transcoded file, but this sometimes takes quite a while. I guess the essence of my request is being able to configure this timeout to be much lower (say 1-2 seconds) so that the app will only ever try to buffer for a predictably short time before switching.
Well not really too, because the app does not know yet is there’s an offline version or needs to do something else. And so anyone reaching those timeouts would have errors even if they already had buffered 99%
Just enable playback cache to workaround network issue as expected by the app, or if your issue happens a lot, do not prefer server version on mobile if you often can’t handle it.
