I love the fact that you can make a playlist that is scheduled to begin at a particular time. Could this feature be extended to events so that if someone has radio boss configured such that the playlists are made in advance, the content could be inserted closest to the estimated start time of that particular event? I just had time compression end an hour at 59:57 and rather than allow the playlist to begin 3 seconds early, it began 4 minutes late. I have scanned all media in advance but its easy for something to come up a bit short unless the length of songs could be changed in fractions of a percent. I hope I've explained my suggestion clearly.
letting events insert playlists to be played at a particular time
- Thread starter derek
- Start date
That still creates the same problem just 3 seconds earlier. The point is that I hit closer to 0 with time compression off than on, and most of the pieces exist that would fix this.
In addition, moving regularly scheduled events earlier in time means that you have to put special events even earlier. Simply replacing scheduled tracks doesn't work because there does not seem to be a window that radio boss examines to determine what should happen if there is a conflict.
Radio-Albena
Member
We sometimes run into the same problem at hourly transitions.
Could a filler before the scheduled event help bridge the remaining time? A selection of station IDs or jingles of different lengths might cover those short gaps, rather than letting another full song start just before the event is due.
For example, if the last song finishes at 11:59:57, a short station ID could fill the gap until the next playlist starts at 12:00:00.
I’m not sure whether RadioBOSS would automatically choose a filler that fits the remaining time, or how it would handle one that is slightly too long. That would need testing, but it might be worth trying.
Could a filler before the scheduled event help bridge the remaining time? A selection of station IDs or jingles of different lengths might cover those short gaps, rather than letting another full song start just before the event is due.
For example, if the last song finishes at 11:59:57, a short station ID could fill the gap until the next playlist starts at 12:00:00.
I’m not sure whether RadioBOSS would automatically choose a filler that fits the remaining time, or how it would handle one that is slightly too long. That would need testing, but it might be worth trying.
That is the Job of sweepers, however, last minute calculations or rapid transitions, among other conditions can actually create this problem. So if a playlist is 10 seconds over the top of the hour, but over the course of the hour crossfades reduce its length such that it ends at 59:57, then we encounter the problem. Having all elements used in a database only lowers the probability of this problem.
Another scenario that can cause this problem is if you are relaying a stream and it ends prematurely, same concept, radioboss cannot scramble for a number of sweepers to fill in the gap, and unless the playlist is cleared some time during the live event, it will simply do the logical thing and play the next item once the live source ends.
Furthermore, with the current system in place, if you have an event configured such that it replaces scheduled tracks, you still have to remember to set the start time of that event even earlier than the start time of the lower priority event so that the replacement can actually happen.
There are other cases where these, and related problems can occur, but I think you get the idea.
Honestly, I don't see a difference between the two situations:
1. Event with start time 12:00:00 but you want to allow starting it 3 seconds earlier, so you set start time to 11:59:57. This is how it's possible now.
2. Add a new option "allow starting event 3 seconds earlier" and leaving Start Time at 12:00:00.
The result will be the same, but option 1) is better because it does not introduce a new option.
When selecting a sweeper, it will try to find the one to fill the required space but as short as possible, e.g., if you have 10 and 50 seconds sweepers, and need to fill 3 seconds, it will take 10-second one.
Exactly my point, and when radioboss does this, which it does quite well, there are times where crossfades make the end of the sweeper occur before the start of the event. If the content generated by an event were inserted at the same time the sweepers were, this would also close that gap and be one less option to add. However, it would change the way events that replace other scheduled events work, because you would need to decide if the sweepers for the original event run to ramp up to an event that replaces it.
Sweepers take into account crossfades - Mix point specifically, but it does a simple calculation not considering the options the next track may have (e.g., Mix Start). To partially compensate for that, it selects a sweeper that is slightly longer than needed. How often do you see this "gap" and how large is it?
Yes, this would complicate things so much, I don't think it will work reliably in real world - events may start in different order, override each other; too many things to consider.
I'm not sure how to quantify it exactly without looking at logs, but the time I've seen it happen will literally see the hour come up 2 to 3 seconds short. That's why moving everything up by 3 seconds doesn't work because the start moves up as well. That's why this system is amazing and frustrating at the same tmie, and why I've requested that the result of triggering an event be added to the playlist at its projected start time.
It seems that a solution could be to make it always select a sweeper that's at least N seconds longer than needed to cover for that?
Perhaps. It was reduce the likelihood of this happening by a significant degree, but it wouldn't help the other scenario I discussed where a live stream would end early and radiobosss could go and play the next event a bit early. If I have a show end at 59:50, and I've got 10 seconds to fill, radio boss would have no time to find the sweeper to fill that gap with. So it would have to play the next song available in the playlist, or if the previous playlist had ended, it would be forced to play the first song in the playlist again. This would be especially frustrating sense radioboss can now make playlists in advance anyway.
But like I said, addressing your point directly, most of the times when hours come up short happens when radio boss is doing time compression to makeup for an hour that would otherwise run a few seconds long, compressing it in to something that then runs a few seconds short.
Why not, if there's a suitable sweeper, it will be inserted.
Do you use Time Stretch?
If the show is live, and its stream ends, I don't see how radio boss would have time to find a sweeper to fill in the gap.
Also, yes I do use time stretch, and that's where the system is too smart for its own good. If you have a lot of shorter elements, the hour comes up a bit short, as I've mentioned before. If the result of the running of an event could be inserted in to the playlist in advance, cued during its respective start time, it doesn't matter if the hour is too short, a bit long, whatever. It would also make radioboss be more reliable when scheduled events replace others temporarily.
I know I keep going on and on about this, but I strongly believe that the benefits justify the time it would take to add this, which I hope wouldn't be long.
I think you can achieve this using the options events offer now:
1. Set the event's Start Time earlier, e.g. 5 seconds or whatever time you find approproate
2. Set "Maximum time to wait in the queue" option to the same value, with Action = Play.
What will happen, for example your intent is to start event at 12:00:00 but if there's a little gap, you're OK to start it up to 5 seconds earlier. So the event is inserted into the playlist at 11:59:55, and it either plays right away, or plays right after the playing track/sweeper ends, or starts playing at 12:00:00 due to waiting option.
1. Set the event's Start Time earlier, e.g. 5 seconds or whatever time you find approproate
2. Set "Maximum time to wait in the queue" option to the same value, with Action = Play.
What will happen, for example your intent is to start event at 12:00:00 but if there's a little gap, you're OK to start it up to 5 seconds earlier. So the event is inserted into the playlist at 11:59:55, and it either plays right away, or plays right after the playing track/sweeper ends, or starts playing at 12:00:00 due to waiting option.
If the main event hasn't ran, how would directing radioboss to play help if its already playing? I think we're close in that maybe all we need is a a checkbox to cue event early if no other events are scheduled at the same time.
There's no "no other events are scheduled" state that is monitored/detected by RadioBOSS. If you have nothing in the playlist at all then the event will start early - that is, on 11:59:55.
What situation my proposed solution doesn't cover?
About adding options/checkboxes - as you can see, the event window already contains plenty of those. So adding anything else must be justified, otherwise, if all proposals were accepted, this window would contain a thousand of options by now
I just watched another example of this at 8 this morning. In this particular case, it had absolutely nothing to do with time compression. There were 17 seconds left before the hour, and no suitable sweeper was available. Yes, a suitable sweeper would have been great, but there wasn't one.
The playlist for the 8:00 event had already been generated at 7:57:02. At 7:59:43, radio boss started another song. The event's content was inserted at 8:00, but then waited behind that song until 8:03:33. So rather than allowing the event to begin 17 seconds early, it began 3 minutes and 33 seconds late.
This is a situation where the five second suggestion wouldn't solve the problem. The song would already be playing before the event was inserted, and the maximum wait option would then interrupt it at 8:00. I would rather have the already generated content follow naturally.
Looking back over the material leading up to this, the raw files totaled about 60 minutes and 29 seconds, but playback moved through them in 59 minutes and 32 seconds. I'm not attributing that difference to time compression. The point is that the file lengths and the time actually occupied in the hour are different, and sometimes there isn't a sweeper available to make up what's left.
That's why I keep coming back to making the generated content available before the event's scheduled time. Radio boss already had the next program ready. I wanted it to use that content when the previous material finished, rather than start another song.
For transparency, I used AI to help gather the timestamps and file durations through the RadioBOSS API and help put this response together. The behavior I'm describing is something I watched happen, and the figures come from RadioBOSS itself.
It had no reason to start that event 17 seconds earlier. It has Start Time and it properly applies it. This would be considered a bug if it did start the events earlier (and in many/all cases this is not the desired behavior).
5 seconds was an example, you can set any other time of course. But it must be your decision, how much time earlier you want to allow an event to run.
