Hello gingernut63,

Unless of course the person concerned is using the latest MediaMonkey beta ...

No, I am still at 4.0.3.1476 and according to Mantis the workaround has been implemented in build 1601.
So really looks like, Netgear finally fixed it (Unfortunately I have not seen any info about what version of samba they are now using in their 4.1.9 firmware).
I am sorry that it is too late for you.

Actually my workaround for this problem was a small script in MM, which simply does a "touch" on the selected MP3 files, invoked by a hot-key.

So long
nvs aka reddinazz
_____________
PS: Just found out that firmware 4.1.9 is using smbd version 3.5.15

Thanks to the MediaMonkey crew for addressing this problem a month or so ago even if it is a Netgear issue

Received the following the following response on the ReadyNas forums today, seems Netgear have extracted their finger(s) and fixed the issue themselves. Unless of course the person concerned is using the latest MediaMonkey beta ...

Hello gingernut,

I have made exactly the same experience regarding the missing timestamp updates in connection with MediaMonkey tagging and was also frustrated that nearly no one cares or seriously tried to replicate this behaviour.

Just want to let you know, that latest firmware 4.1.9 seems to have fixed this annoying issue.
Release notes say "Updated CIFS service ...", so I guess the formware is now using a newer version of samba.

I installed it yesterday and immediately did some test with MM: Everytime the timestamp was updated, as it should.

So long

Link to the topic if anyone is interested: http://www.readynas.com/forum/viewtopic ... c3#p324326

Cheers
Gingernut63

Gingernut,

Thanks. Tracked at: http://www.ventismedia.com/mantis/view.php?id=8487

-Rusty

G'day rusty

There are no problems when editing tags locally (c:\). The problems only occur when editing tags on the files stored on the ReadyNAS DUO. The only way to replicate this issue is to use a ReadyNAS DUO unless someone out there with the same device can confirm this issue.

It may be a Netgear issue, however MP3Tag fixed this issue back in 2009. http://forums.mp3tag.de/lofiversion/ind ... t8649.html.

I have sent you a PM with a log for modifying a tag.

Thanks for the response

Gingernut63

Hi Gingernut,

I've tried replicating this but am having no luck. I tested Image/property changes, single/mass changes, local/network edits, and in-place/property/auto-tag edits.

Any hints as to how to replicate? If this occurs consistently for you, can you generate a debug log? Also, can you test whether the problem occurs if the edits are done locally?

Thanks.

-Rusty

I've just gone through the lengthy process of modifying tags in every one of the classical tracks in my music collection to find that only a few out of 4000 files had the modified timestamp changed. Checking a random sample of files using MP3Tag indicated that the relevant tagging had changed but the time stamps were all different and not the current date. "Modify timestamp when updating tags" is checked in the Library Options.

For a further test, in MediaMonkey I added 10 rows of "N" to the comments of 10 tracks and saved them, the file time did not change nor did the file size. I then opened the same ten tracks in MP3Tag and found the 10 rows of "n" in the comments of each track. Using MP3Tag I then deleted the comments and saved the files. The file time changed to the current time. This test was conducted twice once with FLAC and once with MP3 files.

I notice this was happening because backing up of the files from the NAS drive to a usb drive was occurring too quickly. This is a huge issue if files aren't being backed up because the time stamp remains unchanged.

The system info:

+ MediaMonkey 4.0.0.1439
+ The files are stored on a ReadyNAS DUO running Sparc-Linux.
+ PC running 64 bit Win 7 Professional