CPU load issue after Windows startup

[fuggi]

Hi,
I've been observing an issue with UMS on Windows 7 64 bit in a standard user account (non-administrator account) from the first installation of version 7.8 up to the current version 8.0:
If the option "Start with Windows" is enabled, the CPU load caused by UMS' Java process is significantly higher (~10-50%) in comparison to a manual startup (~0-10%). For instance, UMS operates normally again after closing the auto-started instance and restarting it manually (with the same user account and in the same session). The media library is enabled, but the option "Scan shared folders on startup" is not. With version 7.8, this issue was eventually slowing down UMS so significantly it was even impossible to stream video or audio which needn't to be transcoded.

Is anybody encountering the same issue or can reproduce it?

Best regards,
fuggi

PS: At the moment, I'm working around this issue by disabling "Start with Windows" and using a small batch script in Window's Autostart folder to have it started automatically on Windows start-up without the above-mentioned issue.

[fuggi]

Hello again,
the issue is a little bit different than I thought initially. Even with the new start-up procedure in place, UMS' CPU load goes up after a few minutes IF (and only if) the media libriary is enable (but the "Scan shared folders on startup" still not).
I consider this a bug. Can anybody reproduce it?

In addition, UMC needs literally hours to re-scan shared folders ("Scan shared folders on startup"). I've shared folder with about 90,000 files and the re-scan (not the first scan) was still not finished after more than an hour. For testing purposes, I've also coded a small Java program which scans all these shared files and it takes only a few minutes. So I guess something is going wrong there, too.
Does scanning take so long for you, too?

Best regards,
Marcus

[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.

[fuggi]

Hi all,
many thanks for your responses! Let me answer them step-by-step:

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.

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

I'm glad you noticed the same issue. Thank you in advance for having a look at it!

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.

Thank you for this information! I'll check it with my setup and get back to you.
Just a few questions for my understanding: If that was the reason, why isn't the CPU load just as high with the media library disabled? I mean, wouldn't the media renderer always ask for the complete media tree regardless of UMS' settings? And if so, wouldn't that cause an even higher/longer CPU load since UMS would be forced to scan all shared folders on demand?

Best regards,
fuggi

[fuggi]

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.

Thank you for this information! I'll check it with my setup and get back to you.
Just a few questions for my understanding: If that was the reason, why isn't the CPU load just as high with the media library disabled? I mean, wouldn't the media renderer always ask for the complete media tree regardless of UMS' settings? And if so, wouldn't that cause an even higher/longer CPU load since UMS would be forced to scan all shared folders on demand?

Update:
While it had seemed to be working for the first 30-45 minutes, the CPU load rose again afterwards and remained at high levels between 20-80% ever since. Hence, it didn't work for me.

[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