philippe44
commented
11 months ago I've also verified that for sink with large buffer like what I have with UPnP players (in spotupnp), there is a way to avoid the reload of playing track in any case. With that PR, CSpot will avoid re-queuing the current track if it has not been fully sent to the sink and send a flush otherwise. Then it's possible to have a "smart" sink that, when it receives a flush, knows that the playing track will be re-queued again and just ignores it (discard all data of that trackId). So far it seems to work well (only the sink can now how to flush what needs to be in its buffer an only keep the playing track, cspot cannot guess that).
When the user update the queue, Spotify sends a "replace" frame but one issue is that the current (playing) track is being stopped and reloaded which caused and audible gap, especially on esp32.
This PR tries to address the issue when possible, means that when the 1st track of the reloaded frame is still being played, then no reload is done. Of course, why large buffers, the windows when this can be done will be smaller as TrackPlayer quickly moves to streaming the next track and it becomes virtually impossible to distinguish between tracks.
This probably needs a thorough review
[edit]: I did a first version that poke the TrackPlayer to know what it was playing but it was a bit goofy and I think it's better now where the TrackPlayer simply sets a flag on the track it is downloading and if the preloadedTracks[0] has that flag set, then it simply means that we are still on it. Less changes to different places of the code.