What is the burden on cpu/disc for 'scan on startup' and 'continuously monitor'?

[hiccup]

Ideally, I would think this is something that one would want to be the default.
But I can imagine it being some extra burden on disc activity and perhaps cpu load?
Using ssd vs. mechanical drives may also be a factor?

Any insights on this?

edit
It seems I am not the only one being curious about this.
So, my end-goal for this question boils down to getting the answers to:

Enabling 'scan at startup'
  -  positives: …
  -  possible negatives: …

Enabling 'continuously monitor'
  -  positives …
  -  possible negatives …
 

[Pickles7853]

Minimal if anything.  This is done through the standard Windows API (I think Win32.dll) and it tells the OS that you would like to be notified of any changes.  So MusicBee would get a change notification message and you could then rescan the file(s)/ directories.  So it is not a continuous looping scan that eats resources as you might imagine it to be.  If you are looking for more specifics, you can find more info here on the Microsoft development pages:

https://learn.microsoft.com/en-us/windows/win32/fileio/obtaining-directory-change-notifications?redirectedfrom=MSDN

[hiccup]

Minimal if anything.

So do you think it would make sense to ask/suggest for this being the default for MusicBee?
Do you see any bears on the road if it was? (people using older cpu's, hard drives, networking etc.)

[Pickles7853]

I cant think of any bears per se.  This is standard Windows stuff.  A lot of applications use it for varying purposes.  Like virus protection programs monitoring specific folders or text editors detecting when an open file was modified externally and asking if you want to refresh to view the changes.

To me it is simply a matter of preference.  You can either set the monitoring "on", and have the changes refresh incrementally, or you can have it "off" and choose to refresh in bulk when you are ready.  Either way, in the end, it is the same amount of work for MusicBee.  Just a matter of when it happens.  My opinion is that "on" should be the default.  New users would find this more intuitive as how they might imagine it should work...

[phred]

My PC is on 24/7. I also have MB on 24/7 unless I'm applying a patch update. My CPU usage with MB minimized and not playing music is 1%. I can live with that.

For those who want to know why I have MB launched all the time is that the UPNP plugin allows MB to be seen on my stand-alone Internet radio.

[hiccup]

My PC is on 24/7. I also have MB on 24/7 unless I'm applying a patch update. My CPU usage with MB minimized and not playing music is 1%. I can live with that.
For those who want to know why I have MB launched all the time is that the UPNP plugin allows MB to be seen on my stand-alone Internet radio.

Regarding this topic:
Could you elaborate on the differences between having 'continuously monitor' checked vs. unchecked for your setup?

[phred]

I always have "continuously monitor" and "scan on startup" enabled. I have just disabled "continuously monitor" and my CPU is ranging between one and two percent with MB minimized and not playing anything.

[hiccup]

I have just disabled "continuously monitor" and my CPU is ranging between one and two percent with MB minimized and not playing anything.

Thanks.
That's interesting though; so activating 'continuously monitor' actually lowers your CPU load by 1%.
(Just kidding, don't respond to that. There will be other factors why such values read different every time)

After reading the responses so far, I'm starting to wonder if it wouldn't be a good idea to have both 'scan on startup' and 'always monitor' be the default.
And perhaps even remove these option settings?
Maybe they served some purpose 15 years ago, but don't anymore?

Can anyone think of a possible negative if this was the case?

[Dizza17]

With “scan on startup” enabled, I’ve found I’m unable to  use any tools (search for lyrics etc) or plugins (mainly ASR) until the  little grey x in the bottom left corner has disappeared. So there must be some sort of load on mb itself during this process. I guess it would be nice if some sort of visual representation of the progress of this startup scan was displayed. Just my thoughts.

Regards Aaron

[hiccup]

With “scan on startup” enabled, I’ve found I’m unable to  use any tools (search for lyrics etc) or plugins (mainly ASR) until the  little grey x in the bottom left corner has disappeared.

Thanks.
Ah yes, that makes sense. It will trigger a complete drive scan every time MusicBee is started up.
Definitively not a good idea for mechanical drives.
So making 'scan at startup' the default is off the table. (for now, I will raise this again April 2035)

So that leaves perhaps making 'continuously monitor' the default. (and as a maybe too rigorous step removing that option altogether)
Anyone thinking of possible negatives to that?

[vincent kars]

It will trigger a complete drive scan every time MusicBee is started up.

I don't expect it to work this way. A complete drive scan is very time consuming and MusicBee is pretty fast in reporting differences.
It might queries the FileSytemWatcher (https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-io-filesystemwatcher)
Might be another mechanisme unknown to me like comparing the date in the library with the date last modified in the file system.
But it is pretty fast.

[phred]

It will trigger a complete drive scan every time MusicBee is started up.

My assumption is that both "scan on startup" and "continuously monitor" only scanned the files in the  paths entered in the "monitored folders" field. I never once assumed MB would scan all the drives on a user's system.

[hiccup]

It will trigger a complete drive scan every time MusicBee is started up.

My assumption is that both "scan on startup" and "continuously monitor" only scanned the files in the  paths entered in the "monitored folders" field. I never once assumed MB would scan all the drives on a user's system.

I obviously didn't mean that drives that don't contain music that has been added to the library will be scanned.

Something else that is probably relevant to this matter is indexing.
I am guessing that if the drive(s) that contain the music files have 'indexing' enabled, 'scan on startup' will usually be quick.
(unless Windows is installed on a slower mechanical hard disk)
If indexing is disabled for these drives, it will probably need to scan all files on the drive, and the process will be slow.

[Dizza17]

When I am next at my computer I will time how long the start up scan takes on average over 3 start ups. I will also provide the info that contributes to this start up behaviour ie disk drive info,  library stats etc.

Regards
Aaron

[Pickles7853]

I imagine there are many ways to scan a drive at startup.  Most applications need to save a list of files/ folders which need to be checked on restart.  Due to the nature of what MB does, it already has everything it needs in the DB.  I cant speak as to how it is actually implemented, but I can speculate...

First check the folder(s) last date/time changed.  If it is the same as last time no changes have been made so load what is in the MBs DB.
Second check the files last date/time changed.  If it is the same as what I have stored in the DB then move along.  If it is different then rescan the tags.

So If no changes were made in between restarts MB could stop at the folder check.