RadioBOSS 7.1 [beta]

[tomimatko]

Error when click on the block in the ads scheduler."

 

[tomimatko]

Error when click on the block in the ads scheduler."

The error occurs after creating the playlists and event, and then clicking on the ads block.

 

[djsoft]

It seems the error is in TimeStretch.
The start time calculation was quite accurate, however, the settings kept changing until they were disabled in the last two tracks.
I'm using the version 7.1.1.0

Now I update to the latest

What does the log say about it? Looks like start time was off for several seconds each time, maybe that's why in the end Time Stretch was not applied at all.

 

[djsoft]

The error occurs after creating the playlists and event, and then clicking on the ads block.

Thank you, we'll check it.

 

[easace]

Sometimes, during custom encoding, the track cover art fails to encode, resulting in an error. When this happens, the broadcast stream gets stuck. This seems to be caused by large cover art files. This issue doesn't always happen. There can be hours without any problems, it's a rarely occurring issue.

ffmpeg\ffmpeg.exe -loglevel -8 -loop 1 -i "D:\Radyo\artwork.png" -f s16le -ac {Channels} -ar {SampleRate} -i - -c:a aac -b:a 4096k -cutoff 48000 -compression_level 0 -aac_coder fast -c:v h264_nvenc -preset fast -b:v 1900k -r 30 -pix_fmt yuv420p -f flv -s 1080x1080 "rtmps://xxx.global-contribute.live-video.net/app/sk_us-west-2_xxx"

 

[nelson c]

What does the log say about it? Looks like start time was off for several seconds each time, maybe that's why in the end Time Stretch was not applied at all.

apparently this is the case

[2025-04-13 10:47:12] TimeStretch: init
[2025-04-13 10:47:12] TimeStretch: speed change applied (6,67%)
[2025-04-13 10:49:09] TimeStretch: init
[2025-04-13 10:49:09] TimeStretch: speed change applied (4,77%)
[2025-04-13 10:51:25] TimeStretch: init
[2025-04-13 10:51:25] TimeStretch: speed change applied (5,91%)
[2025-04-13 10:54:18] TimeStretch: init
[2025-04-13 10:54:18] TimeStretch: speed change applied (5,38%)
[2025-04-13 10:54:24] TimeStretch: init
[2025-04-13 10:54:24] TimeStretch skipped: speed change (8,12%) is out of range
[2025-04-13 10:56:45] TimeStretch: init
[2025-04-13 10:56:45] TimeStretch skipped: hour start/end is not valid

 

[NestorC]

RadioBOSS 7.1.1.1 Release Candidate

Changes

• Ads Scheduler: improved operation speed
• Minor improvements

Download
x86 https://dl.djsoft.net/beta/radioboss_setup_7.1.1.1.exe (4/12/2025, 34MB)
x64 https://dl.djsoft.net/beta/radioboss_setup_7.1.1.1_x64.exe (4/12/2025, 38MB)

AdsScheduler is performing better in our case now, but I think it's still not enough.
On the production PC, version 7.1.1.0x64 was taking 3 minutes to finish building all the blocks, and now version 7.1.1.1x64 takes 1 minute. That’s an improvement, but still quite slow.
The “Test all blocks” button continues to trigger the "Frozen" error several times, and eventually finishes after a long delay.
Our AdsScheduler.ini contains approximately 1800 ads, but most of them are either inactive or expired. We don’t delete them because it’s very common for them to be reactivated in the near future.
I ran a test leaving only the active ads (about 180), and the block-building time dropped to 15 seconds, although “Test all blocks” still gives the same error!
Maybe your algorithm could skip processing any ad that is inactive or expired. That might help reduce the time significantly, don’t you think?

 

[djsoft]

Sometimes, during custom encoding, the track cover art fails to encode, resulting in an error. When this happens, the broadcast stream gets stuck. This seems to be caused by large cover art files. This issue doesn't always happen. There can be hours without any problems, it's a rarely occurring issue.

ffmpeg\ffmpeg.exe -loglevel -8 -loop 1 -i "D:\Radyo\artwork.png" -f s16le -ac {Channels} -ar {SampleRate} -i - -c:a aac -b:a 4096k -cutoff 48000 -compression_level 0 -aac_coder fast -c:v h264_nvenc -preset fast -b:v 1900k -r 30 -pix_fmt yuv420p -f flv -s 1080x1080 "rtmps://xxx.global-contribute.live-video.net/app/sk_us-west-2_xxx"

I think that would be hard to diagnose and fix. Could be a problem with ffmpeg. Maybe try using smaller cover art files?

apparently this is the case

Thank you for the log. Yes, the core issue is start time calculation. We'll work on improving that in the future. Currently Time Stretch is good for simpler playlists, but if voice tracks/auto intro/Track List and other dynamic items are involved, it will not work as desired.

On the production PC, version 7.1.1.0x64 was taking 3 minutes to finish building all the blocks, and now version 7.1.1.1x64 takes 1 minute. That’s an improvement, but still quite slow.

In our tests here, it became about 20x times faster. Maybe depends on other things and also hardware. We'll see what more can be done to speed things up. Proper way would be to parallelize it, but it's not going to happen in this version as it's a big change and we can't afford testing it now (it's on to-do list for the next update though).

I ran a test leaving only the active ads (about 180), and the block-building time dropped to 15 seconds, although “Test all blocks” still gives the same error!
Maybe your algorithm could skip processing any ad that is inactive or expired. That might help reduce the time significantly, don’t you think?

Actually, that's what it does since the last update and that's what contributes a lot for the speed improvement. Maybe there's something wrong. we'll check it.

 

[NestorC]

AdsScheduler is performing better in our case now, but I think it's still not enough.
On the production PC, version 7.1.1.0x64 was taking 3 minutes to finish building all the blocks, and now version 7.1.1.1x64 takes 1 minute. That’s an improvement, but still quite slow.
The “Test all blocks” button continues to trigger the "Frozen" error several times, and eventually finishes after a long delay.
Our AdsScheduler.ini contains approximately 1800 ads, but most of them are either inactive or expired. We don’t delete them because it’s very common for them to be reactivated in the near future.
I ran a test leaving only the active ads (about 180), and the block-building time dropped to 15 seconds, although “Test all blocks” still gives the same error!
Maybe your algorithm could skip processing any ad that is inactive or expired. That might help reduce the time significantly, don’t you think?

I selected several expired ads to delete and then pressed "Delete".
This error started appearing and happened multiple times... I'm sending you an email with the bug report.

 

[NestorC]

I’ve noticed that if I select more than one ad and try to delete them all, that’s when the error sometimes appears.
But even if the error doesn’t show up, it still doesn’t delete all the selected ads.

 

[djsoft]

I’ve noticed that if I select more than one ad and try to delete them all, that’s when the error sometimes appears.
But even if the error doesn’t show up, it still doesn’t delete all the selected ads.

Thank you, this will be fixed in the next update.

 

[Jörg B]

Since I started using the beta version of Radioboss — and this hasn’t changed since version 7.1.0.9 — an error regularly occurs when playlists are generated automatically, as shown in the log. However, the error only happens when the playlist is created via an event, not when I generate it manually. I’ve also recreated the preset in the Playlist Generator Pro, but the error still occurs.

 

[nelson c]

Since I started using the beta version of Radioboss — and this hasn’t changed since version 7.1.0.9 — an error regularly occurs when playlists are generated automatically, as shown in the log. However, the error only happens when the playlist is created via an event, not when I generate it manually. I’ve also recreated the preset in the Playlist Generator Pro, but the error still occurs.

I'm having the same problem.
I was investigating because I can't find the cause.
In my case, it happens randomly sometimes. PLGen Pro sometimes takes more than 20 minutes to consume CPU power to generate a playlist and then throws an error.
When I test it from the tool instead of an event, it always seems to work fine. And it takes about 30 seconds to generate the playlist.

 

[Jörg B]

I'm having the same problem.
I was investigating because I can't find the cause.
In my case, it happens randomly sometimes. PLGen Pro sometimes takes more than 20 minutes to consume CPU power to generate a playlist and then throws an error.
When I test it from the tool instead of an event, it always seems to work fine. And it takes about 30 seconds to generate the playlist.

I've noticed that this issue only occurs with events or presets I created after updating to the beta version. Events that are also based on playlist creations made with version 7.0.8.0 or earlier are not affected.
4o