playlists cut off tracks that are playing during the first sync after initialization

[simon-weber]

I've noticed the same symptoms as #18 recently. I think the root cause is a bit more subtle, though. Imagine this timeline:

• track A is in a "not heard recently" playlist P
• listen to A
• close chrome before finishing the track, so it's not removed from P
• wait longer than the remaining length of A
• reopen chrome
• track A is still in P since the sync to remove it never happened. listen to the first second of A
• periodic sync happens

This particular timeline causes the bug for both AA and free tiers, but the free tier is more likely to see it since AA could prevent it after the first ~10 seconds through the fix to #18. The general problem is that a playlist may not be synced upon startup, and playlists that remove tracks dynamically risk removing them in the first sync.

Ways I can think to prevent this:

• be more aggressive about detecting currently-playing tracks, which we could potentially do by querying the ui with the content script.
• sync immediately upon starting up, rather than waiting for the first period to elapse. The hope is that this would get P back to the proper state before a user begins playing any tracks.

[simon-weber]

I'm not actually sure that will help much. In my testing, it still takes about 30 seconds for Google to push the changes to the client, giving people plenty of time to start a track.

[simon-weber]

Syncing immediately doesn't always happen as of #91.