Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't enqueue too many jingles #32

Open
boyska opened this issue Nov 22, 2016 · 1 comment
Open

Don't enqueue too many jingles #32

boyska opened this issue Nov 22, 2016 · 1 comment

Comments

@boyska
Copy link
Owner

boyska commented Nov 22, 2016

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

@boyska boyska modified the milestone: 1.1 Dec 10, 2016
@boyska
Copy link
Owner Author

boyska commented Jul 17, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant