[Solved] PC 'Stuttering' after UMS running for a while

[speckledegg]

So recently I've noticed an issues with my Windows 10 machine stuttering. The mouse will stutter, the audio will stutter, and the more I leave it the worse it gets. Closing UMS will fix the problem - youtube will play fine, movies will play fine, games won't lag etc.

I've never had this problem before - I recently upgraded to Windows 10 and thought the audio stuttering was linked to that, but it seems not. I've tried to figure out if it's a java problem, memory leak or whatever, but I'm no expert and I'm running a blank.

There's nothing in the UMS logs seemingly that shows an issue, but the computer definitely suffers. Any ideas on what I need to check, or how I might be able to trace the issue? I usually leave UMS running in the background, and have done quite happily for years, but now it's stopping me using the PC properly until I either reboot, or shut down UMS.

Thanks in advance,

Mark

[mik_s]

I'm not saying it is not UMS, but for me when my computer does that after being on a while it is because it is running low on memory and has to swap some of it to the hard drive. It wasn't a problem on win 7 but has become more of an issue on win 10.
My laptop has only 4GB and is barely usable and I don't use UMS on that. A SSD would solve that issue but not something I can afford atm.

For me the biggest memory hog is Firefox, mostly because I have a lot of open tabs. When things start getting sluggish restarting Firefox fixes it. I have heard Chrome can use a lot of memory too if you are using that.

[Nadahar]

I'd just like to add that a SSD doesn't solve swapping issues, swapping will still occur at the same rate, and SSDs will quickly wear out from intense swapping. In addition, while SSDs are much faster than harddrives in most situations, they are magnitudes slower than RAM. An SSD can mitigate swapping issues somewhat, but I'd say it's more a masking of a problem than it is a solution.

It seems likely that the described issue can be RAM related, UMS requires a moderate amount of RAM, but every thing adds up. Newer versions of software, including operating systems, tend to be more and more wasteful of resources like CPU, GPU and RAM. This is partly because new features are added and partly because development is becoming increasingly lazy. New "revolutionary" tools and techniques keep popping up that find new ways to waste resources in return for saving a little bit of time for the developer. It seems to me from my WM use that Windows 10 is much more RAM hungry than Windows 7, even though they are mostly the same "under the hood". But, I guess all the spy software included in Windows 10 also requires its share of resources

In any case, anything below 8 GB RAM with Windows 10 will probably give a bad experience.

[speckledegg]

Yes, RAM isn't the issue here - (16GB gaming system), and when it happens, it will persist regardless of what other programs I shut down until I close UMS. Again, this obviously also closes Java, and then the problem goes away.

[Nadahar]

I've never heard of this before (in relation to UMS). It kind of sounds like a GPU or audio driver issue to me, I've seen similar behavior in the past from such issues. But, there is no logical explanation or correlation between such a driver and UMS. UMS will in rare cases utilize the GPU somewhat when transcoding with FFmpeg, but if that were the issue, it should stop as soon as the transcoding stops (since FFmpeg is run in a separate process that is then terminated). Except for that, I really can't see and potential relationship between said drivers and UMS

Maybe you have come across a new, and to me unknown, bug in one of the recent versions of UMS? Have you tested older versions to see if this could be the case?

[speckledegg]

I've not tested older versions yet, but I will give that a try.

At first I too thought it was an audio driver issue - there is a lot about audio issues in Windows 10 out there, so started down that route. However, it was only when I noticed that java seemed to be using much more power and cpu than I would have expected, that I started to suspect UMS (since that's the only thing I'm running that uses java). The fact that the problem stopped when I closed down UMS only confirmed that this might be a java memory leak or some such. However, I'm no expert, so I've struggled to find either the tools or the programs that could help me trace, or log, to see if this is the issue or not.

[Nadahar]

Regarding memory leaks, UMS has a long standing memory issue where it use more and more memory over time, although there has been done some "mitigation steps" in later versions that I haven't really evaluated. But, "true" memory leaks aren't possible in Java (AFAIK) since a traditional memory leak involves actually losing the pointer to the allocated block of memory so that it can "never" be freed again. Since Java handles this "behind the scenes" and has a garbage collector that will destroy unused objects from time to time, this shouldn't be possible. However, if objects that really aren't of any use, or that is of very marginal use and should rather be recreated should they be needed are kept referenced, the garbage collector will never consider them "unused" and thus never destroy them.

This means that all used memory is "counted", so it should be very easy to see how much memory is being used by looking for example in the Windows task manager. So, you shouldn't have to wonder if this is the case, when this starts happening, simply open the task manager and see how much memory the Java process is using.

[speckledegg]

So when it happens, java is using between 8% and 24% CPU usage. It jumps around a lot. This is happening with UMS running in the background, when it isn't being used to stream or transcode anything! It's currently (i.e. at this very moment) claiming to use just under 600Mb of memory. I'd love some suggestions on how we might trace the problem...

[Nadahar]

Then this isn't a RAM issue for sure.

I see two possibilities:

1. There is a bug in UMS causing it to loop doing something it shouldn't.
2. You have a huge media library, and what you're experiencing is that UMS consumes most of the available I/O when scanning the media library which affects other parts of the system.

To examine the first point closer, you must post debug files from when this is happening. To eliminate the second point disable "library scan at startup" somewhere in UMS' configuration and restart UMS. Disabling it will mean that things won't work as intended, but it should be an easy way to determine if this is the cause or not.

Generally, don't share more than you actually want to share, because UMS is going to scan everything in the shared folders trying to figure out if it's something it can serve. If you share a large folder structure with lots of "irrelevant" files, this could make the scanning take longer.

[speckledegg]

Okay, so I've included the log files. I let UMS run overnight and, as predicted, the PC was practically unusable this morning. To confirm, I stopped UMS and the stuttering stopped.

I have also removed a lot of the folders from the shared folders and disabled scanning at startup - although I can't see this being the problem really as I have never had this problem before switching to Win 10, and I've had a pretty large media library for several years now.

I hope you can find something in the logs, although I think they'll show UMS working as intended...
Thanks for your help

ums_dbg.zip

(363.95 KiB) Downloaded 386 times