You may want capture the behavior in a debug log (step 4b) and send the log to support: http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=69

Lowlander wrote:Are you saying the freezing occurred using Auto-Organize Files on read-only files?

Sorry to resurrect this thread after so long, but I never checked back for replies after posting my initial report. To answer your question, no, freezing occurs once a startup scan is in process if any files are locked by the file system (in use by say Winamp or another media player) or otherwise read-only and you attempt to do anything in MediaMonkey which also makes use of it's database / library.

Meaning - in short, i have to wait for my startup scan / monitoring pass to complete before i do anything in MM to avoid the risk of a complete lockup. This issue is present up to version 4.1.4.170x. Not tested with the latest version yet as I've only just applied the update.

Any moving files would fail on read-only folders/files as it won't allow the files to be deleted after the move. Any tagging would also fail to update the files (database would be updated). Unless you're trying to protect files from editing/deletion you should not have them read-only (and I'm not aware that MM rips them to be read-only).

Lowlander wrote:Are you saying the freezing occurred using Auto-Organize Files on read-only files?

I noticed that most of my music folders are "read only". I assume this is by default when you rip an CD through itunes or MM?
Does your question above imply that you should not try to auto-organize files in read-only folders? Do I need to modify the permissions in the folders w/my music before I try moving them around w/ mediamonkey?

Are you saying the freezing occurred using Auto-Organize Files on read-only files?

With regards the crashing issue. I think that's a permissions issue. I store my media on a ReadyNAS Pro, syncing to a local folder via Rsync / DeltaCopy. However, "pulling" files to the local machine (as a pose to pushing files from the NAS) doesn't work properly as DeltaCopy doesn't set file permissions properly during a "Restore" operation, so MM and Windows in general can't access the files until a "Take Ownership" command is paseed on the suspect folder. However no error messages are generated by MM saying it can't access the files/folders. But since fixing the permissions I've had no crashes / freezes of this nature.

Looks like that's the one.

Seems to happen more towards the beginning of a run though. If MM has been open a while and no databases accesses are happening, it works every time. But as stated, on the one time my friend tried it (yes we're both using Art + Details View) he clicked OK instead of cancel, and MM deleted the album outright. No recycle bin.

I presume you're using Auto-Organize Files and are in the Art with Details view, if so you're probably seeing: http://www.ventismedia.com/mantis/view.php?id=11965

I don't understand. How do you reproduce this problem? It sounds like you mean if you use auto-organize multiple times while MM is open, after the first time it can delete your files. But that can't be the case, no one else has reported anything like that and I can't reproduce it.

With the current version of MM (4.10.1692) there is a serious bug with the Auto Organize functionality built into MM.

When doing a "Move" files to new path, The process will complete successfully for the first attempt. For the second attempt (i.e: differing album / files from first attempt, or indeed same files, but different move settings), the file list will be blank. Nothing in source or destination. It is nessecary to exit out of MM, and restart it to get it to correctly show the files source and destination.

If "OK" is selected, when nothing appears in the source / destination parts of the dialog box instead of "Cancel", MM will assume the files have been moved and DELETE the source files regardless, even though NO movement of those source files has taken place.

I have witnessed the above (first paragraph) multiple times on my own PC, and my friend who i've been introducing MM to was unfortunate enough to have at least one album deleted by this bug.

There's also an general stability issue with large libraries, where MM is hanging when clicking on an album after the re-scan / monitoring stage at start-up, but this may be down to a corrupted/problematic Db so will hold off on this issue for now.