OneDrive and RadioBOSS

southernfm

Active member
We're trialling using OneDrive with RadioBOSS.

When we've downloaded the MP3 to the hard drive using OneDrive's sync capabilities, the library search feature seems okay for tracks that are on the hard drive. E.g. we have a folder called ZZ_Themes, C:\Music\ZZ_Themes and a music library called ZZ_Themes. When searching within this library, it is responsive.

We have a large music library, with over 75,000 tracks, between 1950s-2020s, split over several libraries. These are not available on the hard drive, but can be downloaded by OneDrive as needed. When we drag the track into the playlist, or click on the track in the playlist, this is enough to trigger OneDrive to download a local copy of that file. For our purposes this would be sufficient.

However - when we attempt to search through libraries containing tracks that aren't available on the hard drive, the program becomes unresponsive most of the time. Searching for a track is pretty much impossible to do with our set up. This is the same if we reference a network attached location. In our case we're trying to set up a laptop so we can play music at outside broadcasts. The laptop hard drive isn't large enough to house the entire library.

We're working on a way to solve the issue for ourselves, but the search functionality seems to reference the tracks that are being looked up fairly heavily. Expected behaviour with the library search would be for the information within the database itself to show up within the library search. If a track or item is clicked on the library, perhaps that would warrant 'probing' the MP3 file, although personally I think that should only be done if it is in the playlist, or track tool or something like that were used on the track.

I understand there's a cache involved, but I'm not sure what the need is in probing the MP3 files within the library search itself, if we have a database that's supposed to have all the information (the cache could reference the database directly if required, instead of the MP3 file(s).

For example we search for "Eminem" in either (All) or one of the music libraries where we don't have all the MP3s on the hard drive, and the laptop starts downloading 20 tracks in OneDrive, unrelated to what we actually needed. Additionally RadioBOSS freezes and wants to crash (we've submitted bug reports).

This may be a fringe use case with RadioBOSS, but if the search was limited to pulling data out of the database only (except if File Tag APEv2 is used), instead of referencing the files directly, then it would likely improve the search speed and reliability.
 
What option do you use for "Additional information storage" in RadioBOSS Settings->General? It will try to access the files if you use "APEv2" but it should access them a lot less if you use SQLite or MySQL.
 
What option do you use for "Additional information storage" in RadioBOSS Settings->General?
MySQL for all of our systems. We have a dedicated database server that our studio players use, which works well. We have 2 laptops that have their own MySQL databases on their own hard drives (we replicate them behind the scenes). It is one of these laptops where we're having trouble with OneDrive downloading files when we search for items in a library where the MP3s aren't on the hard drive.
 
I suppose the root of the problem here is that RadioBOSS checks if the file was modified in order to decide if cached entry is valid or it needs to read the tag from the file. We'll add an option to skip this step and always make it read the cached entry. This will significantly speed up tag/info reading as it completely skips the disk access. The only case when this will cause problems is when the tracks are modified outside of RadioBOSS (or any of its modules) - those changes won't be seen by RadioBOSS.
 
The only case when this will cause problems is when the tracks are modified outside of RadioBOSS (or any of its modules) - those changes won't be seen by RadioBOSS.
That won't be a major issue for us. We run daily updates on all of the libraries to keep the MP3s and libraries in sync, so we should have the latest data from that scan.
 
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 unintentionally.

It looks like when we highlight the track in the playlist, it doesn't download it from OneDrive like it was doing previously. For example we could choose 15 items out of the music library (some which aren't on the hard drive), and we were able to click on each item in the playlist one by one, which triggered OneDrive to download those tracks, so later on when we played them, they'd be on the hard drive. Any chance we could get that behaviour back (e.g. clicking an item in the playlist 'probes' the MP3 file?)

Searching in the library doesn't do anything at the moment (which is what we want). The pre-load next song feature does trigger OneDrive to download the next track, but has a draw back where if we insert a station ID which is less than 15 seconds long (15 seconds being our pre-cache trigger), then a subsequent track (especially a long one) can get stuck until OneDrive finishes downloading it.

Just to note as well - this behaviour exists whether we have the skip cache option enabled or not (just adding that to outline that it might have been a side effect of the previous version)
 
Last edited:
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 unintentionally.
While we were adding this option, there were also other tweaks made to speed the things up. So you see the result of those. Disabling cache validation also excludes additional step where it verifies file modification date (and also excludes tag/info reading in case a file was modified).

Any chance we could get that behaviour back (e.g. clicking an item in the playlist 'probes' the MP3 file?)
Without file validation, it's not really possible. A file will be downloaded when it's required to do so e.g. you can open Segue Editor 3, it will download the three tracks. A track will be downloaded when it's played or preloaded.

but has a draw back where if we insert a station ID which is less than 15 seconds long (15 seconds being our pre-cache trigger), then a subsequent track (especially a long one) can get stuck until OneDrive finishes downloading it
15 seconds is not enough to download it?
 
15 seconds is not enough to download it?
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.
 
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.
If it's shorter than preload time, the preloading should start immediately after the station ID starts playback.
 
