Search results

When 'Save profile' and 'Load profile' are greyed out for a locked down user, 'Delete profile' appears to be an option that can be clicked on. Expected behaviour would be for the 'Profile save/load' checkbox to now become 'Profile save/load/delete' and delete permission to align with the...

While that is a welcome change, any chance we can get the behaviour of auto saving the profile to be switched off (advanced option choice if necessary)? We set the profile up station wide and presenters have no choice of changing it, so auto save is irrelevant for our purpose. In the odd...

Thanks. Is there a reason the .sdl file gets saved every 10 minutes by RadioBOSS? I would have expected it to save after AdsScheduler updates it, or if an API call comes in which affects the schedule.

Messages attached are from our control room PC + studios. I noticed RadioBOSS saves the .sdl file every 10 minutes. I'm not sure why it is saving so frequently?

We copy this file from our central PC to our studio PCs semi frequently whenever changes take place. Is there any particular difference between the recent version(s) compared to prior versions? We only started seeing this since 6.0.5.0 onward.

I am seeing this pop up on the studio computers several times a day since updating to the latest version (6.0.5.2)

What about if you choose expiration option 'delete event'? My understanding was disable would grey it out and delete would remove it entirely.

Preload next song feature if the song playing is less than 15 seconds (with our customised setting), appears to be working now. Thank you

Cool - no worries. I'll keep this thread alive for the other reported issue, and see if I can work out what the trigger is for the OneDrive sync when dragging from the music library to the player

I have been testing OneDrive and I'm not quite sure which setting is triggering this behaviour, but our Outside Broadcast laptops were only caching files to the hard drive when the file was loading (when we clicked play on the file in the playlist), or if the pre-cache criteria (15 seconds in...

Ah! Yes we have. Thanks.

Entering the time in the schedule editor, you can't easily see the AM/PM part resolution is 1680x1050

I'm able to see the pre-load take place because when it works correctly, OneDrive begins downloading the file to the hard drive cache, and I can visibly see when this happens in the application, and the name of the file appears at the top of the list. That is not happening at all, for any MP3...

Behaviour is still present in current version (6.0.3.1). - Preload timing set to 15 seconds - Load a music track - 3-4 mins long - Load a stationID which is under 15 seconds long (in test case, 7 seconds long) - Track immediately after stationID does not pre-cache, while stationID is playing...

This wasn't happening with earlier versions, but I will test with the new version and see how it behaves and let you know

If the stationID is less than 15 seconds long, the track following it doesn't get pre-cached. So when it reaches that song, the player stalls, while OneDrive begins downloading the track, and then it plays.

Additional track information storage location. Change to SQLite to stop that from happening

Fixed for us, thanks

Fixed for us, thanks

MASSIVE improvement compared to the last version. However, this improvement was noticed even when we didn't have 'Skip cache validation when reading tags' set to True, in 6.0.3.0. We have set it to True for our purposes, but just wanted to flag it for you in case it was doing it by default...