Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Headcool]

One of the issues I have with MC since years is the tagging functionality. When I have to tag lots of files (e.g. after importing; removing inconsistencies between database and files) MC is often unstable. Sometimes this does work well (beyond the fact that the statusbar at the bottom is clobbered), sometimes Windows tells me that MC does not respond and if I want to kill it. If I don't decide to kill the process I have to wait until the tagging has finished so that I can use MC again. If I kill MC, the database and the metadata in or by the files are inconsistent.
I would suggest following:
1) The tagging should run in a background thread, with a lower priority (both process and io priority) than MC. The progress should be indicated at the left bottom where the action window, tag windows, etc are.
2) MC should always preserve a list of files, where the metadata has to be updated from the library. This list is stored persistently somewhere in the appdata folder. If MC is ended gracefully or shutdown in any other way, this list can be read again when starting MC the next time. This would allow the library and the metadata to stay consistent. It would also eliminate most usages of "update tags from library" which is slow because of reasons.
3) Same is true for cover art. "Save cover art to external location specified in the options" is a slow process and is only necessary because of inconsistencies with the library. At any point where the cover art is changed, it should be automatically be saved there. This way, I don't have to invoke this command on thousands of albums, because a small percentage of arbitray albums don't have the cover stored because I changed it.

[~OHM~]

tell us about your pc specs please

[Headcool]

CPU: i7 4470k
RAM: 16GB
GPU: GTX 1080 Ti
System HDD: 1TB Samsung Evo 840
Library HDD: 4TB HGST Deskstar 7K4000

I don't think that the hardware is the problem. Writing the tags is basically random acces to the hard drive, which is slow no matter what. Since my library contains lots of audiobooks it also contains lots of files. A 20 hour audiobook split into 5 min files contains 240 files. Therefore, updating the tags on about 100 audiobooks means writing tags for 24k files. But the speed is not the problem. The stability and robustness is.

[Spike1000]

My 2p.

I tag outside of MC with MP3Tag (I've been using MP3Tag for years and have it customised so it's very very efficient for my workflow) and then just run a manual auto-update to update the MC database. I have no stability issues doing this.

I doubt the internal engineering of the MC tagging engine will change anytime soon so a workaround may be your only option.
 
Spike

[RoderickGI]

While MC can have its moments, this;

<snip> (beyond the fact that the statusbar at the bottom is clobbered) <snip>

points more toward Windows, or some other application, or a combination of Windows and some other application causing a problem. If that is the case no amount of hardware will fix the issue. I've seen my PC sit at zero percent CPU usage, and still waiting, waiting, waiting for something to happen so that I can get on with whatever was next. It isn't MC, it is something else.

Very likely this, given the comment above: https://yabb.jriver.com/interact/index.php/topic,113034.0.html

An obvious one is; Do you have a virus scanner, and is it scanning all your media files? Because if it is, every time a tag is updated in a file (or several hundred, or thousand), the virus scanner scans the file. That is going to slow down Windows and MC far more than any other MC function. Exclude your media file locations from your virus scanner. If you import risky files, dump them into a location that is scanned, scan them, and then move them.

While tagging can take a while to complete, it needs to be allowed to complete or naturally the file tags and library will be out of sync. I haven't seen tagging make MC unstable once it completes though. But if I try to do lots of things at once on the Server and Client I can get it to "White out" and have to wait for it. Generally I find MC pretty fast in all library functions, except where it is writing a lot of data, or data to a lot of files. Any program would have to wait for disk activity and Windows.

[Headcool]

@RoderickGI

I'm not talking about the Windows taskbar. I am talking about MCs statusbar which normally shows thinks like  "x Files (y GB - z hours)" depending of the current selection. If MC writes tags to the disk, it writes the status of tagging updates into this bar. In result I can't see how many files are selected, which might break my work flow. Most operations in MC write their status and their progress into a new small window to the position where also the Action Window and the Display windows reside.

About AV: My AV excludes MC. However this should not be a problem regardless of the used AV. As developer you have to take into account that a reading a file might take a vast range of possible time spans to complete. If the file is in the memory it might take only 1us to read it. On a SSD it might take 100us, on a HDD it might take 10ms. On a network mapped drive it might take 100ms and on a cloud drive it might even take multiple seconds.
However, this is not a problem, because the thread that waits for the file to read and the file to write is not the thread that renders the GUI (that is how it should be and not how MC implemented it). And therefore the GUI thread will always react to the messages Windows will send it. Therefore, Windows will not think that MC is not responding because it actually is responding.

This also has nothing to do with the speed of tagging which is indeed I/O bound. But such things should be always handled async with the GUI.
I also think that not resuming the updating of the tags after a crash is a bad practice. It leaves library and file tags out of sync, which could result in problems later on.

[RoderickGI]

Yep, I understand all that. I just haven't seen the MC StatusBar clobbered during tagging.

There has been a few discussion about how multi-thread MC is or isn't, and how much is done in the "Main thread" versus other threads. I guess JRiver have a reason for leaving tagging in the main thread. But your points are valid. Recovery from a crash situation is almost expected these days in an application.

This is really one for the developers and Jim.

[Headcool]

If I select a certain amount of files and change the tags of these files, MC will write following line into the status bar:
Saving tag changes (x remaining)
Since this will be updated when x is reduced, which happens multiple times every second, this message clobbers the information I really want to see.

[RoderickGI]

Since this will be updated when x is reduced, which happens multiple times every second, this message clobbers the information I really want to see.

Now I understand. Forgive me. I can be a bit slow on the uptake!