jscholes / accessify-prototype Goto Github PK

Currently, due to the use of HTTP long polling, we receive playback events from Spotify in near-realtime. This allows the GUI to be kept up-to-date when playing, pausing and skipping tracks. Unfortunately, when seeking forward results in a new track being played, the HTTP connection remains open and the GUI doesn't update accordingly.

This isn't a significant problem at the moment, partly because the use case of seeking through the playback queue is a pretty obscure one. However, in the future when we need to be absolutely sure when one song has ended and another one has begun, it will become necessary to find a fix for this.

Notes:

• If the playback queue only contains one track, seeking past the end of it results in the HTTP connection being closed as expected.
• Providing returnon values of "seek" and "position" in the call to /remote/status.json doesn't seem to help.
• Using sleep-based, incremental polling of the remote status causes the Spotify Web Helper to use a lot of CPU, even when using an interval of 1 second. So this isn't a good way to solve this either.

Currently, we allow an unlimited number of playback commands to be executed in succession. This probably isn't a good idea and so far, has flagged up the following problem:

• Spotify seems to have an undocumented skip limit in place for all playback sources. If you skip forward faster than approximately 10 skips per second, skip functionality is temporarily disabled.

Currently, the workflow for dispatching Spotify state change events looks like this:

1. Fetch initial status and update listeners.
2. Open an HTTP long polling session which returns status info when something changes.
3. In the same thread, process the status updates e.g. check whether the current track or playback state has changed and update the listeners accordingly.
4. Loop back round to step 2.

With this workflow in place, a race condition makes it possible to toggle the playback state multiple times before the spotify.EventManager loop has continued round to create a new polling connection, meaning the playback state inside listeners becomes out of date until another playback command has been issued.

The proposed workflow would look like:

1. Fetch initial status and post it to the event consumer queue.
2. Open an HTTP long polling session which returns status info when something changes.
3. When new status information arrives, post it to the consumer queue and loop back around to create a new long polling connection immediately.

Meanwhile, in the event consumer thread:

1. Pull the latest status information from the queue.
2. Process the status updates e.g. check whether the current track or playback state has changed and update the listeners accordingly.
3. Loop back round to step 3.