RadioBOSS 5.6 [beta]

Status
Not open for further replies.
As tljay kindly posted a video to demonstrate the Voicetrack with Bed issue I thought I would add my own video to show the issue I am having.

Sometimes it works as you can see towards the end of the Video but most of the time it does not work but continues to play the bed even though the voice track has ended!

https://youtu.be/xw5EmgVT0QA
 
Thanks for the videos. The bed problem is confirmed for time announcements (probably the issue happens in other cases as well). Will be fixed in RadioBOSS 5.6.1.
 
djsoft said:
This will be fixed soon.

Hi
djsoft said:
Please post a screenshot of an event that does this, and also screenshot of player window - before and after an event is started. This is required to reproduce the problem here.

Also, to clarify when you say "Manual start" - does it mean that the event is started manually (the Run Now button), or that track in the playlist is started manually (using the play button)?

Update the bug was reproduced when the scheduled track is started manually from the playlist. It does not remove the track from the queue, therefore track plays second time. This will be fixed soon.

Hi,
When is the fix for this expected to be released?

Thanks
 
southernfm said:
When is the fix for this expected to be released?
It's planned for RadioBOSS 5.6.1, in the second half of July I think.

As a workaround, you can use the Next track button instead of Play to start the track - this will remove the queue mark from the started track.
 
djsoft said:
As a workaround, you can use the Next track button instead of Play to start the track - this will remove the queue mark from the started track.

Thanks but that doesn't suit our setup. If you have an early release version could you please post it here? Otherwise we'll wait til later this month.

Thank you.
 
southernfm said:
Thanks but that doesn't suit our setup. If you have an early release version could you please post it here?
If there will be a intermediate build with some fixes available, it will be posted here.
 
Hello, what can be owed this error in the notifications? (previously it worked well)
 

Attachments

  • Sin t?tulo.png
    Sin t?tulo.png
    29.3 KB · Views: 458
nelson c said:
Hello, what can be owed this error in the notifications? (previously it worked well)
Could be that security settings at your email provider changed. I suggest contact them about it, or read their user manual about how 3rd party apps can use their SMTP server - usually you'll need to enable 3rd party app access, or create separate login/password.
 
Hi

Not sure what the problem is but I keep getting the following error(attached image)? Any idea why? It now occurs everytime adsupdate event triggers, never had the problem before.

 

Attachments

  • IMG_6856.PNG
    IMG_6856.PNG
    59.2 KB · Views: 411
We'll check why this may happen - thank you for letting us know about the problem. But from the error message, I can say that you can safely ignore it, it shouldn't affect operation.
 
This is odd - please send the report (.csv) file for this day, maybe it will shed some light on what happens.
 
Here's the attachment. Although it seems to be correct. In today's day is still happening in the log


Thanks
 

Attachments

  • 2017-07-12.csv
    630.7 KB · Views: 328
A doubt: The new audio engine will improve the precision of sigue editor? It is much the difference between the previous listening and the mix that really is played. I guess for the disk access times. If you want to keep the rhythm for example so that the song that ends and begins to cross in a coup, is impossible are a few milliseconds of difference that make the adjustment with the editor is useless.

Provisionally add a very useful setting configuration:
For example if it is known to take 50 ms to start the track compensate that time in the actual mix.
 
nelson c said:
The new audio engine will improve the precision of sigue editor? It is much the difference between the previous listening and the mix that really is played. I guess for the disk access times.
This is because of low crossfade engine resolution, that allows crossfade times to drift +- 50 milliseconds (sometimes can be even more). The new audioengine will fix this, yes. But its development is a lot of work so I can't say when it's going to be finished.

nelson c said:
For example if it is known to take 50 ms to start the track compensate that time in the actual mix.
The amount of error is not known, it can be different each time, even when the same tracks are played again.
 
nelson c said:
Here's the attachment. Although it seems to be correct. In today's day is still happening in the log
This is not a bug: in the report you don't have the "Title" column, but use the Filename column instead, and that will be empty for scheduled commands and many other log entries. Please see the image attached where (your report file is loaded there).
 

Attachments

  • log.png
    log.png
    24 KB · Views: 419
Status
Not open for further replies.
Back
Top