seeking in ended queue somehow corrupts it

[Whuppee]

queue had 1 song in it and had ended (not ephemeral, not looping)

tried seeking to a part of the song to restart. immediate responses and subsequent websockets show an empty queue, and /queue show errors in discord with this output. playhead must still be one, else the length check would prevent this

working on other things, so noting for later

[Ethazeriel]

Changing the return type of getCurrent() to properly include the possibility of returning undefined makes fixing this easy - do we want to special case the seek command to call prev() if getCurrent() returns null? I assume yes and have done so in a9c4068 but my solution isn't particularly elegant - may want to review and modify

[Whuppee]

Note that the command would fail too and we need to look through for other places we've forgotten to check for current.

Per our conversation, I think move the playhead in the same way prev() does without calling it, then seek.

I didn't give it thought at the time, but this started with the Status/Media Bar not knowing there wasn't a current track; the queue ending should probably trigger a web sync. Inelegant, but could compare the playhead to length in the idle event.

Feels intuitive (to me) in the browser, probably not in Discord, but tend towards allowing it. May still want to sync the queue ending for other presentation reasons, but seeking won't feel right under 'Current Track: None'. Unsure if we'd want to report a current track falsely there.

[Ethazeriel]

I don't remember what we discussed about implementation details, but I've made a first attempt in 549e1dc to at least not call play() twice.

have not yet tackled the websyncs.