[SOLVED] Playlist jumps back to playing entry after a few seconds when stop scrolling

[Tim Curtis]

MPD sits in an "idle loop" until it detects a change in "something" and then it exits the loop, posts a block of data including the changes and then returns to idle. Moode receives the new data as a json array.

You could analyze the json returned to the front-end to see if it's possible to detect a pattern in whats changing and then see what if anything can be done to deal with it. Just turn on debug logging in System Config and then watch the Browser console for one of the problematic stations.

Btw this is an old issue. There were stations from way back that did this and they were removed from the moode built in station list because of the perf impact of a front end refresh every few seconds :-0

As far as I can tell this a broadcaster problem and the vast majority of stations don't exhibit this issue.

[kurt1970]

@Tim Curtis Couldn't a check be made on the metadata, and act accordingly only if something changed? Or is MPD dealing totally with it, so that we have no chance of interaction?

That's my point. I guess, moOde probably has an idea about what (source type) is currently playing?

[the_bertrum]

I don't use playlists, and if I did I don't think I'd put radio stations on them. I can't really understand what condition makes it useful to have a never-ending stream on a playlist, surely you never get to advance.... (I realise this is MY problem and no one else's)

Having said that, there are stations where the metadata is resent continually with no changes for apparently no reason (ClassicFM does this for no reason other than it is annoying as far as I can tell, not as annoying as the adverts, but my wife likes it so....), but there are other stations where the metadata is frequently updated with different information about the current track so the data changes, but the music playing does not (Klara Continuo for example). That complicates things.

I suppose the questions is, why does the playlist need to scroll when the data changes? I suspect, in the case of a playlist of tracks, it is because the playlist has advanced to a new item so focus shifts to that new item. In the case of the track on a stream changing though, the playlist is still playing the same item so why refocus? The play bar updates with the new metadata, but the playlist is not changed in anyway.
Assuming those musings are correct, should then a change of playlist item be the trigger for scrolling the playlist back to the currently playing position rather than a change in the metadata?

I am of course just thinking aloud here, it matters not to me one way or the other, and I accept that maybe the metadata is the only way either condition can be captured so feel free to ignore my interjection

[kurt1970]

@the_bertrum, @Tim Curtis I use a playlist for radio stations, as there is no such thing in moOde as "Radio presets". Maybe that's the shortcoming?
So, the playlist just groups my favorite radio stations. Acutally nothing to do with having a never ending stream.

[Tim Curtis]

As @kurt1970 mentioned, playlists containing radio stations are useful if you want to be able to have a list of stations to easily pick from for example the Default Playlist.

When a station transmits updated metadata auto-scrolling keeps the item visible in the Queue for a consistent UX. It's only an issue for the handful of badly behaving stations that transmit metadata unnecessarily.

Have a look at these two functions in /var/www/js/playerlib.js

renderPlayqueue()
updateActivePlayqueueItem()

1. if we don't auto-scroll for radio stations then we end up with a separate UX for tracks vs stations.
2. If we add code to avoid auto-scroll for stations that transmit metadata even though the song hasn't changed we end up with "exception code".

Either of these could be done but there needs to be good justification for either changing the UX or adding exception code. Number 1 involves a change to the functions mentioned above. Number 2 involves changes to the back-end code that maintains the MPD idle loop. We would need to check the metadata and keep MPD in its idle loop unless the metadata "actually changed". Something like that.

[the_bertrum]

@the_bertrum, @Tim Curtis  I use a playlist for radio stations, as there is no such thing in moOde as "Radio presets". Maybe that's the shortcoming?
So, the playlist just groups my favorite radio stations. Acutally nothing to do with having a never ending stream.

I suppose my needs in that regard are satisfied well enough with the "favourites" setting.

I also realise I actually do have three playlists and they do have radio stations in them, although they are playlists of one item each and I use them so I can call a radio "preset" from code attached to a button.

One of the things I like most about this Forum is finding out what other people do with moOde, it is endlessly fascinating.

[the_bertrum]

As @kurt1970 mentioned, playlists containing radio stations are useful if you want to be able to have a list of stations to easily pick from for example the Default Playlist.

When a station transmits updated metadata auto-scrolling keeps the item visible in the Queue for a consistent UX. It's only an issue for the handful of badly behaving stations that transmit metadata unnecessarily.

Have a look at these two functions in /var/www/js/playerlib.js

renderPlayqueue()
updateActivePlayqueueItem()

1. if we don't auto-scroll for radio stations then we end up with a separate UX for tracks vs stations.
2. If we add code to avoid auto-scroll for stations that transmit metadata even though the song hasn't changed we end up with "exception code".

Either of these could be done but there needs to be good justification for either changing the UX or adding exception code. Number 1 involves a change to the functions mentioned above. Number 2 involves changes to the back-end code that maintains the MPD idle loop. We would need to check the metadata and keep MPD in its idle loop unless the metadata "actually changed". Something like that.

So the UX here is that the station is analogous to the Album and the metadata is analogous to the track?  Makes sense.

[Tim Curtis]

After a bit of testing with ClassicFM and the station mention by the OP it looks like MPD is emitting the idle timeout event "playlist" which is documented to mean "the queue (i.e. the current playlist) has been modified". The playlist version number is also incremented.

# MPD status
https://mpd.readthedocs.io/en/latest/pro...d-s-status

Maybe someone can look at MPD sources to see what exactly triggers the playlist event.

[kurt1970]

I replaced a Naim NDX streamer by moOde. In the Naim app, you've separate entries for all different sources, like iRadio (vTuner), UPnP, Tidal, etc. Under the iRadio tab, you've your radio presets.
The closest I can get to this with moOde, is to put the radio stations in a playlist.

[Tim Curtis]

I replaced a Naim NDX streamer by moOde. In the Naim app, you've separate entries for all different sources, like iRadio (vTuner), UPnP, Tidal, etc. Under the iRadio tab, you've your radio presets.
The closest I can get to this with moOde, is to put the radio stations in a playlist.

You can also mark stations as "Favorite" in the Edit Station screen and then set "Group by" in Radio Manager to  "Favorites first"

Then when you switch to Radio view the favs will appear at the top.