-Something like the “pre-cache tracks” feature that works perfectly but for the current track
-When starting to listen to a track, the app seems to buffer 25-50% of it and than wait before downloading more, and it is not going to be added to the rolling cache if the user stops the player before the end or skip song.
-Something else i noticed is that if i skip to the middle of the track and than listen to the rest, symfonium is going to add to the rolling cache just the second half of the track.
-I just what to select a track and let the app download the whole transcoded version, no partial buffer, as it is not going to be cached if i don’t listen to the whole track.
-I’m using Navidrome and/or Airsonic-Advance at the moment, both updated to the latest version.
Problem solved:
-avoid the need of smart playlists and simply use the already great rolling-cache feature
-currently playing track not being added to the rolling cache before the end of it
Brought benefits:
-reduce the need for smart playlists just to cache an already playing/played track
-no need to re-transcode the track server-side
-no need to re-download a track that i already downloaded while listening to it
-no need to wait for the smart playlist to do its job
Other application solutions:
Audinaut seems to do this, the app downloads the whole transcoded track to the end
-Something else i noticed is that if i skip to the middle of the track and than listen to the rest, symfonium is going to add to the rolling cache just the second half of the track.
Please open an issue with logs for that one it should not happen.
For the rest this is currently a limitation in ExoPlayer, their cache system still have quite a few bugs with download and playing at the same time.
just to understand right, is ExoPlayer used by symfonium?
isn’t there a way to use the same mechanism used by the app when pre-caching the next track, to cache/fetch the current playing one from the server? or maybe a way to increase the “buffer” for the current track? if/when app manages get the whole transcoded file it should be easy to add it later in the rolling-cache (aren’t whe in that situation when listening to 99% of track? the whole file should be buffered, and i know it is correctly going to end up in the rolling cache now already, as soon as i listen to the whole song)
i trying to think if there is a way to mitigate the problem in some way or another
The only workaround is to start cache before playback but then playback is locked for the duration of caching of the first span, something that can take time and so delay start by a long long time.
ok i think i understand, i have “one” last thing i wanna ask:
what is triggering the app to put the received data in the rolling cache?
if it’s the user listening to 100% of the first track and than going to the next one,
isn’t that possible to do that before the 100% mark?
does Symfonium knows when there is no more data to buffer?
at that point, isn’t it possible to cache what we got (100% transcoded and than buffered on the device) even without listening to the whole track?(possibly at 25-50-70-90% depending on the size of the source).
in short: why wait for the 100% mark before caching?
i’m really trying to understand what’s going on in the background, it’s really interesting
Thanks again
The app have no way to know if the playback cache is fully filed or not and will wait for the end of track to copy to rolling as the option name clearly state The fact that it’s also applied for pre cache is because some people asked for that to easily fill rolling cache by just starting a queue.
You are transcoding and so seek requires restarting the playback and caused the caching issue you had. But without transcoding if you start play then seek near the end, the data in the middle was not pre cached, the rolling cache will trigger the download of the missing parts too.
This is complex solution that have many benefits but unfortunately since it’s deep in ExoPlayer and published by them, it’s hard to workaround some special needs like this one.
With that said I may add an option to force the pre cache of current track with a warning it will vastly delay the playback start.
Great, an simple option to force the pre-cache even with a delay might be good enough when listening to short/normal tracks. Better than nothing at all. and combined with the standard pre-cache, the delayed-play it’s gonna happen only for the first track.
I hope to see the feature in the app soon, me and a friend are sharing a server and really considering buying the app if all works good enough for us.
Amazing job, and again, Thanks
and combined with the standard pre-cache, the delayed-play it’s gonna happen only for the first track.