Scheduler Option

[eddr]

Hello,

I find the current features of the scheduled events great, with a lot of options - however one thing that is missing, is the ability to start a scheduled event if it was missed. If you compare this to Windows own Task Scheduler, the option is highlighted in the screenshot attached.

User case for this:
1. Scheduler is enabled, schedules running as usual - a playlist is scheduled to run at 5:00pm.
2. The 5:00pm schedule runs, and loads the playlist
3. API is used to a) disable scheduler b) switch to line.input
4. Line.input is currently playing but a schedule should run at 8:00pm to load another playlist - this does not happen as scheduler is disabled.
5. API is used to enable scheduler again and at this point, the 'desired' behaviour would be to somehow get back to the schedule which should of happened if line.input was not playing and the scheduler was enabled.

I hope this makes sense and you can see the use for this Essentially being able to switch from the normal schedule to a line input, then back to the schedule again picking up where it should be.

Thanks

 

[djsoft]

With such an option, the results will likely be very hard to predict, especially if a lot of time passed between scheduler off->on, and if many events have this option enabled - the queue of events to start when scheduler turns on can become huge.

You can do it another way: start line input as "Overlay event" with "Set playlist volume" set to zero and keep the scheduler enabled. If there are no other Overlay events in the time period, the playlist will silently change its state while line input is playing.

 

[eddr]

Thanks for the response!

I see your point. Could this be over come by putting in an expiry time? Or only running the last event which didn't run?

The work around method sounds good, but how would the API control the overlay making it stop when desired?

Thanks

 

[djsoft]

I see your point. Could this be over come by putting in an expiry time? Or only running the last event which didn't run?

The huge problem with adding new features is that it's extremely hard to find free space in the event window. The feature has be very useful to make it to the event window

The work around method sounds good, but how would the API control the overlay making it stop when desired

You're right, currently there's no way to control overlay events from the API.

I'm not sure... But I think there could be some sort of totally different solution. Can you please provide more information about your task?

Perhaps, you can run two RadioBOSS'es that use Virtual Sound card as their playback device. One is used to play "Line In" and another runs playlists and events. You then use API to mute ("setvol 0") one instance and un-mute ("setvol 100") another. So you have only one instance playing at one time and this goes to Virtual Sound Card. The third instance (or, better, RadioCaster) uses the Virtual Sound card as Input and broadcasts sound from it.

 

[eddr]

Yes, an over crowded window with too many options is never good, but I'm pretty sure Delphi can do tab controls no?  Then options could be separated out some how?

My aim here is to be able to let the schedules run but move to line.in via API for however long (could be 5 minutes, 2 hours or even a day) and come back to the schedule by the API and carry on as normal. Almost like having the schedule still running populating/clearing/repopulating the playlist but leaving line.in playing OR stopping the scheduler, playing line.in and then carrying on after by enabling the scheduler again but it should then pick up from where it should be according to scheduled (missed) events.

Having 2 RadioBOSSs running & another streaming app running is way too cumbersome  :'( and i could see it confusing my end users.

Looking forward to your thoughts  ;D

Thanks

 

[djsoft]

We avoid tabbing for event window: the point is to keep everything visible when the event window is opened.

The solution with two instances looks good enough to me. It's very easy to setup, it can be implemented with existing features, and you even don't need to start and stop the scheduler from the API - only the setvol commands are used to switch between instances.

Another solution is to implement the feature you request in your script. Before turning off the scheduler and starting line input, get event list via API. The events have the "IntTimeToStart" property - it says how much time(*) is left before event is started - save the list for later use. After you turn off line input and re-enable the scheduler, check through the saved list and start all "missed" events - considering how much time line input was playing: if "IntTimeToStart" was less than that, then start the event (sort the events by IntTimeToStart field to make them start in the right order).

* The "IntTimeToStart" is measured in days: 1 means one day (24 hours), 0.5 (12/24) means 12 hours, 0.041666 (1/24) is 1 hour, 0.013 (20*1/24/60) is 20 minutes and so on.

 

[eddr]

We avoid tabbing for event window: the point is to keep everything visible when the event window is opened.

Fair enough

The solution with two instances looks good enough to me. It's very easy to setup, it can be implemented with existing features, and you even don't need to start and stop the scheduler from the API - only the setvol commands are used to switch between instances. .

