search

JayThomason / Tutti

Tutti is a shared music application for the car being made in conjunction with Audi.
3 stars 1 forks source link

Restructure Jam networking to use Jam-specific song IDs #203

Closed hwray closed 10 years ago

hwray commented 10 years ago

Long ago, we were using song hashCodes (essentially artist+album+title) to communicate Jam state changes between phones. When we added the ability to have the same song in the Jam multiple times, we had to move towards an index-based API framework (ex. "move song 2 to index 4," "set song 5 to be currently playing"). However, we're now seeing that this could cause syncing issues when multiple clients take action simultaneously. For example, if the master receives a message to move song 4 to index 2, but what that client thinks is song 4 differs from the Master's song 4 due to a recent change by another client, the wrong song will end up getting rearranged.

I've added a new jamId key to the Jam database, which is essentially the existing song hashCode + a unique iterated counter based on the total number of songs that have been added to the Jam so far (allowing us to distinguish between multiple copies of the same song in the Jam). Now I need to rework our client/server networking to transmit and use these values for setting and moving songs in the Jam.

hwray commented 10 years ago

The Jam ID thing was a patently terrible idea. Instead, I've added a timestamp field to the Jam database. Client and server are now exchanging timestamps with /jam/addSong requests. Need to get timsetamp exchanges and checks going on for /setSong and /moveSong requests.

hwray commented 10 years ago

After a lot of stupid oversights and long one-line bugfixes, this all seems to be working. We're now identifying songs in the Jam using the unique ID of the timestamp at which they were added (on the local phone that actually clicked to add the song).