I think this problem might apply on my system with beta 4.05.90.
PC is XP3 with 3.5 gb Ram + 4 gb swap in Ram. i7/x58. Hard disk is data (not only audio) dedicated, hence 4kb clusters. 2TB. Healthy, contiguous file system.
Couldn't reproduce it but I once saw the whole 7 GB of virtual memory being used while doing some heavy work in MM. Don't know how MM handles memory but if there was a fix to deal with the 2 gb limit, it might have worked a bit too well... I think it was beta 4.05.89 at the time.
MM Database in ram, along temp files, thumbnails and such. FWIW, that virtual disk pushes 13 GB/s and has virtually instant access/seek time, compared with a hard disk, not just in benchmarks but in every real time application that uses it.
Db got bumped up to 1gB in size, right after I copied MusicIp cpuid in custom field. Was a bad idea but makes for a great troubleshooting system.
I have a large db then: 230.000 entries. Despite this, everything "read related" is super fast : very good (better than MM3.2.5) tree-panel action with lots of "tree nodes-scripts" and collections. 1 second MM launch and ready time. Instant searches and auto playlists.
Writing is something else. First, disk writes seem to occur even when none should. At the least, MM seems to do some background work while doing any db edits. cpu idles at 12.5% (4 cores + HT).
I sometimes notice a progress bar for database update while editing large selections (1000+). I think it's too long since there is no disk access at all. Progress bar states it's updating db entries.
A fair example would be to change the season field from "03" to "3" for a whole TV show season [worth noting that column explorer displays two different seasons in that case], say 20 episodes. MM will just sit there, Gui unresponsive, doing apparently nothing for 1 minute, maybe more, displaying 12.5% cpu usage in task manager. Reorganizing on the same drive stalls MM as well and takes longer than renaming should. The slow performance applies to audio and video files, ony more noticeable with videos.mask for music :
mask for video:
- Code: Select all
t:\Data\Ma musique\Songs\<Extension>\<Genre>\<Artiste de l'album>\$If(<Année>,[<Année>] )<Album>$If(<Disque n°>,\Disque <Disque n°:2>)\<Piste n°:3>$If(<Artiste><><Artiste de l'album>, - <Artiste>) - <Titre>$If(<Extension><>mp3, [<BPM:3>bpm])
- Code: Select all
T:\Data\mes Vidéos\Films\$If(<Séries>,<Séries>,<Titre> - <Réalisateur>$If(<Année>, [<Année>]))\$If(<Séries>,$If(<Année>,[<Année>] )<Réalisateur> - <Titre> - $First(<Acteur>,2),Film $If(<Disque n°>, - Part <Disque n°> )(Avec $First(<Acteur>,2)))
Not sure is this should slow down the renaming process, but this looks nothing like heavy processing for a i7 cpu.
TV shows have a straight mask (T:\Data\mes Vidéos\TV\<Séries>\Saison <Saison n°>\<Episode n°> - <Titre>) and reorganizing is just as painful.
Editing album arts freezes the Gui in the same manner; video still worse than audio.
The "stall time" appears to be proportional to selection size. The "Gui freezing" as well, meaning that MM will hang worse as the selection grows. Past a certain selection size, graphic corruption will occur and task manager will behave erratic. Windows explorer might hang as well on large edits, though it's not clear if patience would allow the system to recover. Other running programs do not seem to be hindered, as long as explorer and task manager allow access to them. After killing MM (when no more cpu cycles in use and gui still frozen), system sometimes
needs a reboot, for MM will "fail to create image" at next launch. And "fail to initialize player" when nonskinned.
With db on ram and SQLiteSafety=0, you bet I'm doing 12 backups a day and then some... I'd like to help and troubleshoot this on my specific system. I probably need a couple of instructions on how to report this in a usable format.
I had to re-enable real time tagging. I then noticed that the behavior was no different than when disabled, except I could see the disk progress bar. Might it be that there is a small bug that would break "disable tagging ? In which case, behavior is almost normal, only a bit slow, like 300-400%, apart from the sluggish/frozen gui while tagging.
If that's all there is to it, might I suggest something being done about video files NOT being tagged as default. These need more editing steps than audio and MM does not appear to be ready to handle that task as transparently as with audio files. I don't suppose it should be expected to, video files being what they are.
I experimented with movies first, quite straight forward to tag but still more steps than audio. I then tried my luck with TV shows : this is where the fun begins, with different directors, writers, even actors per episode.
There is no way yet to tag TV shows in a few sweeps, unless someone comes up with some jmdb script. Which btw would be very nice. I wish I could write code and be the one ...
Bottom line :
My take on the problem reported here, is that it might be related to tagging.
Tagging the same video file over and over is just ridiculous, by design; it only makes it worse that it takes too much time and freezes gui.
While typing this edit, MM just tagged 1500 files, Flac and Mp3. That's still quite slow (I type slowly), considering the running system but that's quite acceptable.
What I might like to look into :
- frozen gui while tagging.
- disabling auto-tagging looks broken
- Tagging video should be a separate option, default should probably be off, maybe with a context item to freshen disk data.
I will install and troubleshoot the first beta release that include any of those fixes.
Maybe, if the problems reported here can be reproduced, a dedicated thread would be useful?