If it's shorter than preload time, the preloading should start immediately after the station ID starts playback.
This wasn't happening with earlier versions, but I will test with the new version and see how it behaves and let you know
 
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. Once the next song is reached and about to play, RadioBOSS stalls waiting for OneDrive to download, then it plays when it has
 
It's possible that the preloading was started but failed to finish during the 7-second station ID.
 
It's possible that the preloading was started but failed to finish during the 7-second station ID.
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 file that follows a track (stationID in our case) that is less than 15 seconds long, when 15000 is set as the pre-cache figure in the settings. (or in other words - when the pre-cache setting is set to 30 seconds for example, I expect the same behaviour would take place) - I can test that out tomorrow to confirm.
 
Last edited:
We'll check if there's a bug with this.
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 our case) was being met.

Temporarily I was able to get this triggered by adding a song from the music library to the playlist, but it stopped working after awhile. Part of our preparation process for the outside broadcast laptops is to copy the RadioBOSS folder contents from our main system, and override the laptop copies, so they have the latest ad scheduler entries etc. and are up to date. We do this manually and it works well.

Today I have done that, and the behaviour of the player has gone back to caching/downloading the OneDrive files (that are only in the Cloud until we need them) onto the computer, when songs are added from the music library, so it seems to be picking up a setting from somewhere. This is actually beneficial for us so we're happy that it's happening, but just not exactly sure what is triggering this. The advanced configuration looked identical between the two systems.

The configuration from our main computer system is old I think, it was probably initially created back in the version 5.5 days, so it's possible there's some legacy setting somewhere inadvertently triggering this.

There's no bug to report I guess since we're getting the behaviour we desire, but just not exactly sure how it's happening.

Advanced config is as follows:

Event editor - File browser starts in event directory - True
Events - Legacy behavior for "Do not action event when playlist is stopped" option - True
Events - Delete confirmation box: include event name - False
Playlist Text - Track List (TrackList)
Playlist Text - Time Announcement (Time Announcement)
Playlist Text - Playlist Item (Playlist)
Playlist Text - Teaser
Text - Nowplaying text when stopped - Southern FM
Text - Additional text for system tray icon - (blank)
Text - Stream name when URL hidden - NetworkStream
Playlist - Start Time calculation track limit - 450
Playlist - Open playlist: store file name for playlist tab - True
Playlist - Confirm "Delete all" operation - False
Playlist - Enable next track preload - True
Playlist - Preload next track buffer (ms) - 15000
Playlist - Preload network streams only - False
Drag-n-Drop - Sort tracks alphabetically - True
Logging - Create Teaser Log - False
Audio - Disable tag reading - False
Audio - Skip cache validation when reading tags - True
Audio - Code page for non-unicode tags (0 - use system default) - 0
Audio - Read tags in a separate process - False
Audio - Improve seeking, gap killer and mix point precision for MP3 and chained OGG tracks (slows down track start) - False
Audio - Process 0-9 jingles with main DSP (only when played on the main device) - True
Audio - Do not use Media Foundation codecs - True
Fading - fade out on pause (ms) - 150
Disable screensaver - True
Smooth level graph - False
Turn off visualization and level display - False
Broadcast - Internal server buffer size (ms) - 2000
Broadcast - Do not send empty title when playback stopped - False
Track List - Track selection timeout (ms) - 3000
Stream playback - Disable title sync - False
Stream playback - Delay between connection attempts (ms) - 2500
Stream playback - Proxy server - (blank)
Stream playback - User Agent - RadioBOSS
getfile command - delete files to recycle bin - True
Album Cover - image size for saving and export (px) - 350
Album Cover - try reading cover art from folder - False
Accessibility - Use text UI for VST plugins - false
Weather - Use text UI for VST plugins - False
Weather - data expiration (hours) 123
Search - Search delay (ms) 300
Search - Maximum number of returned items - 1000
Legacy - Use APEv2 tag for FLAC - False
 
The configuration from our main computer system is old I think, it was probably initially created back in the version 5.5 days, so it's possible there's some legacy setting somewhere inadvertently triggering this.
I don't think any legacy setting could do it. Also, many of settings were renamed or their meaning changed or they were removed in RadioBOSS 6.0. Windows also has file cache and it can also affect how everything works. We design RadioBOSS to ensure it works with regular or network folders. How it performs with OneDrive - we do not test because this is a lot of work and does not guarantee anything because OneDrive is also updated and its behavior can be changed any time.
 
I don't think any legacy setting could do it. Also, many of settings were renamed or their meaning changed or they were removed in RadioBOSS 6.0. Windows also has file cache and it can also affect how everything works. We design RadioBOSS to ensure it works with regular or network folders. How it performs with OneDrive - we do not test because this is a lot of work and does not guarantee anything because OneDrive is also updated and its behavior can be changed any time.
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
 
Preload next song feature if the song playing is less than 15 seconds (with our customised setting), appears to be working now. Thank you
 
Back
Top