It's certainly easy to setup but from a resource point of view and usability for clients, it may be confusing. Also there's the potential (I'm sure it would happen at some point, some how!) for both instances of RadioBOSS to be playing causing a horrible sound!

I know this is the easiest work around and yes it would work - but not practical for me

Another solution is to implement the feature you request in your script. Before turning off the scheduler and starting line input, get event list via API. The events have the "IntTimeToStart" property - it says how much time(*) is left before event is started - save the list for later use. After you turn off line input and re-enable the scheduler, check through the saved list and start all "missed" events - considering how much time line input was playing: if "IntTimeToStart" was less than that, then start the event (sort the events by IntTimeToStart field to make them start in the right order).

* The "IntTimeToStart" is measured in days: 1 means one day (24 hours), 0.5 (12/24) means 12 hours, 0.041666 (1/24) is 1 hour, 0.013 (20*1/24/60) is 20 minutes and so on.

Now this sounds more promising - I will have to do some coding and test this, but does seem like a good way. So getting the event list + schedules are 2 separate new functions in the 5.5 beta API?

If we were to look at this from another angle - we simply need a way to switch to line.input but let the schedule/queue/events happen in the background, almost like the line.input gets priority over the audio if it has been asked to play - maybe like a 'sticky' playlist entry? (If it exists in the playlist, always play it or something similar)?

I really appreciate your input here - exciting times ahead when I can get this working

 

[djsoft]

It's certainly easy to setup but from a resource point of view and usability for clients, it may be confusing. Also there's the potential (I'm sure it would happen at some point, some how!) for both instances of RadioBOSS to be playing causing a horrible sound!

Resources are not a problem - if RadioBOSS window is minimized, then its resource consumption is less that 1% CPU. Sound will not be corrupted, of course So I'd consider this solution for its simplicity.

Now this sounds more promising - I will have to do some coding and test this, but does seem like a good way. So getting the event list + schedules are 2 separate new functions in the 5.5 beta API?

Yes, the commands were added to control the scheduler, please see this post: https://www.djsoft.net/smf/index.php?topic=4651.msg22431#msg22431

If we were to look at this from another angle - we simply need a way to switch to line.input but let the schedule/queue/events happen in the background, almost like the line.input gets priority over the audio if it has been asked to play - maybe like a 'sticky' playlist entry? (If it exists in the playlist, always play it or something similar)?

Something like this is planned for the future, this is for stations that mostly rebroadcast another station, but this should be useful in your case as well.

 

[eddr]

It's certainly easy to setup but from a resource point of view and usability for clients, it may be confusing. Also there's the potential (I'm sure it would happen at some point, some how!) for both instances of RadioBOSS to be playing causing a horrible sound!

Resources are not a problem - if RadioBOSS window is minimized, then its resource consumption is less that 1% CPU. Sound will not be corrupted, of course So I'd consider this solution for its simplicity.

The worry here is about volume levels clashing - there's potential for both to be set at 100% for some reason (manual intervention due to wrong volume being changed as an example).

Also how does this work from a licensing point of view? Does one license allow multiple instances on the same machine?

Now this sounds more promising - I will have to do some coding and test this, but does seem like a good way. So getting the event list + schedules are 2 separate new functions in the 5.5 beta API?

Yes, the commands were added to control the scheduler, please see this post: https://www.djsoft.net/smf/index.php?topic=4651.msg22431#msg22431

Excellent, I'll have a look at this!

If we were to look at this from another angle - we simply need a way to switch to line.input but let the schedule/queue/events happen in the background, almost like the line.input gets priority over the audio if it has been asked to play - maybe like a 'sticky' playlist entry? (If it exists in the playlist, always play it or something similar)?

Something like this is planned for the future, this is for stations that mostly rebroadcast another station, but this should be useful in your case as well.

I'm intrigued Can you offer more detail on this?

 

[djsoft]

The worry here is about volume levels clashing - there's potential for both to be set at 100% for some reason (manual intervention due to wrong volume being changed as an example).

This problem exists for any solution: incorrect manual intervention can ruin anything. Note that you can disable volume slider in the settings.

Also how does this work from a licensing point of view? Does one license allow multiple instances on the same machine?

You can run multiple instances for yourself but you can't offer them for other people.

Something like this is planned for the future, this is for stations that mostly rebroadcast another station, but this should be useful in your case as well.

I'm intrigued Can you offer more detail on this?

Currently no - the feature is still not designed, so I don't know how it will be done

 

[nelson c]

If we were to look at this from another angle - we simply need a way to switch to line.input but let the schedule/queue/events happen in the background, almost like the line.input gets priority over the audio if it has been asked to play - maybe like a 'sticky' playlist entry? (If it exists in the playlist, always play it or something similar)?

Something like this is planned for the future, this is for stations that mostly rebroadcast another station, but this should be useful in your case as well.

Latest update beta can work perfectly with Repeater. (for the filling of sweapers)
However it is good to know that there will be more developments in this line.

Here a software that I think has good ideas for:

http://www.solidynepro.com/indexahtmlp_Audicom8ENG,t.htm

(In Item: iLink -Internet link receiver)

 

[eddr]

Going back to what I want to achieve, I think I may have found a solution but would like to hear your thoughts on this?

Goal: Be able to let the schedules run but move to line.in via API for however long (could be 5 minutes, 2 hours or even a day) and come back to the schedule by the API and carry on as normal. Almost like having the schedule still running populating/clearing/repopulating the playlist but leaving line.in playing OR stopping the scheduler, playing line.in and then carrying on after by enabling the scheduler again but it should then pick up from where it should be according to scheduled (missed) events.

Possible solution: Have Line.in played via API (1. Inserted into playlist at position 1 2. Play position 1 3.Remove track from position 1) and then any schedules for playlists etc have the options 'Remove previous schedule from playlist' + 'Clear playlist' enabled but NOT select 'Run scheduled launch without waiting for current track to finish'. So this would mean while line.in is playing, the playlist in the background will be getting cleared + updated according to schedule. How does this sound? Can you think of any issues with this?

If the above is not a good idea then how about just an option for line.in tracks to say "Do not allow schedule to interfere if playing" - so if line.in is playing, schedules would not effect it - only a manual removal from the playlist or by going to the next/previous track would?

Thanks

 

[djsoft]

Possible solution: Have Line.in played via API (1. Inserted into playlist at position 1 2. Play position 1 3.Remove track from position 1) and then any schedules for playlists etc have the options 'Remove previous schedule from playlist' + 'Clear playlist' enabled but NOT select 'Run scheduled launch without waiting for current track to finish'. So this would mean while line.in is playing, the playlist in the background will be getting cleared + updated according to schedule. How does this sound? Can you think of any issues with this?

Theoretically, it can work. Scheduled events should not start and let LineIn continue playing. But I suggest you to test how it will work, though

If the above is not a good idea then how about just an option for line.in tracks to say "Do not allow schedule to interfere if playing" - so if line.in is playing, schedules would not effect it - only a manual removal from the playlist or by going to the next/previous track would?

The problem here is that it's a very special case and I'm not sure that other users will find this feature useful.

Also, options like "Do not allow schedule to interfere if playing" often lead to adding another counter-option "Run scheduled event no matter what and ignore any non-interfere options"...

PS I'm still sure that using two RadioBOSS instances is the most reliable and easy solution for this. It's easy to setup and it doesn't require adding any features.

Another note, I mentioned it somewhere earlier. In the future, RadioBOSS will have a sort of "relay" player and that will allow you to do what you want to do - but that's planned for RadioBOSS 5.6.

 

[eddr]

Ok I'll have to test my possible solution  ;D

With regards to the suggested options - I see your point, somehow there would have to be an override for the already overridden schedule :-\ then things get confusing!

Having 2 instances of radioboss running is still something I'm considering but I would lose functionality such as track title information, cross fading between the instances (although this could be solved by adjusting the volume in stages but not ideal) and silence detection would be split between the two also. Then there would be the additional cost of radiocast, unless i use something else like edcast or altacast, or a third radioboss.

Hmmm  :-\

 

[djsoft]

Having 2 instances of radioboss running is still something I'm considering but I would lose functionality such as track title information, cross fading between the instances (although this could be solved by adjusting the volume in stages but not ideal)

Crossfading can be done easily. The setvol command allows changing volume over time: setvol 0 1000 - slide volume to zero during 1000 ms (1 second) time interval.

and silence detection would be split between the two also.

Silence detector should have the same settings for both instances.

Then there would be the additional cost of radiocast, unless i use something else like edcast or altacast, or a third radioboss.

You can use one of the instances for broadcasting - select the "Audio source" on Broadcasting tab to use the virtual sound card (the same one that is used in RadioBOSS instances) and it will broadcast whatever's playing on this sound card.

 

[eddr]

Hmmm It's sounding better Definitely a contender if my method doesnt work out.

So the only thing is the track title and how to get round this - when switching to the line input instance, how can I get the title updated to reflect this? I guess the normal instance would be used for broadcasting to make this easier but i wouldn't want it sending track titles when actually what your hearing is a live feed and not the playlist which is playing. Any ideas?

 

[djsoft]

So the only thing is the track title and how to get round this - when switching to the line input instance, how can I get the title updated to reflect this? I guess the normal instance would be used for broadcasting to make this easier but i wouldn't want it sending track titles when actually what your hearing is a live feed and not the playlist which is playing. Any ideas?

Yes, title updates are a problem - I can't think of any quick solution to it. Maybe you can solve it on your server side, show that line in is playing and send the title update to Shoutcast.

 

[eddr]

Would it be solved by another feature to allow an event/schedule send title update? I suppose this depends on how title updates work - does the title which is being sent get updated when the track changes?

 

[djsoft]

Would it be solved by another feature to allow an event/schedule send title update? I suppose this depends on how title updates work - does the title which is being sent get updated when the track changes?

Title updates are sent either periodically or on track change.

Did you consider implementing the "scheduler catch up" in your own script, as I mentioned before: https://www.djsoft.net/smf/index.php/topic,4663.msg22458.html#msg22458