Bug / Inconsistent behavior of the Stop command (X)

tomimatko

Active member
I often use X (Insert Stop command) + N (next) during live broadcasting, especially when I want to speak after a song.

I've noticed a few inconsistencies:

1. Inserting a Stop command (X)
Pressing X correctly inserts the Stop command after the selected track. However, if no track is selected, the Stop command is inserted at the end of the playlist instead of immediately after the currently playing track. It would make more sense to insert it after the currently playing track, since placing a Stop command at the end of the playlist serves no practical purpose.

2. Next (N) after a Stop command
With "Remove stop commands after execution" enabled, everything works correctly: pressing N starts the next track.
If "Remove stop commands after execution" is disabled, N starts always the first track if Repeat Playlist is enabled, or does nothing in normal playing mode.
 
if no track is selected, the Stop command is inserted at the end of the playlist instead of immediately after the currently playing track. It would make more sense to insert it after the currently playing track, since placing a Stop command at the end of the playlist serves no practical purpose.
Yes, it would be more logical to have it inserted after the playing track. However if nothing is playing and nothing is selected, inserting at the end is OK as any other position may not be what is expected.

If "Remove stop commands after execution" is disabled, N starts always the first track if Repeat Playlist is enabled, or does nothing in normal playing mode.
This may be because of how the next track is evaluated. I can't tell if it'll be fixed, it depends on how much next track evaluation needs to be changed for this.
 
Hi tomimatko, hi Dmitry,

I tested this on RadioBOSS 7.2.5.0 by hand (keys N and Enter) and read the state through the API (playbackinfo) after each step. Playlist: a track, a stop command behind it, then a note and more tracks.

1. X without a selection (tomimatko’s point 1)
With nothing selected and a track playing, X inserts the stop at the end of the playlist. With a selected track it goes directly behind it. Dmitry’s remark above (behind the playing track would make more sense) matches what I see.

2. N after an executed stop (tomimatko’s point 2)
After the stop has been executed, N always starts the first track of the playlist, not the entry behind the stop. I tried every combination of “Remove stop commands after execution” (on/off) and “Repeat Playlist” (on/off), with a note or a normal track behind the stop, with and without a selection. The result was always the first track. I could not reproduce “does nothing” in normal mode.

3. Enter after an executed stop
Enter starts the selected entry, as expected. RadioBOSS moves the selection to the entry behind the stop by itself when the stop is executed (also when the stop is removed afterwards). I tested this with “Remove stop commands after execution” off and on, and with different selections.

4. What the API reports while stopped (playlistpos is 0)
After an executed stop, NextTrack and NextTrackPreview show the first track of the playlist, which is what N starts, but not what Enter starts. After cmd=stop they show the track that was just stopped.

So RadioBOSS clearly knows which entry would be played next (the selected one), but N and playbackinfo do not use it. As I wrote here earlier (https://www.djsoft.net/community/posts/60777/): a field in <Playback> such as nextplaylistpos, valid in every state, would let external clients show the right “coming up next” title. And N after a stop should probably start the entry behind the stop.

Best regards,
Roland
 
Back
Top