Scheduled playlists: questions, suggestions, and offers.

[caturria]

Hello Azuracast!
I'm Caturria, your newest Github sponsor and a hobbiest who's been fooling around with Azuracast for a couple of years now. First and foremost, I'd like to say bravo to Buster and the other fine people working on this fantastic project.

Now, on to the important stuff: scheduled, sequential playlists.

At present, it's not easy to set up a playlist that will play from start to finish at a scheduled time, without worrying about having it preempted by unexpected content. Even harder is setting up multiple scheduled playlists with overlapping windows and insuring that they play in the intended order. In fact, as far as I can tell, the only way to achieve this at present is through custom Liquidsoap programming.

I would like to propose a simple addition which I believe would open up a world of possibilities in this area: give playlists (or their schedule items) a priority value, similar to what Station Playlist Creator does with its timed events. This is separate from the weights, and serves an entirely different purpose: to allow higher priority playlists to trump lower priority ones. So if multiple scheduled playlists are otherwise eligible to play at the same time, only those with the highest priority are considered.

This opens the door to many common scenarios which currently aren't possible without custom Liquidsoap. For example, a playlist containing a special show needs to play at 6:00, but the regular 6:30 break needs to be able to interrupt it. You'd set the special show to start at 6:00 and have priority 0, and the break to start at 6:30 and have priority 1. The break would interrupt the show at 6:30, and when it was over, the show would automatically continue from where it left off.

This also solves the problem described by the "Side-by-Side Playlists" case study in the docs: configure commercials to play once every five songs at priority 1, and the bumpers once every five songs at priority 0. Bingo, they play side-by-side, no need for custom Liquidsoap programming (and the loss of control that comes with it).

The other issue I've faced with scheduled playlists is that they are trumped by requests. Perhaps we could have a 'trumps requests' option, such that requests can only get played when no scheduled items that trump them are currently eligible?
Can I get some thoughts on this?

I would also like to disclose something important: I am blind. Congrats, by the way, on the accessibility of AzuraCast; it's rock solid. I could help with the implementation of these features on the backend, but due to the blindness, adding it to the frontend is a little beyond my ken (God knows what it'd look like).
Is it possible that someone might be open to colaborating on this with me?

Kind regards,

Jordan (Caturria).

[BusterNeece]

@caturria Hello and thank you for your message!

It's always so nice to hear just how many people in the blind community use and enjoy AzuraCast. I'm really proud of that, and I hope we can continue to deliver an accessible experience for you.

This idea, of assigning a secondary "priority" to playlists to resolve conflicts, is actually something I'm a big fan of. It's easy to implement, easy to code around, less prone to error than other solutions, and it solves a myriad of problems that users have with our existing playlist system.

I think we could even easily solve the "requests trump playlists" problem right out of the box with this. Let's say that by default, all playlists have a priority of zero. We could then set requests as always having a priority of, say, ten. Then if you wanted a playlist to pre-empt playlists, just set its priority above the requests, but any playlist that's in the general rotation (below the requests) would be interrupted by requests.

If you don't mind, would you be so kind as to submit this over at https://features.azuracast.com/, our site for tracking and voting on feature requests? You can just link back to this discussion if you'd like to avoid having to retype everything. That would help us a ton.

Thank you for your support and feedback!

[caturria]

Hi Buster,

Thank you very much, that's been submitted.

I would love to dig into this and see what I can get accomplished. But I'm currently blocked on this issue:
#7365

Seems docker.sh install-dev currently produces a broken install, and I can't say I'm familiar enough with the docker side of things to be competent in trying to sort that out.

Lastly with regards to scheduling playlists, I reported an issue a couple of years ago dealing with the first (or last) items in a sequential, loop once playlist sometimes being skipped. I woke it up a few times but it kept being killed by the stale bot. Unfortunately that bug is still lurking. Hopefully I can catch a break on it once I can get a development environment up and running.

[caturria]

Just a quick update:
I spent some hours today familiarizing myself with the inner workings of the auto DJ, and trying to pin down some sort of explanation for the "first track in sequential playlist gets skipped" bug.
Seriously, has anybody else at all experienced this bug?
I have an external scheduler that's creating and deleting single-use playlists via API every hour. Perhaps there is something about this activity that's getting the system confused somehow?
It's one of those things that just keeps happening as soon as I get busy doing something else, but when I'm laser focused on watching the database like a hawk, I can't seem to catch it in the act! GRRR!
I suspect that it either gets dequeued from the playlist and then never queued up for playback, or it gets queued with an erroneous timestamp_cued value so it never gets picked up when Liquidsoap calls for next song.
I'm also experiencing failures during scheduled playlists wherein Liquidsoap fails to fetch the next song entirely because the query returns 0 results. Liquidsoap tries to fall back to the error file, but it's so busy trying desperately to get a result back from the API that it doesn't have time to actually generate the stream, so listeners and mountpoints get disconnected.
All this to say, I suspect there's some edge case wherein a song is selected but never queued, which manifests as different flavours of chaos depending on when it happens.