[Feature request] Increased streaming cache

[B16WLL]

I use Finamp for music when driving, but don't always have signal for data. I used to use DSub, which had a control to choose how far ahead tracks were cached. I had mine set to 10 tracks, meaning I could be out of coverage for 35-40 minutes without any issue. Is there a way of doing this for Finamp?

Oh , and Android Auto support would be awesome 😉
The official Jellyfin app has that but it sucks.

[Chaphasilor]

I agree that the streaming cache should be increased. It seems like currently it's caching about 30 seconds to one minute, and I frequently encounter interruptions in playback :)

Maybe it would be possible to fully cache the currently playing track as a start, that shouldn't require a huge code change...

[jmshrv]

I'll have a look to see if the caching method can be changed. It may be platform-dependent, as on iOS the whole song is buffered as long as it isn't massive

[seniorm0ment]

I notice caching issues on Android, it's a massive pain when driving on mobile data because of spotty reception. Realistically it'd be nice for it to be able to cache the whole song, plus preload the next one or two. Or at least the option to. I presume we can just set a size limit, I've seen that on other apps.

[BloodyIron]

@jmshrv I was about to start a new thread for this very issue, this is important to me too! I am currently trying out Jellyfin to move away from Subsonic (dsub, music) and Emby (other multimedia). And I quite like Finamp! However, I am "drunk" so to say with the cache settings that dsub offered me, where I could define how many songs ahead are automatically cached, also depending on what kind of network I'm on (wifi/cellular, etc).

It really would be helpful to have these settings so I can just start playing an album and it caches X number of songs immediately. I have to say, I'm REALLYYYY impressed with how much faster Finamp caches songs than dsub, and if this functionality were available in Finamp I probably would automatically have the entire album automatically cached on my phone before I finished putting my shoes on!

Oh and I've been using dsub up until a few weeks ago (when my subsonic premium expired) so this is achievable on hardware/software as new as my "Xcover6 Pro" running Android 13, and OneUI 5.0, updated as of Dec 1 2022 (latest available).

What kind of feasibility are we looking at this being maybe baked into an upcoming update? :)

[jmshrv]

This looks quite easy to do - https://pub.dev/documentation/just_audio/latest/just_audio/AudioLoadConfiguration-class.html

Looks like the buffer size can't be changed on iOS, but as I said it caches quite a lot anyway

[BloodyIron]

@B16WLL the thread for Android Auto is : #24

@jmshrv what kind of a timeline are you anticipating for this to be mainlined/released?

[jmshrv]

I don't really have a timeline for anything, I try not to give time estimates/deadlines since I never actually keep up with them. Finamp is a project that I work on in my time, so the amount of work I put into it can vary significantly.

For this issue specifically, it should be pretty easy to add so I might look at it today or some other time.

[jmshrv]

Looks like the buffer size can't be changed on iOS

Nevermind, https://pub.dev/documentation/just_audio/latest/just_audio/DarwinLoadControl/preferredForwardBufferDuration.html

[jmshrv]

Added in 2938e51 (sometimes I'm inconsistently quick 🙃)

[BloodyIron]

@jmshrv reading through that commit it looks like the buffer setting is only in seconds, and not number of tracks. Maybe I missed it in your code somewhere, but the original ask (which I myself am also interested in) is asking for the ability to auto-cache # of tracks (and/or a setting to just cache the whole queue/album/wtvr).

While I applaud your speedy solution (how dare you! /s ), I would like to hear your response on this aspect please, as this detail is particularly important/useful to me, OP, and likely others.

[jmshrv]

From my (very limited) testing, it looks like it'll cache beyond the current song if you set a really long buffer size. I'd assume at some point it'll get limited by memory, but this should suffice for now.