RadioDroid
RadioDroid copied to clipboard
segler-alex
buffering
when i was drive long distences there allways any places where the connection is lost. so i think a way to buffer 30 sec or a minute is a good chance to fix this.
sry for my english good job, thanks for your great app.
I'm often switching between H+, wi-fi and 4G as I walk around my neighbourhood and town, and so having big skips is quite uncomfortable and worth a longer startup time
I don't think buffering would help. Because we can ask radio's server only for the current chunk, we cannot ask for chunks in advance:
Chunk 1 2 3 ...
|---------------|---------------|---------------|---------------|---------------|
^ xxxxxxxxxxxxxxx ^
| DROPPED |
connection restored
dropped
No matter how much you buffered if your connection dropped for more than chunk length - you will notice it.
However, what we could do is more aggressive reconnect strategy by default. At the moment the defaults are unreasonably conservative.
What you could do at the moment is in Connectivity settings reducing connection and read timeouts and increasing retry timeout.
The music I listen to on the radio is particularly resistant to pitch bending, tempo changes and skips, but not large pauses
However, what we could do is more aggressive reconnect strategy by default. At the moment the defaults are unreasonably conservative.
Would it be possible to maintain multiple concurrent connections?
Would it be possible to maintain multiple concurrent connections?
Maintaining them - I don't see how, issuing multiple connections with periods between them lower than their timeout and keeping the one that connect first - may help. However I think that setting connection/read timeouts to 1 second may be aggressive enough to reconnect in time.