INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Windows => Topic started by: kosmik on March 03, 2015, 01:59:40 pm
-
I have around 300 albums in my collection, mostly in FLACs. After running into problems with cover art on my ZX2 (some of tracks had cover art in external files and when transferring to handheld device which supports FLACs, tags were not updated) I decided to update tags from library.
Now 30 minutes passed and I still see MC not responding and Resource Monitor shows that it's in fact reshuffling files.
It would be really great if it didn't lock up but shown some kind of progress indication.
-
It's probably not frozen, just working in the background. It'll probably take awhile.
-
It looks frozen and Windows report this.
It looks like this:
* initially there is a progress indication counting files, on around 400 out of 4000 it disappears
* MC freezes for half an hour while it's reshuffling stuff
* then after half an hour it unfreezes
It's fine with me because I know how to use perf monitor etc, but a non-technical person could just follow Windows suggestion and kill process. I wonder in which state library will be after that...
-
It's actually not frozen, it's just busy until the task completes. ;)
-
It's actually not frozen, it's just busy until the task completes. ;)
And Windows should know better.
-
And Windows should know better.
If you actually read the dialog, Windows says it might be busy or might be frozen. That is true. Windows can't tell the difference between an application that is too busy to update its UI and one that is permanently hung. People just think whenever they see this dialog now that it means the program is crashed.
Back in the old days, this wasn't a problem because PCs were so slow at all tasks that they regularly behaved in this manner. The "problem" is that most PCs are now wildly overpowered for the tasks regular humans do most of the time, so when they do actually bump something that is "heavy" and results in non-responsive UI (like pounding the disk with access to update all in-file tags across possibly hundreds-of-thousands of files), then people get confused because: "it never does this in my web browser or in Word".
Yeah, because those applications hardly ever touch the disk, and they might consume 15% of the CPU time even at peak load.
-
Technically, its bad behavior of an app to lock its UI thread with "work", however unfortunately some parts of MC will do this and sometimes you have to wait it out.
In a perfect world, all this "work" would be done on background worker threads and the UI would remain responsive, but with an app as huge as MC, there is some parts which aren't quite as perfect.
We try to change this whenever possible, but sometimes its such a huge undertaking and only visible in extreme circumstances (like tagging a huge library in one go), that it gets put further down on the long list of things to do.
-
It seems related not to the size of collection, but to number of changes.
I'm re-running this operation again and again when I find and fix broken stuff (e.g. album in the single FLAC+CUE file), and now it doesn't lock up that long.
However another related thing is that it keeps "Saving tag changes (33 remaining)" for really long time even though I don't see any significant disk activity for MC process.
-
Technically, its bad behavior of an app to lock its UI thread with "work", however unfortunately some parts of MC will do this and sometimes you have to wait it out.
In a perfect world, all this "work" would be done on background worker threads and the UI would remain responsive, but with an app as huge as MC, there is some parts which aren't quite as perfect.
We try to change this whenever possible, but sometimes its such a huge undertaking and only visible in extreme circumstances (like tagging a huge library in one go), that it gets put further down on the long list of things to do.
Right. I didn't mean it was perfect. Just that crashed and busy aren't the same thing.
-
However another related thing is that it keeps "Saving tag changes (33 remaining)" for really long time even though I don't see any significant disk activity for MC process.
This is typically an indicator of a locked file. One that is being actively played, usually, though there can be other causes.