Radios are unreliable when network isn't 100% available

[dani]

Describe the bug

I took some days off, traveling in car in France, and saw that Otter's radios are not very reliable in such situation. There are several problems, but all are linked to the fact that network could go down / up while driving outside of big cities.

1. If the network drops while a track is currently being downloaded, the track will be truncated. No matter if network comes back up a few sec later, even if I choose next/previous, the truncated track will stay truncated, otter will not download the missing part

2. As with radios, tracks are "loaded" when needed, if the network goes down at the moment otter tries to load the next one, it'll fail. And instead of trying again later (it should probably try indefinitely, or at least several times, maybe react when network is available again), Otter just stops here. The radio won't load tracks anymore. Sometimes, Otter doesn't even allow to restart the radio when network is up again. I have to kill the app and start it again

3. Tracks are downloaded only 1 at a time. To be more robust to short network drops, it should always try to load the next 3 (or maybe even 5 ?) tracks into the current playlist and download them immediatly, so they are available for local playback. This way we would have a few minutes of locally cached music, and can tolerate network drops, without music being stopped.

All this only happened to me while driving, where network isn't very reliable. But it's probably a common usage, and the current problems make Otter difficult to use.

How to reproduce

1. Start to play a radio
2. Drive in a car or turn your WiFi on/off a few times to simulate short network drops
3. The radio should quickly stop playing

Expected behavior

Otter should try to cache more tracks so it can tolerate short network outages. It should also handle partially downloaded tracks (resume, or restart downloading them)

Environment details

• Device: Tested with a Nokia 8.1 and a Samsung S 9
• Android version: 10
• App version: Latest one, 0.21.2

Logs

Not collected. The app doesn't crash, so I don't know if logs would be relevant

[AMoonRabbit]

I believe point 2 and partly 3 are because of how radios work in Funkwhale. Even the radios on the web player behave by only preloading 1 track ahead. Otter is either mimicking this, or restricted by this. But I have had the same issues.

[SpcCw]

I noticed this behavior as well. The player does seem to detect the radio failure though because it starts showing a toast message saying something like "Radio Error".

However it doesn't stop playing for me but just loops some already played and cached songs. This is perfectly fine (not able to load radio so let's just play what we already have) but would be better if Otter tried to reload radio in this case every now and then until it succeeds. Maybe at the end of each song?

Also it would be great to:

• have some indication that this is radio playing
• if radio mode persisted until turned off, even if stopped and started again - until queue is explicitly replaced. So if I set radio in the morning when going to work and then stop the music (or even close the app) and then start it back in the evening it would still be radio - right now it seems to turn into static queue.

[apognu]

I'll look at all that.

As you said, radio playback is very sensitive to having network connectivity when the last track starts playing (the action of fetching the next radio track is triggered when playback gets to the last item on the list). This should happen whenever you skip to the last track (so in case of error, cliking on previous and then next should try and load a new track).

This is not a solution in itself since it requires human intervention, so I will try and work on the retry process. But I'm wary of behaviors like starting playback again automatically when network comes back up, since it may lead to music playing unexpectedly in awkward situations.

As far as track data itself ("music") is concerned, this is out of my scope, all downloading is handled by ExoPlayer, so there is not much I can do.

@SpcCw : radio mode should be persistent until non-radio playback is initiated, so this is something to be looked at.

[SpcCw]

I am not sure how exactly it happens. If I manually turn off WiFi and mobile data on my phone when radio is playing then it stops with error. However sometimes when I am walking around I notice radio no longer loading new songs but just looping around already downloaded ones yet there is toast message about radio error.

If I start radio, listen to it then pause the player and close the app, it is static queue on the next start.

Maybe it could work like this:

• If "There was an error while trying to play this radio" event happens then Otter sets the next track at the beginning of already played queue (but maybe no earlier than last 30 tracks so it is still cached and repeats are avoided?) and then retries to fetch the next track. If nothing then Otter waits until current track finishes playing and retries. If nothing again then Otter just loops through the cached queue trying again when another track ends. If network never comes up then Otter will loop through what it has.

• If at some point retry is successful and the track is fetched then Otter switches to it after the current one and the normal operation is resumed.

• If the network goes down during download resulting in "This track could not be played" then same logic is applied (switch to earlier tracks, retry while playing them) and the problematic track is removed from queue.

This way even if the network is unreliable music will be playing until the coverage is back. It would be great for certain activities (like running, cycling, working out, etc...) when sudden stop of music and the need to reach for the phone to reset something can really kill the mood :)