Sometimes a song that's not particularly appropriate comes up in the queue, or a song that's far too quiet (or sometimes, loud). It would be handy to allow users to skip their own songs, at the cost of forfeiting their queue spot.

I remember seeing that mopidy-gmusic was pulling Top Tracks and we do display a link for it but we error if we try and view them. Currently it is considered an album but we get an error in browse_controller when we try and iterate over its tracks.

We may need to mark it somehow as a fake/pseudo album

Feature: add an opt-in to display a desktop notification using https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API when a new song starts playing.

This option requires that the domain be served over HTTPS.

I would like to use React or possibly Vue.js (which might be easier to use incrementally) to help modernize the frontend. Rails wants to do it's UJS, and I don't yet know how that will play with using other frameworks.

In theory, this should be just a after_save :update_queue in app/models/queue_entry.rb, but I want to test that first.

Feature: Allow users to reorder their queue. At the start we can just add a button to the songs in the queue to make them go to the front of a user's queue. This is technically enough to do full reordering. Later if we want drag-drop reordering or the UI gets too cluttered with buttons in the queue we will probably want #24 to improve the UI/UX

In theory, this already works via a handcrafted POST, but we should probably have an UI option for this. In general, I expect this would be limited to MP3 and YouTube links, but if someone really wants to queue a Google Play Music (or whatever) song by URI, more power to them.

I have a bunch of notes on this, but it would be good to get them into one document that can be followed to set up another instance of Spinner somewhere.

There are a few cases where the next song up will be incorrect:

• When a user "leaves the room"
• When a user who would otherwise be next "enters the room" or queues a song after having an empty queue.
• When the next queue entry is deleted
• When queue entries are re-ordered (when this is supported)

I believe it would be sufficient to have some logic to call for double-checking the next song in the queue and handling it being incorrect. The easiest option would then be to call this code whenever a user's presence changes or a queue entry changes (although it would be nice to batch the latter together, in case an entire queue gets re-ordered). We will also need to handle the deletion of a queue entry if it is the next song: it may not exist in the database to delete by the time the next-song-checking code runs.

It may be worthwhile to cache information about albums in the database. This would also make library browsing a bit better, but it's not clear how much information we'd end up "needlessly" caching.

In order to make this more friendly for being used when hosting social events, I'd be interested in the following:

• Websocket presence of mobile phones. If someone queues a song and then puts their phone away, will their phone keep sending presence heartbeats and keep them in the room? It would be unfortunate if people had to keep looking at their phones to make sure their songs get played. Otherwise allow for a way to disable the presence heartbeat and rely solely on the "mark away/mark present" buttons
• Removing account requirement. Some people will avoid making new accounts for one-off needs; on a spinner instance only exposed on a local network there may be a reasonable way to handle accounts via username and cookies only.
• In a similar vein, spinner doesn't actually use email so we can drop the email client side control during signup.
• Putting songs to the front of your queue. Sometimes people have a song for the moment and want to put a song as being first on their queue. This may be a good time to upgrade the UI for the song list.
• Some of these changes should be set with a config so we need to add some new config options.
• Save the full playlist from the event for people who want to recreate that awesome playlist.

I'll probably be doing most of this work in a new party-mode branch.

When queuing many tracks I noticed that for each song that got added the browser would request the new queue because it was told to via ActionCable (I believe). This behavior should also appear when queuing an album, each song added causes a queue GET. Probably should specialize this case to not call queue_entry.notify_user_of_queue_change until done queuing. Unfortunately, this is currently an :after_save on the model, so it might get a bit gross. Maybe rate limiting or debouncing are easier methods to get better behavior.

This would be a nice feature.

(We should also support adding an album to your library, but since the library features aren't exposed at all yet, that's likely to just be confusing at this time.)

Likely just +1/-1 ratings, vaguely like Turntable.fm used to allow. We could build on this to skip songs with a significant enough number of negative votes, as well.

We want to add additional sources like Spotify and will probably be forced to transition to YouTube Music. Currently to queue a file or YouTube link, the user has to provide a search term in a specific format in order to force Spinner to use a different mopidy backend. We can continue down this route and force a spotify: prefix to search Spotify, but the nicest option would be to automatically search all providers and deduplicate the results. There may be other issues with adding more providers that we might want to document here.

When someone queued an HTML file to play, Spinner got stuck trying to play it, failing, and then starting again. We should investigate why this happens (rather than just skipping it and moving on), and fix that behavior.

The mark around/not listening link is currently not AJAX but probably should be. Also, its not super obvious when you're not listening. We could add a small header element that lets you know you're not listening (could also only appear if you also have stuff in your queue)

Add support for the mopidy-spotify backend.

See also: #22

Right now, when a user queues a song, we add the song to their library as well. We should expose the library information somehow, possibly for easily re-queuing songs, or removing songs from the library. It would also be nice to have a button to add a "now playing" (or recently played) song to the current user's library.