Author Topic: What is the burden on cpu/disc for 'scan on startup' and 'continuously monitor'?  (Read 972 times)

Dizza17

  • Full Member
  • ***
  • Posts: 186
So for anyone that is intrested,

Using the latest version of portable mb,
total of 22,783 tracks (6117 FLAC on portable HHD - 15,951 mp3 on internal HHD)
Win 10 installed on SSD.

Average scan time across 3 startups - 14 mins
mb Disk usage - between 25 - 31 percent for scan period.

regards
Aaron
When the rich wage war, it’s the poor who suffer.

Pickles7853

  • Full Member
  • ***
  • Posts: 150
Dizza17:
Ok... after some testing I am going to take a wild stab in the dark.  You have (perhaps a couple) of long, nested, hard to decipher Virtual Functions?  Maybe related to classical music.  Using Regular Expressions.  Did I get close?

Reason: I am just curious about your 14 minute load times.   As a frame of reference -- I have 5700+ music files with related art, lyrics, etc all on an external 1TB USB drive.    All things being equal I would expect my load time, based on yours, to be around 3.5 mins.  I can delete my MB DB completely (including backups) and next time I run MB I am ready to go in under 6 seconds.  The only thing I can think of that might cause this would be Virtual Functions having to format so much data...

As this is off topic for the thread I would not be offended (in the least) if you decided not to reply.  Just saying.  If this is something you would like to look into though we could start a new topic about it up in the General forum.

hiccup

  • Hero Member
  • *****
  • Posts: 9107
As this is off topic for the thread I would not be offended (in the least) if you decided not to reply.
I think it's perfectly on-topic.
The goal of this topic is to get some better understanding of anything involved so that users can make an informed decision on deciding to activate these two features or not.

@ Dizza17 and Pickles7853: do you have drive indexing enabled for the drives that contain your music?
Could that also be a factor?

Pickles7853

  • Full Member
  • ***
  • Posts: 150
Quote
do you have drive indexing enabled for the drives that contain your music?
Could that also be a factor?

I have indexing disabled...
I actually have no idea if that could be a factor or not though.  It is one of the few features of Windows that I know almost nothing about.

hiccup

  • Hero Member
  • *****
  • Posts: 9107
I can delete my MB DB completely (including backups) and next time I run MB I am ready to go in under 6 seconds.
That seems crazy fast for 5700+ files on an external USB drive. (assuming it is a mechanical drive?)
Surely the data must have been cached somewhere to get such results?
Did you use 'compress library' between tests?

Quote from: Pickles7853
I actually have no idea if that could be a factor or not though.  It is one of the few features of Windows that I know almost nothing about.
I know it is intended to speed up Windows search.
So it will be indexing things like file location, and perhaps also some file properties and metadata, depending on the file types.
But seeing your speedy scan results with indexing disabled for your drive, it's probably not something that MusicBee uses when scanning a drive, and thus irrelevant for the functioning of these two scan options.
Last Edit: April 28, 2025, 07:11:30 PM by hiccup

Pickles7853

  • Full Member
  • ***
  • Posts: 150
I did some further testing with some interesting results.  Well at least for me.
Note: Today I am getting a different base time.  Instead of 6ish seconds it has increased to 17 seconds.  Not really sure why.

<1> I went online and found the worst (read longest) virtual function I could.  I made a derivative of it for my tests.  Original can be found in this thread:
https://getmusicbee.com/forum/index.php?topic=34322.0
<2> I then found some functions (five of them) using Regular Expressions.
I created a new Virtual Function and pasted the contents of <1> five times.  I then pasted each of <2> five times.

In all of my testing my base time never increased very much.  I ran it three times without, three with, and again three times without.  It is a steady 17 seconds without or ~19-20 with my FrankenFunction.  So I am forced to conclude that my initial assumption of Virtual Functions effecting Dizza17's scan times are probably incorrect.
Last Edit: April 28, 2025, 08:02:46 PM by Pickles7853

hiccup

  • Hero Member
  • *****
  • Posts: 9107
It is a steady 17 seconds with or without my FrankenFunction.
Still a lot faster then I would expect from such an amount of tracks using an external mechanical drive.
(again, did you use 'compress library' between tests?)

Quote from: Pickles7853
So I am forced to conclude that my initial assumption of Virtual Functions effecting Dizza17's scan times have to be incorrect.
Thanks for testing this thoroughly. Highly appreciated.
To be honest, I would have been very surprised if virtual tags would have played any role in this at all.
Virtual tags reside in MusicBee itself, not in the files.
And what they output is never stored anywhere at all.
So I can't really imagine them affecting scanning.

Things like having (perhaps large-size) artwork embedded in the files instead of linking/referencing them may play a role?
Last Edit: April 28, 2025, 08:22:19 PM by hiccup

Pickles7853

  • Full Member
  • ***
  • Posts: 150
Quote
Still a lot faster then I would expect from such an amount of tracks using an external mechanical drive.
(again, did you use 'compress library' between tests?)

I have never compressed my library.  While I have seen, in other threads, some people suggesting this as part of a solution to someone's issue, I never followed through to find out what exactly this does.  My drive is a Seagate SRD0SP0 (if this helps).

Quote
Things like having (perhaps large-size) artwork embedded in the files instead of linking/referencing them may play a role?

This, again, gets me into unknown territory.  I know all about tags but nothing about how they are actually implemented.  I would blandly assume this would be a non-issue as I cant see the distinction between reading artwork from an MP3 file or a dedicated PNG/JPG.  Either way it is just reading a sequential chunk of memory.  Umm right?  I could be wrong.

What I can say about my files:
For various reasons (preference/ security/ saving disk space) I always separate everything I can.  My music files are simply MP3s with tags.  Artwork is separate as are lyrics.

Quote
So I can't really imagine them affecting scanning

Well I am under the assumption (perhaps incorrectly) that MB is creating lists for artists, albums, tracks, etc as the information is parsed from the files.  So if you used a really time consuming Virtual Function I could imagine it slowing down the process as a whole.  It is possible these are separated.  Perhaps all the tags are read first and then processed afterwards.
Last Edit: April 28, 2025, 09:47:01 PM by Pickles7853

hiccup

  • Hero Member
  • *****
  • Posts: 9107
I have never compressed my library.
OK, I think that might explain why your scan results are so fast.
Information about your 'deleted' files will still be cached in MusicBee's library, and will be available and used when you re-import them. (I think)
Last Edit: April 28, 2025, 09:53:49 PM by hiccup

vincent kars

  • Sr. Member
  • ****
  • Posts: 474
Quote
Well I am under the assumption (perhaps incorrectly) that MB is creating lists for artists, albums, tracks, etc as the information is parsed from the files.
That is how it works indeed.
If you start with Musicbee (or any other media player), you point it to the root of your music collection and it will scan all the files, read all the tags and store it in its own database. This is very time consuming but when done, all it has to do is keeping its database in sync with the files.
 Obvious, querying a database is much faster than reading all audio files. This explains why the response of Musicbee is crisp. You are not accessing individual files, you are querying a database.
Musicbee goes one step further, is caches the database to get an even better performance.

Windows does the same, it creates a database of all the files. Just open de Windows File Explorer. How could it be so crisp? Indeed it queries a database instead of scanning all the files on a disc.

On startup Musicbee only have to compare the date last modified in its own database with the date last modified in the database of the file system. Only if there are differences, it has to do something.

hiccup

  • Hero Member
  • *****
  • Posts: 9107
On startup Musicbee only have to compare the date last modified in its own database with the date last modified in the database of the file system.
I'm pretty sure MusicBee does not do that.
Not out-of-the-box with default settings.