After time switched to DST MM syncs ALL files

[dip]

In Germany time has moved one hour ahead last weekend due to daylight saving time. When I now synchronized my ipod video (running the rockbox firmware with d_USBMass1.dll) with MediaMonkey, MediaMonkey started to copy ALL songs (more than 9000) to the ipod although only one new album has been added to the library. Since most of the songs must be converted from flac to mp3 it took hours over hours. This happend with the latest beta 3.1.0.1232.

This should definitely be fixed, otherwise this will happen every six months.

I expected to find a lot of similar posts in the forum regarding this issue since daylight saving time is used in many countries, but I didn't. Does this happen only with a specific constellation? For example, I have MM running on a different computer than the music files are stored.

Has anybody else had this problem when time has moved one hour due to daylight saving time?

[rusty]

This would only occur if somehow all of the files had changed their timestamp--otherwise nothing would have triggered them to sync. Could something in your environment have caused such a change?

-Rusty

[dip]

I cannot image any reason that the timestamp of all my files should have been changed. I have only added a new album to the library and then synched in the normal way.

I had a similar problem last year with a backup program synchronizing data (not related to MM) to an external disk. After switching to DST the backup programm copied also ALL files to the external disk (even the files which were not changed). From the support of this backup program it was explained that this was caused since the disk on which the original data files were stored were NTFS formatted while the external backup disk was FAT32 formatted. It was explained that Windows XP handles the time and date on NTFS and FAT32 disks in different ways so that on the FAT32 disks all files get a new timestamp when Windows XP switches to DST (I don't know if I explain this 100% correctly). I formatted the external disk with NTFS and since then this problem did not occur any further after switching to DST.

Since my disk storing my original music files is NTFS formatted and the disk of my ipod is FAT32 formatted, could there be a similar problem? To be totally correct, the music files are stored on an NTFS formatted disk of a first computer running Windows XP (my music server). This disk is shared over my home network and MM is running on a second Windows XP computer which has two NTFS formatted disks on one of which the library of MM is stored. The ipod (running the rockbox firmware, so MM does not use the ipod dll but d_USBMass1.dll) is plugged into this second computer.

Does MM check the time and date of the files as stored on the ipod (usb mass storage device) when synchronizing which could result in the above problem?

[rusty]

I expect that whatever triggered your backup software to backup all files also triggered MM to resync all files, as MM _does_ examine file last modified timestamps to determine whether a file has been modified.

As far as what is triggering the change in timestamps--I have no idea; a difference in file system shouldn't cause that.

-Rusty

[dip]

To avoid any misunderstanding: The problem with my backup software was only last year when time was switched to DST. I then changed the format of my disks that they are all NTFS formatted and since then I have no problem with the backup software. But with MM I had the described problem two weeks ago when time was switched to DST. Below I enclose a copy of the description I related to the different timestamps for NTFS and FAT32 formatted disks. Maybe the problem that MM started to sync ALL files is related thereto.

--------------------------------------------------

There was a huge amount of debate on the xxcopy forums on this
eg http://groups.yahoo.com/group/xxcopy/message/4272

see this article - http://www.codeproject.com/datetime/dstbugs.asp

would seem MS NOT up to fixing it

[extract from xxcopy forum]
The source of your problem is that one set of files are on
a FAT volume and the other set are on an NTFS volume. The
timestamp of a file on a FAT volume is recorded using local
time. The timestamp of a file on an NTFS volume is recorded
using UTC time.

When you change the regional setting to a different time zone
or daylight savings starts or ends, the timestamp of files on
either volume DOES NOT change. However the timestamp of files
on an NTFS volume APPEARS to change. When windows retrieves
the timestamp for NTFS files and passes that time to the
calling program, it adjusts the UTC time to reflect the local
time zone and/or daylight savings. Therefore although the UTC
time is unchanged, Explorer or Cmd or Xxcopy or whatever
generally uses/displays the time using local time and this
appears to show an altered timestamp.

This wouldn't cause a problem if comparing files between two
different NTFS volumes because the time adjustment would be
the same for both the src and dst. The problem arises when
comparing files on a FAT volume because these times are
stored using local time. Windows makes no time zone
adjustment for these files so their timestamps both remain
the same AND appear the same irrespective of timezone/
daylight savings changes. However when the file timestamps
are compared to the files on a FAT volume, they appear to
have different timestamps.

[Garry Deane]

[rusty]

Dip,

Thanks for the clarification. I'm going to move this to our regular bug forum so that we can look into this after the 3.1 release.

-Rusty

[dip]

Same problem happened again. After daylight saving time has ended last weekend in Germany, MM now syncs again ALL files which takes hours!
I am using MM 3.1.1.1261.

Please look into this problem since otherwise every six months I have to sync ALL my files.

[chrisjj]

As far as what is triggering the change in timestamps--I have no idea

I see nothing to indicate a change in timestamps. Dip, if timestamps have changed, could you confirm?

[dip]

Timestamps have not changed. I confirmed that by running my backup programm. When I started to backup my music files after DST ended, my backup program did not copy ALL files (only the files which have been amended during the last backup). This confirms that timestamps of the files have not changed (otherwise the backup programm should have copied ALL files). I have no idea why MM starts to sync ALL files after DST begin/end.

MM is installed on a Windows XP Home computer. My music files are stored on a music server running Ubuntu 9.04. Last time when I had this problem the music server was running Windows XP but I changed the operating system of the music server during the last half year.

[rovingcowboy]

it changes here on sunday so either sunday or monday they should be able to see this if it is doing it because of mediamonkey.

[chrisjj]

> Timestamps have not changed.

Thanks.

> I have no idea why MM starts to sync ALL files after DST begin/end.

II think it would be worth the Devs checking that MMs' timestamp interpretation is not vulnerable to DST changes.

[nohitter151]

Couldn't it be that your server and the PC which MM is on just have different times: http://www.mediamonkey.com/support/inde ... 13&nav=0,1

[dip]

Couldn't it be that your server and the PC which MM is on just have different times: http://www.mediamonkey.com/support/inde ... 13&nav=0,1

No, I don't think so. First, both are fetching their time via ntp. Second, if they had different times, the effect that ALL files are synched must happen always (or at least always when the times drifted enough). However, this problem occurs ONLY every six months at the first sync after DST begins (in March) or ends (in October).

[nohitter151]

Couldn't it be that your server and the PC which MM is on just have different times: http://www.mediamonkey.com/support/inde ... 13&nav=0,1

No, I don't think so. First, both are fetching their time via ntp. Second, if they had different times, the effect that ALL files are synched must happen always (or at least always when the times drifted enough). However, this problem occurs ONLY every six months at the first sync after DST begins (in March) or ends (in October).

I'm saying maybe one updates to DST sooner than the other with the new time -- so perhaps for some unspecified amount of time (e.g. until you reboot) the servers time is in the future compared to the PC.

[nohitter151]

it changes here on sunday so either sunday or monday they should be able to see this if it is doing it because of mediamonkey.

Actually we aren't changing to DST (in the US), we're changing back to normal time on Sunday. We're on DST now.