INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Freezes when running "Update tags from library" for large music collection  (Read 2385 times)

kosmik

  • Recent member
  • *
  • Posts: 21

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

Awesome Donkey

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 7812
  • Autumn shade...

It's probably not frozen, just working in the background. It'll probably take awhile.
Logged
I don't work for JRiver... I help keep the forums safe from "male enhancements" and other sources of sketchy pharmaceuticals.

Windows 11 24H2 Update 64-bit + Ubuntu 24.10 Oracular Oriole 64-bit | Windows 11 24H2 Update 64-bit (Intel N305 Fanless NUC 16GB RAM/500GB M.2 NVMe SSD)
JRiver Media Center 33 (Windows + Linux) | iFi ZEN DAC 3 | JBL 306P MkII Studio Monitors | Audio-Technica ATH-M50x Headphones

kosmik

  • Recent member
  • *
  • Posts: 21

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

Awesome Donkey

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 7812
  • Autumn shade...

It's actually not frozen, it's just busy until the task completes. ;)
Logged
I don't work for JRiver... I help keep the forums safe from "male enhancements" and other sources of sketchy pharmaceuticals.

Windows 11 24H2 Update 64-bit + Ubuntu 24.10 Oracular Oriole 64-bit | Windows 11 24H2 Update 64-bit (Intel N305 Fanless NUC 16GB RAM/500GB M.2 NVMe SSD)
JRiver Media Center 33 (Windows + Linux) | iFi ZEN DAC 3 | JBL 306P MkII Studio Monitors | Audio-Technica ATH-M50x Headphones

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72444
  • Where did I put my teeth?

It's actually not frozen, it's just busy until the task completes. ;)
And Windows should know better.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

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.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 10942

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.
Logged
~ nevcairiel
~ Author of LAV Filters

kosmik

  • Recent member
  • *
  • Posts: 21

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

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

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.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

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.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/
Pages: [1]   Go Up