Websocket channel queue does not fire if new queue is subqueue

[tjhrulz]

OS: Windows 10 Issue Descriptions: If you have a queue that is currently playing let us say that it has songs 1,2,3,4,5 in that order and you switch to a new queue that has songs 1,2,3 in that order the queue payload for any connected websockets will not fire. Going from 1,2,3 -> 1,2,3,4,5 will cause it to fire. Steps to Reproduce: Have 2 playlists one with two songs and one with just one song that is the same as the first song from the playlist with two songs. Have a websocket connection active. Play playlist with 2 songs. Play playlist with 1 song. Most recent queue payload is now not the current payload.

[MarshallOfSound]

Haha, great issue 😆

https://github.com/gmusic-utils/gmusic-ui.js/blob/master/src/QueueNamespace.js#L40

Looks like we just compare the new queue elements against the matching indexed elements in the old queue, if they match we claim no change. We ignore the fact the old queue could have been longer 👍

Will fix for the next release, out of interested what are you using the websocket for? 😄

[tjhrulz]

I write a plugin for rainmeter that allows skins​ to use it to control and get info from GPMDP. While I have you here is there anyway I can get the id or even better yet index of the currently playing song? Right now I am having too string compare the title artist and album of every location in the queue since getCurrentTrack gives a null id and an index of 1.

[MarshallOfSound]

@tjhrulz Unfortunately no, there isn't an easy way to get the ID of the current playing song. In the companion app we also do string comparisons on the queue to determine the ID 👍