CPU load issue after Windows startup

[Nadahar]

I doubt your Java test-program analyses the content of the files and creates thumbnails if appropriate. It's not just about "listing" the files.

[SubJunk]

I've seen that CPU issue after startup lately too and have been meaning to look into it

[atamariya]

Agree with @nadahar. Additionally, check if you have a renderer which is asking for complete media tree. My LG TV is one such culprit (WMP another). I always switch on my TV only AFTER UMS is completely up.

[Nadahar]

You're right. It's not quite as simple as you say, but the general idea is correct. UMS should be able to use the information from the database instead of re-parsing in the majority of cases. Your experience suggests that isn't the case, which sounds like a bug to me.

[SubJunk]

I doubt your Java test-program analyses the content of the files and creates thumbnails if appropriate. It's not just about "listing" the files.

You are right, it isn't ... and there is no need for it. Since all folders had been scanned when they were added to the media library in the first place, a re-scan only needs to check if each folder and file still exists or if there are new folders/files and, at most, check if its timestamp of file size has changed. Only if one of these conditions applies, UMS needs to scan its contents and, if applicable, create a thumbnail.
I was not complaining about the initial scan, but only the re-scan which takes so much time even though not a single file/folder has changed.

Yeah that is what it should be doing so maybe there is a bug there. We generally use MediaInfo and it takes time (milliseconds which add up) to keep using that for every file, so maybe there is a bug where that is being launched even when a database match was found. Just an idea that might be right or wrong.

Maybe you can have a look into our code and try to fix it since we are open source I am sure a lot of users would be very happy if the scanning got faster.

[SubJunk]

I haven't had this happen since using the standalone build, so it may have been related to a newer version of Java