southernfm
Active member
Sometimes we remotely command a studio to load a certain playlist.
We invoke the command as follows in our example:
The playlist is called AUSSIE-OVERNIGHT.m3u8.
If there is already an item in the queue (alt + q) prior to our loading the playlist, a different item in the playlist will take its place in the queue, once the playlist is loaded.
In our example, song number 11 is queued. If we load the command more than once, the queue position of the track jumps. In our case it jumps from song #11 to song #239 (which is a completely different song). It will actually go back and forth between #11 and #239 every time we invoke the load command, both of which are different tracks. If there's more than 1 item queued, the behaviour is the same (e.g. #11 and #12 would jump to #239 and #240, then back to #11 and #12 if we load the playlist again).
Expected behaviour would be for the queue to clear when we've loaded a playlist to override the existing playlist via API, although I think the behaviour is equivilent to an export to player > 'after playing track' in our case.
Additionally, the queue position is where the playlist will begin, if we invoke a play command, so sometimes it could potentially start in position #239 instead of #1. We can get around that by specifying play #1 in the API command, but others may just rely on 'play' which will have the queue jump problem.
We invoke the command as follows in our example:
The playlist is called AUSSIE-OVERNIGHT.m3u8.
If there is already an item in the queue (alt + q) prior to our loading the playlist, a different item in the playlist will take its place in the queue, once the playlist is loaded.
In our example, song number 11 is queued. If we load the command more than once, the queue position of the track jumps. In our case it jumps from song #11 to song #239 (which is a completely different song). It will actually go back and forth between #11 and #239 every time we invoke the load command, both of which are different tracks. If there's more than 1 item queued, the behaviour is the same (e.g. #11 and #12 would jump to #239 and #240, then back to #11 and #12 if we load the playlist again).
Expected behaviour would be for the queue to clear when we've loaded a playlist to override the existing playlist via API, although I think the behaviour is equivilent to an export to player > 'after playing track' in our case.
Additionally, the queue position is where the playlist will begin, if we invoke a play command, so sometimes it could potentially start in position #239 instead of #1. We can get around that by specifying play #1 in the API command, but others may just rely on 'play' which will have the queue jump problem.
