Date/timestamp issue on Music Players

More info. I have conducted testing using a number of different Music Players/managers and the results are similar to the ones achieved with MediaMonkey.

I installed Jangle, AIMP2, Quux Player and Songbird at different times and modified the tagging of one album stored on my ReadyNAS DUO. the results are listed below.

- When modifying one to three characters of text in songs all programs did not change the date, time or file size of the relevant audio files
- Same results for FLAC and mp3 files
- When I added a large amount of text to the comments tag in Quux Player and Songbird, there was no change to the date, time or file size. However when I removed the text in the comment field both players changed the date and time
- When I added a large amount of text to the comments tag in AIMP2 there was no change to the date, time or file size. This time when the text was removed the the date and time changed to the current date and time for a second then reverted back to the original date and time. The same was achieved for the removal of any amount of text in any tag.
- When modifying a small number of text characters in the tags all programs did not change the date, time or file size of the relevant audio files (AIMP2 did try, see above)
- I could not get MediaMonkey to modify the date, time or file size no matter what I did

The results from the AIMP2 tests were the most interesting. No changes when adding text but when removing text the program did change the time and date for the relevant file for only one second before it revert back to the original. I think that these initial tests are pointing towards the ReadyNAS as the source of the problem.

Is this issue only happening to me? :o If it is then tell me, otherwise this is a very important issue that needs some form of response. Has anyone done any testing to see if their time stamps are being updated every time they modify an audio file? Does this issue apply to other file types?

My backup drive is not updating the edited audio files if the date/time stamp is not modified. The only way I can be sure that it is being done is to change the date/time stamp via a third party program which I should not have to do. This must have been happening for quite some time, thank goodness I haven't needed to rely on the backups at all.

Very interested to hear a response to this issue.

Usually depends on the software making the changes to the file if it modifies or retains the timestamp. I've seen it fall both ways.

Haven't used these types of tools myself in awhile, so I'm not familiar with recent things.

The programs have been configured to change the date/timestamp when any editing is done to the files including tagging mods. They modify the date/timestamp every time when editing tags on audio files located on the PC C:\ drive however as mentioned above, when modifying tags on audio files installed on my ReadyNAS DUO the timestamp is not changed, or it tries to change, but it reverts back to the original date and time.

Like I've said previously, you don't know this happening unless you look for it. It can't just be happening on my setup, it is probably happening to a lot of other users, they just don't know it. Yes that is supposition, but to confirm, it would be good if other people conducted the same or similar testing to prove or disprove my theory. If I'm right, then it is an issue that needs addressing.

Just noticed a recent post on the forum by Schreiner_A2 regarding the Samba version used in the firmware. viewtopic.php?f=7&t=57758

Why is such an old samba Version 3.0.37 on ReadyNAS NV+ (firmware 4.1.8 ) ??? This samba has so much known problems for example time stamp problems!!!

Any comments to confirm or deny? Possibly explains why my posts have received such a low key response.

Again I stress, if you are backing up the data on your ReadyNAS DUO, which you should be, some programs are not updating the timestamp when editing data which means the modified data is not backed up. If you use any of the programs mentioned in this topic then you should be making sure that your edited data is being backed up. There will be other programs that are having the same issue, are they the ones you use? It's not a problem until you need the backups, by then it's too late. :shock:

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

reddinazz wrote:

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

Thanks for the post reddinazz. I didn't know that Netgear had finally fixed the problem, but have they?? Because of the lack of support by Netgear, I logged a bug report on the MediaMonkey website late last year. They fixed the issue a couple of months ago after liaising with Forian at MP3Tag (my suggestion). If you are using a latest MediaMonkey beta then the fix might not be Netgears!

It's good see that it's finally fixed whatever way it was done, however this activity has come too late for my ReadyNas Duo as I have migrated to a HP N40L Microserver; couldn't wait for something to happen. Alas MP3Tag and MediaMonkey had to program in a fix at their end because of the lack of activity by Netgear.

Thanks Again

I have already posted this information to the MediaMonkey forum. But it should go here as well:

If you are using a latest MediaMonkey beta then the fix might not be Netgears!

No, I am still using MM 4.0.3.1476 and according to MM developer information the workaround has been implemented in build 1601.
Although late (too late for you), it seems Netgear did it.


PS: Just found out how to read out the samba version (see http://www.readynas.com/forum/viewtopic.php?f=17&t=62461). Firmware 4.1.9 is using smbd version 3.5.15