You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you schedule a long-running event (like a 2h show), then all the short-but-high-frequency events (jingles) will be enqueued after that, which is not so nice.
There should be some way of specifying how that can be avoided.
Here is some strategy:
Priority
Every event can have a priority. If the priority of an event is lower than the priority of the currently playing song, then the event is discarded.
However, to do this we should be able to keep track of informations on the currently playing song, which is not very easy. Currently larigira does not provide such functionality. Implementing it is conceptually not very easy.
Max wait
A more stateless solution could be to check the (remaining) length of the currently playing file. Therefore, an event can have a "maximum waiting time" parameter. So for example if you set a jingle every 15minutes, with max wait = 10minutes, then when you schedule a 2hour show, you will end up with no more than one jingle.
This is very simple, but does not completely fix the issue for long shows that are broken in multiple files (unless we keep track of "groups" of tracks added together, which is not so bad but slightly boring to do).
It also implies that every alarm needs a new form field to specify the max wait parameter. Since we have only 2 alarm forms (and have no plan to add new ones), this is not much of an issue
The text was updated successfully, but these errors were encountered:
One more (not-)solution: allow the logic to be writable with a plugin. So that there is a function that gets called with some context information: information about the audios about to be enqueued, information about the playlist or similar things. This way any sysadmin could code it exactly the way she likes it.
If you schedule a long-running event (like a 2h show), then all the short-but-high-frequency events (jingles) will be enqueued after that, which is not so nice.
There should be some way of specifying how that can be avoided.
Here is some strategy:
Priority
Every event can have a priority. If the priority of an event is lower than the priority of the currently playing song, then the event is discarded.
However, to do this we should be able to keep track of informations on the currently playing song, which is not very easy. Currently larigira does not provide such functionality. Implementing it is conceptually not very easy.
Max wait
A more stateless solution could be to check the (remaining) length of the currently playing file. Therefore, an event can have a "maximum waiting time" parameter. So for example if you set a jingle every 15minutes, with
max wait = 10minutes
, then when you schedule a 2hour show, you will end up with no more than one jingle.This is very simple, but does not completely fix the issue for long shows that are broken in multiple files (unless we keep track of "groups" of tracks added together, which is not so bad but slightly boring to do).
It also implies that every alarm needs a new form field to specify the
max wait
parameter. Since we have only 2 alarm forms (and have no plan to add new ones), this is not much of an issueThe text was updated successfully, but these errors were encountered: