The error occurs after creating the playlists and event, and then clicking on the ads block.Error when click on the block in the ads scheduler."
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.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
Thank you, we'll check it.The error occurs after creating the playlists and event, and then clicking on the ads block.
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"
apparently this is the caseWhat 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.
RadioBOSS 7.1.1.1 Release Candidate
Changes
Download
- Ads Scheduler: improved operation speed
- Minor improvements
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)
I think that would be hard to diagnose and fix. Could be a problem with ffmpeg. Maybe try using smaller cover art files?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.
Code: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"
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.apparently this is the case
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).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.
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.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?
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?
Thank you, this will be fixed in the next update.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.
I'm having the same problem.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'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.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 confirm: I also have two types of alert messages. I saved the bugs.The error occurs after creating the playlists and event, and then clicking on the ads block.