RadioBOSS Cloud

[jharris171185]

Major problem this morning with stream retrieval of podcasts. Here's an example of what my log shows.
2025-05-09 9:00:12 AM
https://www.srnnews.com/feed/?post_type=audio-news&audio-category=hourly-news podcast
2025-05-09 9:00:53 AM
Stream connection lost/unstable: reconnecting
2025-05-09 9:01:35 AM
Stream connection lost/unstable: reconnecting

Each time it reconnects, it starts the podcast over, but not the time it is set to play for, so you get something that restarts multiple times, but does not play to completion. Not sure what should or could be done, but it has happened multiple times this morning.

 

[djsoft]

Not sure what should or could be done, but it has happened multiple times this morning.

The only real solution is to ensure network reliability so that the podcast plays in full without interruptions.

 

[jharris171185]

Hello,
I could use a bit of help with setting up requests. I understand how to turn them on, and how to insert the code, but I need to find a way to have them be able to play just about any time, as long as that time is NOT within a few minutes of another scheduled event. I have a general music playlist scheduled hourly, but then an ads playlist (consisting of ad intro, ads, ad outro), another playlist consisting of a podcast followed by a station sweeper, etc. Goal is to not have requests pop up right in the middle of those specific playlists. Those playlists are set to start after currently playing track. So what I don't want to happen is, for example, requests to fall between ad intro and ads, or between my ads and ad outro. Or, between the podcast and the sweeper. Does this make sense? But, any other time in the hour is fair game. If I just insert the command at specified times, I run the risk of that happening. How would you go about this, and with as few scheduler items as possible? Ideally, at least 3 requests should be inserted per hour, if any exist at all. What would be absolutely amazing, is in the playlist builder, an option could be given to "replace track with request if one is available." Any way you could add that? Then, I could specify exactly which tracks are available to be replaced, exactly where requests should fall, and where they should not. You could add this option in the same set of options where you choose whether or not to ignore protection rules, whether or not track is sequential or random, etc. Please please consider adding this. That would enable requests in a much quicker way, and not clutter up the scheduler with tons of events. And, it would, I think, be easier to implement than heavy if then logic in the scheduler, but allow us to achieve the same result.

Also, on an unrelated note, I have a podcast that always seems to play quiet. Is it possible to create a filetype for that, and give it a boost of say +1 db?
Thanks in advance for your help.

 

[djsoft]

If I just insert the command at specified times, I run the risk of that happening. How would you go about this, and with as few scheduler items as possible?

You can configure the "playrequestedsong" event to queue after the scheduled tracks, this way it will not interrupt other schedules. Currently, this is the only option.

 

[jharris171185]

I know that currently it's the only option, but I think it could be made much better. Also, it would be good to have a few more things in the request feature.
1. In the widget, once the person finds the song they want, have them enter their name and location, so when someone is live, we can give a shout out.
2. The ability to mark a request as played, that way, if we are live, but a request comes in via the web site, we can play it live, mark it as played, so that once we kick back to the cloud, it doesn't get replayed.
3. A command that can run every so often, to clear requests over a certain length of time that were already played.

 

[jharris171185]

Also, to further explain why more options are needed, if you cue after all scheduled tracks, you run the risk of having so much in the schedule that they simply don't get played. If you insert after currently playing, you run the risk of having them pop up where you don't want them.
I know what is currently possible, but I am asking you to please add more ways of doing it to work better with more setups.

 

[djsoft]

I know that currently it's the only option, but I think it could be made much better. Also, it would be good to have a few more things in the request feature.

Yes, we will improve it in the future when the Scheduler will have more commands/options like conditional commands/actions.

1. In the widget, once the person finds the song they want, have them enter their name and location, so when someone is live, we can give a shout out.
2. The ability to mark a request as played, that way, if we are live, but a request comes in via the web site, we can play it live, mark it as played, so that once we kick back to the cloud, it doesn't get replayed.

The song requests will be improved in the future, we'll consider what you propose too.

3. A command that can run every so often, to clear requests over a certain length of time that were already played.

This command already exists: songrequestclear it's documented here: https://www.radioboss.fm/support/radioboss-cloud/scheduler/scheduler-commands/

 

[jharris171185]

Ok, so I see the command you mention to clear old requests. That is good, but problem is, just clearing old requests does not make any distinction between played vs unplayed. Now granted, I have it set up to pull potential requests 3 times an hour, so setting it to clear stuff over 4 hours as suggested in the example, should only clear played items, but it would be nice to have a fail safe there, in case for some odd reason the request conflicted with other repeat rules and couldn't be played for a while.

Honestly, even something in the wording of a command about not splitting up a playlist would be good. Example, I have a playlist for ad breaks that includes intro, ads, outro. I also have playlists that include a sermon clip followed by a sweeper, and others that include a podcast followed by a sweeper. So a way to just make sure it can't split those up, treat those like a single track in the system, instead of multiple, so it could insert say after mini playlist but before next song, would be more than enough, that way we are not relying on scheduler timing alone, and have that fail safe. So you can see what I mean, here is one of my rotations. Rotations start at like 2:30 each hour, after top of hour station id, news break, and hour intro sweeper.
(TrackList) \Music (random, subfolders)
(TrackList) \Sweepers (random, subfolders, ignore repeats)
(TrackList) \Music (random, subfolders)
(Playlist) Ads
(TrackList) \Music (random, subfolders)
(Playlist) Answers In Genesis
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
(TrackList) \Sweepers (random, subfolders, ignore repeats)
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
(Playlist) Hub Clips
(TrackList) \Music (random, subfolders)
(Playlist) Ads
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
(TrackList) \Sweepers (random, subfolders, ignore repeats)
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
(TrackList) \Sweepers (random, subfolders, ignore repeats)
(TrackList) \Music (random, subfolders)
(TrackList) \Sweepers (random, subfolders, ignore repeats)
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
(TrackList) \Sweepers (random, ignore repeats)
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
(TrackList) \Music (random, subfolders)
This rotation is a bit over scheduled to account for the varying lengths of songs and other items in the rotation. I hope by pasting my rotation here, you can see where issues could arise. Thanks for your understanding and your work on this. I don't mean to harp on it too much, and I do want you to know that I am very happy with the service and the stability, and any suggestions or requests are only to help improve.

 

[jharris171185]

Any way we can get a filetype identifyer for streams, specifically podcasts? I know there is one for tts, but not anything for streams. That way we can apply slightly better fading rules between items.

 

[djsoft]

Ok, so I see the command you mention to clear old requests. That is good, but problem is, just clearing old requests does not make any distinction between played vs unplayed. Now granted, I have it set up to pull potential requests 3 times an hour, so setting it to clear stuff over 4 hours as suggested in the example, should only clear played items, but it would be nice to have a fail safe there, in case for some odd reason the request conflicted with other repeat rules and couldn't be played for a while.

Intention is that unplayed old requests do not make a lot of sense. The person who requested it would not wait for days for the request to be played.

Honestly, even something in the wording of a command about not splitting up a playlist would be good. Example, I have a playlist for ad breaks that includes intro, ads, outro. I also have playlists that include a sermon clip followed by a sweeper, and others that include a podcast followed by a sweeper. So a way to just make sure it can't split those up, treat those like a single track in the system, instead of multiple, so it could insert say after mini playlist but before next song

It will be possible in the future when an events will have the "Start as Container" option, effectively making an event an "unbreakable".

Any way we can get a filetype identifyer for streams, specifically podcasts? I know there is one for tts, but not anything for streams. That way we can apply slightly better fading rules between items.

There's an option to apply file to network streams.