Azuracast: Changing playlist content on-the-fly

[gammaw]

Hi,

I'm used to adding/removing songs to/from playlists "on-the-fly", i.e., without restarting the stating afterward. It seems to work fine with standard Azuracast playlists but not with advanced (custom Liquidsoap) playlists. Can anybody confirm it?

What happened is that I removed all songs from a playlist (playlist was empty), didn't restart the station, but a previously removed song was started at a scheduled time. Why is that?

Thanks,

Peter

[SlvrEagle23]

@gammaw Advanced playlists go directly through Liquidsoap for their playback, so AzuraCast can't "live-reload" them the same way it can with other playlists that it directly uses to supply the next playing song.

Liquidsoap is supposed to be watching the playlist file for changes. I'll look into whether that's happening correctly or not.

[gammaw]

@SlvrEagle23 FYI: just checked what happens if I delete the song from a playlist without restarting the radio. As a result, when Liquidsoap tries to play the song, it won't find it, logs an error message (see picture) and falls back to the current playlist. This is good behaviour in my opinion but it also shows that Liquidsoap doesn't detect playlist changes.

Is there any chance of an update to make Liquidsoap be aware of playlist changes?

[SlvrEagle23]

@gammaw I think what's causing this problem is the fact that Docker mounted volumes don't "play well" with Liquidsoap's "watch" mode, which normally watches playlists for changes and reloads them if it detects any.

I updated the playlist reload mode to every 1 "round" (every playthrough of the playlist), because this will ensure that playlists can play through the entire shuffled list normally, but still be relatively frequently reloaded by batch changes in the web UI.

[gammaw]

@SlvrEagle23 what does it mean, when will the change on a playlist take effect? I updated to the latest version (after your commit) and I still see the same behaviour. This is what happens:

1. Playlist 'P1' with song 'S1' is running.
2. Playlist 'P2' contains playlist 'S2' and I remove 'S2' from the playlist (I don't delete just remove). I don't restart the radio.
3. Playlist 'P2' is scheduled and it shouldn't start as it's empty but it still starts because of Liquidsoap's memory. As a result, 'S2' will interrupt 'S1' ('P2' is an advanced playlist).

[gammaw]

@SlvrEagle23 just checked again (after updating Azura) and it seems working. We're very happy :)

[gammaw]

@SlvrEagle23 @Vaalyn today I made an important discovery, which fixes a lot of our problems. The discovery is this: deletions from a playlist will not cause LS to reload the playlist but additions will do. So if we change a playlist's content on-the-fly we need to make sure that we first delete, then add. You can also follow this in the LS log (deletions will not trigger any action but additions will).

[Vaalyn]

@gammaw I've checked the code of the Controller that is executed when removing media from a playlist and couldn't see any obvious errors there. When a playlist is effected by the changes in the BatchControllers playlist action it will be added to the $affected_playlists and at the end here the playlists will be written to disk. I've checked what the variable contains when deleting a media file from a playlist and the affected playlist, in my test it was the default playlist, was in there.

I've also checked my playlist .m3u after deleting the media files from the playlist and the changes where saved to the file. The saving itself seems to be successful and the notify command to LS also shows no errors in the logs.

So the application code is not the source of the problem I think.

[gammaw]

@Vaalyn thanks for checking! Did you look into the Liquidsoap logs as well if you see the actions after deletions? I see nothing there. After additions yes.

[Vaalyn]

@gammaw When adding a media file to the playlist:

2019/04/19 18:53:32 [server:3] New client: 192.168.160.7.
2019/04/19 18:53:32 [playlist_default:3] Loading playlist...
2019/04/19 18:53:32 [playlist_default:3] No mime type specified, trying autodetection.
2019/04/19 18:53:32 [playlist_default:3] Playlist treated as format application/x-mpegURL
2019/04/19 18:53:32 [playlist_default:3] Successfully loaded a playlist of 2 tracks.
2019/04/19 18:53:32 [server:3] Client 192.168.160.7 disconnected.
2019/04/19 18:53:33 [playlist_default:3] Loading playlist...
2019/04/19 18:53:33 [playlist_default:3] No mime type specified, trying autodetection.
2019/04/19 18:53:33 [playlist_default:3] Playlist treated as format application/x-mpegURL
2019/04/19 18:53:33 [playlist_default:3] Successfully loaded a playlist of 2 tracks.

When deleting a media file from the playlist:

2019/04/19 18:53:32 [playlist_default:3] Loading playlist...
2019/04/19 18:53:32 [playlist_default:3] No mime type specified, trying autodetection.
2019/04/19 18:53:32 [playlist_default:3] Playlist treated as format application/x-mpegURL
2019/04/19 18:53:32 [playlist_default:3] Successfully loaded a playlist of 2 tracks.
2019/04/19 18:53:32 [server:3] Client 192.168.160.7 disconnected.
2019/04/19 18:53:33 [playlist_default:3] Loading playlist...
2019/04/19 18:53:33 [playlist_default:3] No mime type specified, trying autodetection.
2019/04/19 18:53:33 [playlist_default:3] Playlist treated as format application/x-mpegURL
2019/04/19 18:53:33 [playlist_default:3] Successfully loaded a playlist of 2 tracks.
2019/04/19 18:55:08 [server:3] New client: 192.168.160.7.
2019/04/19 18:55:08 [playlist_default:3] Loading playlist...
2019/04/19 18:55:08 [playlist_default:3] No mime type specified, trying autodetection.
2019/04/19 18:55:08 [playlist_default:3] Playlist treated as format application/x-mpegURL
2019/04/19 18:55:08 [playlist_default:3] Successfully loaded a playlist of 1 tracks.
2019/04/19 18:55:08 [server:3] Client 192.168.160.7 disconnected.
2019/04/19 18:55:08 [playlist_default:3] Loading playlist...
2019/04/19 18:55:08 [playlist_default:3] No mime type specified, trying autodetection.
2019/04/19 18:55:08 [playlist_default:3] Playlist treated as format application/x-mpegURL
2019/04/19 18:55:08 [playlist_default:3] Successfully loaded a playlist of 1 tracks.

[gammaw]

@Vaalyn wow. I clearly don't have it on deletions. Any idea why?

[Vaalyn]

@gammaw not really sure. Let's see if there are any differences. Are you using Docker or bare-metal? Can't remember^^

[gammaw]

@Vaalyn Docker. Can you check one more thing? When I say deletion I simply delete the song from Azura (instead of removing the playlist label). Can you check if it triggers the same thing in Liquidsoap?

[Vaalyn]

@gammaw That may be the difference. I only tested the removing from a playlist not the complete deletion.

[Vaalyn]

@gammaw Yep, deleting a file indeed doesn't do a LS reload. I'm gonna check if I can find out why it's not triggering that.

[Vaalyn]

@gammaw I've checked the code and it's not doing a reload for affected playlists. I'm gonna add that.

[SlvrEagle23]

I merged the commit from @Vaalyn which should help quite a lot with this issue.