INTERACT FORUM
More => Old Versions => JRiver Media Center 26 for Windows => Topic started by: RD James on January 02, 2020, 07:35:39 pm
-
Recently, I've been having a problem where MC's UI slows to a complete crawl after the program has been left running (idle) for several hours.
I'm using the standard view, but doing things like scrolling a list takes literal seconds to respond to mouse input.
Restarting the program fixes it temporarily, but obviously that's not a good solution.
Any idea where to start on troubleshooting this?
-
I have experienced the same sluggishness (although in my case it is running in TheaterView). I also don’t know where to start in debugging it.
-
Windows 10? 64 bit OS and MC?
MC26.0.14?
-
Windows 10, 64-bit, MC 26.0.14
-
Yup.
-
64 bit MC on both?
Auto import on?
Audio analysis?
-
Yes.
Yes.
Yes.
But AFAICT the import and analysis processes are done. But perhaps it is trying to import or analyse “new” files that are not there (??) — but would one know it?
PS does the new “WaveForm” feature cause a re-analysis? I see nothing in Options regarding that..
-
PS does the new “WaveForm” feature cause a re-analysis? I see nothing in Options regarding that..
It does not.
-
I have experienced the same sluggishness (although in my case it is running in TheaterView). I also don’t know where to start in debugging it.
https://yabb.jriver.com/interact/index.php/topic,116118
-
This is a very well known issue (theater view). No way to fix except run an external windows task to "restart" mc every 24 hours.
Hmm. That’s rather brutish!
PS in my case, when I turn my A/V system off via my Logitech remote, it keeps the HTPC (which has MC server running on it) turned on (i.e. MC remains always on), but it turns my receiver and TV off. So I am wondering if either MC’s TheaterView 3D graphics renderer, or MC’s Audio renderer, may be getting messed up when the PC’s HDMI output “loses” the receiver plus TV that are attached (via HDMI pass thru) to it? Does “losing” the HDMI destination devices cause a reconfiguration of the audio or video drivers that might munge MC? Just a thought..
-
....MC’s TheaterView 3D graphics renderer.....
MC23:
https://yabb.jriver.com/interact/index.php/topic,112003.0.html
They made an attempt to fix it, but didn't help:
https://wiki.jriver.com/index.php/Release_Notes_MC24
24.0.33 (6/7/2018)
13. Changed: Adjusted expired time tracking in OpenGL Theater View to try to prevent failure after long time of idle
Every year, I put it in my list of requests:
https://yabb.jriver.com/interact/index.php/topic,122571.msg849277.html#msg849277
-
Yes.
Yes.
Yes.
But AFAICT the import and analysis processes are done. But perhaps it is trying to import or analyse “new” files that are not there (??) — but would one know it?
PS does the new “WaveForm” feature cause a re-analysis? I see nothing in Options regarding that..
Try turning them off, just to see what happens.
-
MC23:
https://yabb.jriver.com/interact/index.php/topic,112003.0.html
They made an attempt to fix it, but didn't help:
https://wiki.jriver.com/index.php/Release_Notes_MC24
24.0.33 (6/7/2018)
13. Changed: Adjusted expired time tracking in OpenGL Theater View to try to prevent failure after long time of idle
Every year, I put it in my list of requests:
https://yabb.jriver.com/interact/index.php/topic,122571.msg849277.html#msg849277
I confirm that the issue that I am seeing is the exact same one that tzr916 is describing. And I am 100% sure that it is not caused by auto import or analyse audio.
The hypothesis of tzr916 is that MC TheaterView is rendering graphics to an HDMI graphics output, and that when the downstream receiver and tv are turned off, this has some kind of impact on the driver that causes MC to freeze. This kind of behaviour is exactly what I am seeing too.
Furthermore, I think that the reason why MC is freezing is that the issue is causing MC’s usage of the GPU to saturate at 100%. In the past JimH has said that the issue is a driver issue and “not an MC issue”; but I think this is disingenuous, because if you look in Task Manager it says that it is the MC process which is using 100% GPU, and not some other Windows process. Therefore I think JRiver needs to step up to the plate on this.
The issue seems to build up over time during periods when the HDMI downstream devices are turned off. So my hypothesis is that during these times there is some kind of thread leak, that causes MCs GPU usage to slowly rise until it tanks at 100%.
-
I've never been able to reproduce the issue described in that other thread, otherwise I would've fixed it. It also makes no sense to me that it would happen on some systems, and not others - unless its not a problem in MC itself.
It should also not matter if you use MC or not use MC, unless "using MC" involves actually playing a video (which closes Theater View temporarily), or any other action that would close Theater View, so that its restarted.
Regardless, I made one change just now that would potentially have an impact after about 5 hours of Theater View running continously, but what exact impact that would be, and how it would manifest, is hard to say.
PS:
Theater View does not use threads - because it can't. OpenGL and multi-threading really doesn't mix very well. All graphics calls are on the same thread. Only the much more recent graphic APIs like DX12 or Vulkan are designed for proper multi-threading.
-
The issue for me is in Standard View, not Theater View.
I have disabled features like auto-import and the waveform display to no avail.
What I have noticed -and this is not the entire cause- is that certain views are causing Media Center to run significantly slower now.
These are views that haven't been updated in months/years, but suddenly run very slow in MC - mostly views that are displaying thumbnails (which are stored on an NVMe SSD).
All thumbnails have been built, and all files are already analyzed.
If I restart MC, they run much quicker - though still not as fast as they should be, and it doesn't take long to slow down again.
-
Any drives unavailable or misbehaving?
-
I confirm that the issue that I am seeing is the exact same one that tzr916 is describing. And I am 100% sure that it is not caused by auto import or analyse audio.
The hypothesis of tzr916 is that MC TheaterView is rendering graphics to an HDMI graphics output, and that when the downstream receiver and tv are turned off, this has some kind of impact on the driver that causes MC to freeze. This kind of behaviour is exactly what I am seeing too.
Furthermore, I think that the reason why MC is freezing is that the issue is causing MC’s usage of the GPU to saturate at 100%. In the past JimH has said that the issue is a driver issue and “not an MC issue”; but I think this is disingenuous, because if you look in Task Manager it says that it is the MC process which is using 100% GPU, and not some other Windows process. Therefore I think JRiver needs to step up to the plate on this.
The issue seems to build up over time during periods when the HDMI downstream devices are turned off. So my hypothesis is that during these times there is some kind of thread leak, that causes MCs GPU usage to slowly rise until it tanks at 100%.
We're all speculating here, but I believe that a video driver that had a memory leak could explain this.
One reason I say this is that the problem seems to affect just a few people.
What video hardware are you using?
The problems of HDMI are well known and there are some devices sold that will make Windows think the display device is unchanged. Try Google for EDID emulator. Geffen is one source.
It would help if all three of you could compare hardware to see if there's anything in common. RD James' problem may be different since it's in Standard View.
-
Theater view issue:
Not drivers. Not GPU specific. Happens on my Server (nvidia 1060 all versions of drivers since problem reported years ago), and 3 Clients (1 nvidia 640 all drivers, and 2 amd). Happened back when MC used Direct 3D, still happening with OpenGL.
https://yabb.jriver.com/interact/index.php/topic,116118
https://yabb.jriver.com/interact/index.php/topic,112003
Original problem started (twice) by County Bumpkin and confirmed by RoderickGI, and Wer... Now AndrewFG! If they can reproduce it, why can't Hendrik? Try leaving a MC pc machine running (no sleep) in theater view for 3 to 4 days without any input mouse/remote/keyboard, then walk over and try to navigate in theater view (L/R/U/D/Enter). The screen will just blurrrr, only way to get out is ESC out of theater view.
Hopefully Hendrick's next attempt will fix it! Thank you
-
Now AndrewFG! If they can reproduce it, why can't Hendrik? Try leaving a MC pc machine running (no sleep) in theater view for 3 to 4 days without any input mouse/remote/keyboard, then walk over and try to navigate in theater view (L/R/U/D/Enter). The screen will just blurrrr, only way to get out is ESC out of theater view.
Why would you do that (not let the PC sleep when not in use)?
-
HDMI hand shake? PC not sleeping but AV equipment (TV and/or receiver) go to sleep or get turn off?
does it happen on PC that are not connected by HDMI?
-
HDMI hand shake? PC not sleeping but AV equipment (TV and/or receiver) go to sleep or get turn off?
does it happen on PC that are not connected by HDMI?
No, but how are your computers connected to TV's?
-
Sleeping my Server is not an option, too many Tv processes going on - serving clients, guide downloads, library backups, shows recording, etc. Sleeping clients just introduces other bugs - hoping/waiting for the server to wake, hard to wake client pc with remote, hdmi handshake problems with tv, sometimes new tv recordings not showing up, etc. Maybe there are fixes for those, and I could work around them. But for a guest trying to use the tv for the first time, it's so much simpler for them to walk in the room and just power On the Tv and have MC on the screen ready to go.
-
Why would you do that (not let the PC sleep when not in use)?
Because MC clients never used to wake up a sleeping server without restarting the client and MC clients (with MC or a remote) generally provide no info about server side errors so it made for a v user unfriendly experience. Has this been improved over the last few years?
-
I can confirm that this problem, which goes back years and which I commented on extensively and provided a workaround in the other referenced thread, is not driver or HDMI sink/handshake specific.
It happens:
-With both AMD and Nvidia drivers
-With multiple driver versions, separated by years of development
-When the PC is not allowed to sleep
-With Windows 7 and 10
-With an EDID emulator (Dr HDMI) attached or not
-
Why would you do that (not let the PC sleep when not in use)?
Because it is also a server for other clients and renderers.
-
Any drives unavailable or misbehaving?
No, everything is present and nothing in the setup has changed.
Why would you do that (not let the PC sleep when not in use)?
It's a server for more than just Media Center, and is nearly always doing something.
But the main reason is that I was having to replace several HDDs per year when I was letting them and/or the computer itself go to sleep regularly.
I don't want to tempt fate, but I haven't had a drive die since making that change several years ago now. It's far cheaper to keep the PC running than it is to replace the drives.
-
But the main reason is that I was having to replace several HDDs per year when I was letting them and/or the computer itself go to sleep regularly.
I've never seen a scientific analysis that supports that.
-
^
Gentlemen, please let’s not get off track. :)
-
Well in my case , it does not even need to be run for hours. just 2-3 blurays song rips (m2ts files in pass-thru mode) of 3-4 minutes each and the entire system freezes. i had tried to raise this issue in my earlier threads too.
Since i have re tested with older versions of MC like mc23 too, i feel MC has not been able to keep track of some change which has crept in Windows 10 about 1.5 yrs back (i started having issues since then only).
here's the other thread where i tried to raise this issue : https://yabb.jriver.com/interact/index.php/topic,123039.0.html
-
Just for info: I am currently testing a workaround. In my Logitech Harmony remote I have added extra commands in the scene scripts as follows:
1) In the scene shutdown script before sending the commands to power off the TV and the receiver, it now also sends to the MC HTPC the IR commands “Clear” followed by “Enter” — which takes MC out of TheaterView before turning off the downstream HDMI devices.
(note: to be precise I was already sending a “Stop” command to MC to halt streaming of audio data to the missing downstream HDMI devices; so I am now sending “Stop” / “Clear” / “Enter”)
2) In the scene startup script after sending the commands to power on the TV and the receiver, it now also sends to the MC HTPC the IR command “GreenButton” — which puts MC back into TheaterView.
I realise that this work around might not be the cure for everybody. Especially if you don’t have a programmable remote. But it might work for some. Anyway, I am planning to run this for a couple of weeks, and if it really does work (around) then I will report back here.
-
It would be nice if you could test 26.0.16 for a while without workarounds, once its available in a couple of days.
-
It would be nice if you could test 26.0.16 for a while without workarounds, once its available in a couple of days.
Ok Hendrik, I will do that.
-
Still waiting for the new build, but I've also found that JRemote on iOS becomes completely unusable when MC starts to slow down - so it's not just the PC client's UI which is affected.
JRemote stops loading thumbnails at all, and either doesn't open views or it stops displaying anything.
I'm not sure why, but I also noticed that when browsing albums in JRemote, it's accessing every single track on the disk while browsing.
Shouldn't that be a database operation? Loading the track list via the database, and thumbnails via the cache?
All tracks have now been moved to SSDs, but that hasn't made a difference.
-
Still waiting for the new build, but I've also found that JRemote on iOS becomes completely unusable when MC starts to slow down - so it's not just the PC client's UI which is affected.
JRemote stops loading thumbnails at all, and either doesn't open views or it stops displaying anything.
Thats definitely unrelated to any fix we talked above. I have no idea how any such operations would get so slow that JRemote wont work anymore.
-
Thats definitely unrelated to any fix we talked above. I have no idea how any such operations would get so slow that JRemote wont work anymore.
Well that's disappointing to hear.
I'm not sure why, but I also noticed that when browsing albums in JRemote, it's accessing every single track on the disk while browsing.
Shouldn't that be a database operation? Loading the track list via the database, and thumbnails via the cache?
All tracks have now been moved to SSDs, but that hasn't made a difference.
Following up on this: it seems that it's only happening with the two largest thumbnail sizes in JRemote on iPad when it's horizontal, or the largest one when vertical.
My guess is that MC's thumbnail cache is not high enough resolution for these views, which is why it's hitting the disk even though I have created a thumbnail cache for every file in the library.
But it's not the cause for views in JRemote becoming unresponsive or not working at all. As I said, those files are now on SSDs.
After restarting MC, JRemote running as fast as it should, even when it is building thumbnails off the disk.
(though it'd be nice if the thumbnail display in JRemote could update more than one icon at a time - which is slow even if it loads off the cache)
-
Following up on this: it seems that it's only happening with the two largest thumbnail sizes in JRemote on iPad when it's horizontal, or the largest one when vertical.
My guess is that MC's thumbnail cache is not high enough resolution for these views, which is why it's hitting the disk even though I have created a thumbnail cache for every file in the library.
Its possible that JRemote itself switches to requesting the full original image in that mode, which are not cached. I don't know the internal calls of JRemote on iOS. But thats the only realistic option where it would load it directly from the file.
Also are we talking about thumbnails of individual tracks, ie. in a track listing, or images in a browse view, of eg. a list of albums, or something like that?
-
Its possible that JRemote itself switches to requesting the full original image in that mode, which are not cached. I don't know the internal calls of JRemote on iOS. But thats the only realistic option where it would load it directly from the file.
Also are we talking about thumbnails of individual tracks, ie. in a track listing, or images in a browse view, of eg. a list of albums, or something like that?
Browsing a list of albums, but only at the largest thumbnail sizes.
It seems like it's only hitting one track per album (as you'd expect) but it's not always track #1 for some reason.
This should probably be split off to its own discussion though, as it doesn't seem related to MC slowing down. I just noticed it when trying to see why JRemote was running so slow/breaking.
-
For the avoidance of doubt: in my case I observe only a tremendous slow down of the UI navigation in TheaterView, and I have never* encountered slow down issues navigating with JRemote, nor with playing music, nor with serving tracks to other MC clients, or other renderers.
That’s why I tend to suspect the problem is due to overloading of the GPU rather than overloading of the CPU or the disk/file system.
*) the only times I have encountered slow downs on those other activities, is when rebuilding thumbnails or analysing audio; but my PC is definitely NOT doing any of that at this time.
In other words, I think the two issues are unrelated. (Although I suppose if the PC did not have a fully dedicated GPU chip, then the 3D graphics rendering might have an impact on the CPU; but honestly I don’t know if such machines exist; maybe on simpler PCs like the Raspberry Pi ??)
-
In other words, I think the two issues are unrelated.
As I said, I don't use Theater View.
Here's a short clip of the problem: https://www.youtube.com/watch?v=xc4ho5rqw2o
I right-click to bring up the menu when the cursor stops moving.
And this video is not half as bad as it gets sometimes.
-
RD:
What I am about to say, I mean in a constructive way.
You seem to have some unusual problem reports on your system. You also seem to be gaming a lot on that same system. For example, you showed some kind of frame rate/video problem in a previous thread and then substantiated it with a frame rate checker tool. I believe you also talked about the interaction of MC during gaming in that same thread. Something like, it works just fine until you engage certain games, then odd stuff happens with the video.
So, it might be useful to discuss what, if anything, about your video setup is customized or non-standard. Like beta drivers, or anything special you had to load for games, etc. I also recall (perhaps incorrectly) that you were doing 10 bit video on one of your systems. If you've done anything to video or other subsystems to make that work, it would be worth sharing.
Good luck to you,
Brian.
-
So, it might be useful to discuss what, if anything, about your video setup is customized or non-standard. Like beta drivers, or anything special you had to load for games, etc. I also recall (perhaps incorrectly) that you were doing 10 bit video on one of your systems. If you've done anything to video or other subsystems to make that work, it would be worth sharing.
I'm using the standard NVIDIA drivers - the "studio" branch since those are tested more thoroughly for stability and updated less frequently.
My current monitor is 8-bit, though my projector and TV will do 10-bit. It doesn't make a difference what display it's connected to though.
There isn't really anything non-standard about this setup.
That said, I've tracked it down to the Sonarworks VST Plug-in.
I upgraded my license from a headphone-only one, to headphones+speakers right around the same time that MC26 was released, and that required me to update the software.
I don't know when the change occurred, but the old 4.1.0 plug-in works fine, while the latest 4.4.2 plug-in is causing this lag in Media Center.
The reason that it sometimes feels like it's only happening after the program has been running for hours, is that I don't use the plug-in in all of my zones and the lag only starts when playback does.
-
Glad to hear you isolated your issue.
Sounds like MC might still have something going on in Theater View. But good that your issue is at least known if not resolved.
Brian.
-
I'm having the same problem with the SonarWorks VST. It doesn't even seem to matter if the plugin is activated. Just installing it slows the UI to a crawl. Has anyone found a solution or is this being looked at?
-
You need to contact the publisher of the plugin.
-
Added to Weird and Wonderful (https://yabb.jriver.com/interact/index.php/topic,24031.msg870761.html#msg870761) (WaW)