Yes, both will be included in 4.1.17:
- the delay: http://www.ventismedia.com/mantis/view.php?id=14248
- the slow tag reading: http://www.ventismedia.com/mantis/view.php?id=14247

Thanks for the testing and your time!

I have been running MM 4.1.16 (non debug) with id3lib.dll from 4.1.15 (non debug) today and so far have not had any auto-organize errors.

I would suggest leaving the delay and retry code in place to catch the rare occasion when move/rename fails.

Thanks for the log!

Could you please replace id3lib.dll from 4.1.16 by id3lib.dll from 4.1.15 to see whether it resolves the issue?
It looks like consequence of http://www.ventismedia.com/mantis/view.php?id=14247

Hi Ludek,

I reverted to MM 4.1.15 last night and have been running it all day without a single rename/move failiure.

This evening I installed MM 4.1.16 debug and ran dbgview. Within minutes I had captured a rename/move failure so it realy looks like it is a MM 4.1.16 problem.

I have submitted a ticket with the debug log attached (#JEF-905-20231).

I hope it helps you get to the root cause of the problem.

PeterCM wrote:Since installing the custom 4.1.16 I have not seen the auto-organize error message so it seems the delay you put in is long enough.

Thanks for confirmation, I commited the change (100ms auto-try) as http://www.ventismedia.com/mantis/view.php?id=14248 (will be in 4.1.17)

PeterCM wrote: I have seen the auto-organize error message with 4.1.15 but only 4 to 5 times in six months.

OK, I guess it could be a coincidence?

Since installing the custom 4.1.16 I have not seen the auto-organize error message so it seems the delay you put in is long enough.

I have seen the auto-organize error message with 4.1.15 but only 4 to 5 times in six months. I will revert to 4.1.15 debug and see if the error is occuring. After testing 4.1.15 I will install 4.1.16 debug and capture a debug log log.

PeterCM wrote: Something must have changed with the new version of MM as this error was not occuring in the previous build.

I am not aware of any change between 4.1.15 and 4.1.16 that could have impact on this.
Could you please do some tests with 4.1.15 debug to ensure that the error really doesn't happen and generate a log when auto-organizing.
And then do the same with 4.1.16 debug and generate log and stop it once the error appears?

Thanks!

PeterCM wrote: I will download the custom exe you made and give it a try. Is this custom build compiled as a debug version?

Yes, it is debug version.

I use auto-organize to get the file names corectly formatted after updating the tags. I also use auto-organize to move files into sub folders like CD1, CD2 etc. when it is a multi-disk album that has all it's files dumped into the same directory. There is no active editing on the files at the time I run the auto-organize, also not playing any of the files either.

Could you not put a more descriptive message in the error popup so we can see what the reason is for the error mesage. It could be that tag editing has not released the handle to the file. Something must have changed with the new version of MM as this error was not occuring in the previous build.

I will download the custom exe you made and give it a try. Is this custom build compiled as a debug version?

Hi, the question is what is the small delay to auto re-try?

I added 100ms to this testing EXE: https://www.dropbox.com/s/smrcfx8mmexpm ... y.exe?dl=0
It includes also the fix for the "delete key issue" ( http://www.ventismedia.com/mantis/view.php?id=14246 ),
feel free to replace it over your current MediaMonkey.exe
And let us know the results!

It would be also valuable to find what is locking the original file. Is it possible that you are doing a tag operation (modifying file properties) on the same file that is just moved or something like this? Probably the debug log would be still useful.

Thanks!

I am currently running a custom MediaMonkey.exe for testing the delete key issue. I will reinstall the debug version when I have finished with my current testing.

I disabled Thumbs.db creation and it has not made any difference.

A small delay and a hidden retry would most probably fix the issue.

Ok, please let us know and full debug log http://www.mediamonkey.com/forum/viewto ... ?f=26&t=69 attached to open Support ticket should help us locate and possibly add some retry delay so that error do not show immediately. What do you think?

I agree that the file could be locked for moving/renaming temporarily. I don't think it could be because of Thumb creation though. Explorer would only create a new thumb after the file is renamed.

It seems to me it is some kind of timing issue. Is there any way we can debug it? The error message is occuring very frequently.

I will turn off Thumbs.db creation and see if it makes a difference.

Hi,
It is very possible that Windows explorer is creating Thumbs file and read it so it is locked for moving. Thus Retry works.

I have just upgrades to MediaMonkey 4.1.16.1836 and now sometimes getting an error message when using Auto-organize.

Settings:
Move and rename files to new destination based on file tags.
Destination: .\<Track#:2> - <Title>

Error message:
An error occured while moving file C:\Music\Artist\Album\OldName.mp3 to C:\Music\Artist\Album\NewName.mp3. Do you want to try again?
Options: Yes No Cancel

When I choose Yes the rename is successful.