MediaMonkey forum

I had about 7,000 ALAC files that I wanted to do editing of tags with.
I did several passes through the whole set with no problems, but then, out of the blue, MM started bogging down.
When editing, say artist name or album title, for a handful of files, it started taking extraordinary amounts of time to apply the updates.
I went back to look at the 7,000 files, and found that a bit over 1,000 of them (in random locations throughout the library) had been zero'd out (file sizes before were in the 20-30mb range; afterwards, what was left was 2-3kb).
The rest of the files (all of them from the same source) were fine, with all of the tag-edits applied.
For all, I'd done nothing but edit a few fields and hit Ctrl-S to sync the tags.
I did a full rescan in MM, and it looked normal except that exactly 2 files in MM's library showed as having no tags at all.
Very, very weird.
Should I be afraid of ALAC?
What would cause MM to completely overwrite all these files?

Are you saying that this app destroyed your music files?

Yes .. totally.

Which version of MediaMonkey and is the MM Codec Pack installed?

At that time, I was using: MediaMonkey_4.1.5.1719 (2014-10-22).exe
After the errors, I put in: MediaMonkey_4.1.6.1736 (2015-03-03).exe
I am trying to recreate the situation & am checking the ALACs (now!)

Sorry ...
I am using K-Lite.

It would be a serious bug so it would be best to capture the proceedings in a debug log (step 4b) and if you reproduce it send the log to support: http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=69

Obviously you should work on copies of files so if things go wrong you have a backup to restore.

restored from backup & running 1 album at a time
first 2 are ok .. only 498 to go
it may be awhile

Oddities:
I edited tags on several thousand files, one album at a time, with no errors.
Finally, today, on one album, 5 out of 8 files got zero'd.
So, I downloaded "DebugView (v4.81) - MS-TechNet.zip" and ran it.
I restored the 5 files from backup, and re-ran the edits in MediaMonkey.
Unfortunately, this time, the editing went fine .. tags updated; files saved cleanly.
Huh?
All I was doing was calling up the properties box, and editing
album-name, grouping, favorites, and comments.
I didn't do a system restart. All I did was shut down MM, copy back the files, run DebugView, and restart MM, and rerun the edits on the same set of files, followed by a Ctrl-S.
The only thing I can say about the whole process is that the first time through, after I closed the properties box, MM seemed to hang with the "# files to be tagged" showing

Now, I didn't read the "how to report a bug" thoroughly enough.
I did get the DebugView, but I didn't get the debug-build of MediaMonkey (until after),
but that's neither here nor there, at this point.
Since I can't repeat the errors, again, consistently or otherwise, I seem to be mooted.

I do have a question, though:
Can I run the debug-build of MM full-time, installing it over the existing copy,
or am I going to have to go back and forth, with re-installations.
If I do have to do re-installs, will all my other work (eg, INI edits) survive?

I'll keep at it (I do want the files edited anyway), but I'm not seeing anything useful I can do.

Another question is raised:
Since it's so difficult here to rely on background processes, like edits being written to files,
I will, of course, edit in smaller batches and try to check results.
It would be nice if there was some way of generating a report about recent file changes.
I have no way of knowing things are mis-happening except by searching for files that are too small.
I manually run a full-system scan for all files under a certain size. This is fantastically tedious and error-prone.
So, is there some way I can get MM to report on exceptions, or at least to generate a log of files that I should check for exceptions?

Yes, you can run the debug version of MediaMonkey full time (I do), it may be marginally slower, but works the same.

From what you're reporting I presume the bug lies in doing too many file operations in close sequence, possibly doing multiple edits on the same file and that's what's causing the problem.

You've got Timestamp that indicates when a file was modified by MediaMonkey.

Bug: http://www.ventismedia.com/mantis/view.php?id=12654

okey dokey
I'll come back to this, if & when, maybe, but am assuming no bugs here.
Thanks for all the help.

I recreated the errors & opened a trouble-ticket: Ticket ID #FSL-488-54872
It's looking like a real bug.
I'm really hoping (profoundly) that it's only ALACs.
That's bad enough.
If it's all .M4As, there are far bigger issues.
It's definitely in MediaMonkey .. I did several run throughs, after simplifying my set up.
I tried to upload the "before" .m4a files, but I guess they're too big (about 100mb).
But the "after" files are there (about 200k each).
Anyway ...

This is "getting" serious.

To recap:
A simple edit, even just of an Artist-Name field, in MM is accepted.
MM might slow down for a bit, but the resulting MM library-entry looks ok.
The resulting file on disk is 100-times smaller than what you started with.
Obviously, files are getting corrupted.
So far, I've only had this happen with .m4a files identified as ALACs.
(this happened with both the current 4.1.6.1736 and prior 4.1.5.1719).

Two Questions:
Has anyone seen anything similar, especially with non-ALACs?
Can I exclude all ALACs (or maybe just all .m4a's) from on-going operations?
(in order to have stuff to do while leaving these out till the problems fixed)

I have a trouble-ticket open, and they seem to be working on it, but no smiles so far.

KyleHxAgain wrote:Two Questions:
Has anyone seen anything similar, especially with non-ALACs?
Can I exclude all ALACs (or maybe just all .m4a's) from on-going operations?
(in order to have stuff to do while leaving these out till the problems fixed)

1. I haven't seen anything like that
2. Create a collection (gold) with an exclusion rule(s) for extension. If free, try to edit the "music" collection to include the same exclusion rule.
(work inside created collection or Music collection).

I've been working at the Help Desk on an on-going issue.
They certainly seem to be working at it, but no joy so far.

What's happening is that tag-editing ALAC files intermittently results in those files being corrupted.
A 32mb file, after editing, ends up at something like 300k.
It seems that all that got saved to disk was the metadata info .. the sound data was deleted.
In MM, the entry looks normal, until you try to play it (or look at the filesize).

These has only happened with ALAC files (which are to .m4a as FLAC is to .mp3).
It hasn't happened (to me) with .mp4 nor .mov files (I don't have any .m4b files).

I'm very frustrated, and the people at the Help Desk are stumped.
I'd really like to hear of anyone having similar issues.
We've done many hours of debugging, and have re-created the problem (very intermittently), but can still find nothing to point at as the cause.

Ey?