Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vocalpoint]

Morning,

I wanted to some thoughts on this topic out there BEFORE I run auto import on my library today and once again - watch thousands upon thousands of files get listed as having changes.

I am in Calgary, AB and the Daylight Saving Time change occurred last night. As I store all of my media on a Windows 2008 server - once DST hits - ALL filestamps on ALL files on the server are changed by one hour per the server settings for DST...see here:

http://support.microsoft.com/kb/129574

So every album that was added to MC at anytime in it's valid library lifetime - now appears altered by one hour - here is an album and it's files as they appear on the server right now:



And here is how MC shows them as of now:



Because the server filesystem (NTFS) has now auto shifted the "modified" timestamp back by a full hour - when I click Auto Import in MC anytime after this writing - the entire library is going to report back as being "changed" - which is the reason for the question.

Should MC have the built in ability to work correctly with DST (and the NTFS filesystem) or is having Auto Import report "changes" to 60000+ files - the best this will ever get?

Logically there are NO change to the library whatsoever as of this writing. I have added nothing, removed nothing and changed nothing - yet MC is going to think that 60000 files have changed and report that back.

Thoughts?

VP

[JimH]

I don't remember ever seeing a daylight savings problem with MC.

[Vocalpoint]

I don't remember ever seeing a daylight savings problem with MC.

Jim,

Well - my gut feel is there will be one here.

If I hit Auto Import now (Manually) on my existing library (currently with v18.0.212) in production (with v19.0.67 in testing) - MC is going to see all the modified dates on the server do not match the modified dates in the library - and then tell me that 60000 files have changed.

That's the issue.

I have reported this here in the past and everyone said I was crazy. Well - today - I reminded myself to ask about this -BEFORE I press that Auto import button - so I know I am not seeing things

So if you saying that if MC has "no problems" with DST - it should simply know that DST has occurred and all files in the library should rescan with MC saying nothing has changed?

Should I press Auto Import and report back?

VP

[DoubtingThomas]

I've been using MC for many many years, never a daylight savings issue with any file using any program.

The underlying OS does not store the file date/time you see.  It stores it as GMT and then applies an offset for display based on your settings.  Change your Windows Timezone to something different than you have, presto all the file timestamps will appear changed, then change it back, they revert back. But notice that all the filetime stamps have not been updated to current time due to your timezone "change".

[Vocalpoint]

I've been using MC for many many years, never a daylight savings issue with any file using any program.

The underlying OS does not store the file date/time you see.  It stores it as GMT and then applies an offset for display based on your settings.  Change your Windows Timezone to something different than you have, presto all the file timestamps will appear changed, then change it back, they revert back. But notice that all the filetime stamps have not been updated to current time due to your timezone "change".

Well - as long as MC does the same (the date I "see" is not really real but a GMT offset) - I suppose we will have no issues . But if If MC is truly "DST aware" should it's library not display the same "modified" time as the server?

I am very concerned that my screencaps clearly show that MC is storing the a date of modification that is an hour "out" from what's on the server as of 2:00am this morning.

All I can tell you is at last DST change - I pressed Auto import and had MC tell me that thousands of files had changed.

I guess all I can do is press Auto Import and see what transpires. Will report back here shortly.

VP

[Vocalpoint]

OK - it's not 60000+ files but 7650 files were "effected"....details coming as soon as this import completes it's "updating library to match external changes"

EDIT: That A Fine Frenzy Album that I showed in the screen caps was not in the list of 7650 files "effected" and MC continues to show a modified date that is one hour off from what the server is showing.

The MC summary dialog gives no clues as to what changed in this list of 7650 files....I looked over a few albums and cannot make any real connections as to why this happens on DST day and ONLY on DST day. I never see such a large "change" list as I do the day after a time change.

Some albums on this list haven't been touched in months - and I do an Auto Import sometime 30 times a day. Yet albums like some obscure Wang Chung album imported thios past March is on here.

Hmm...I am wondering if I am seeing "changes" only to those records added AFTER to the "last" DST change back in the spring (March 10?)

EDIT: MC is doing some strange stuff here...I see it detected changes on only half of the new Waxahatchee album....



When I know for a fact I imported this rip all in one go back on March 20 and have not touched the files since then. Yet MC shows the first 7 tracks with one modified time and the last 6 tracks with a modified time and hour later. On the server - the modified time is the same for all tracks.

Anyhoo - something strange going on here with DST and while it seems benign - it would be nice to see exactly what MC is getting all excited about. It's kind of freaky when the system suddenly says it's updating 7650 files in the library for no clear reason.

VP

[InflatableMouse]

I think you should have ran the auto-import a few minutes before the offset took place, and then right after.

[Vocalpoint]

I think you should have ran the auto-import a few minutes before the offset took place, and then right after.

That would have been @ 1:59am this morning...I was sawing logs at that time.

Best I can do for you is - yesterday evening (around 9:30pm) was the last manual run of Auto Import on this library - MC reported zero files changed. Yet today - after DST - here are 7600+ files with something that's different.

I remain baffled tho as to what exactly MC is finding to be different. Some of those example I posted haven't been touched since I imported them months and months ago and none have EVER come up in a manual run since imported - including yesterday night.

Like I said - this happens every single time that DST either kicks forward or back. It's always about 5000-7000 files that suddenly have "changes". I will be sure to revisit this thread again in March 2014 when we spring forward again.

VP

[rjm]

I have relied on a daily manually initiated auto-import to validate the integrity of my large library for about 5 years and have never seen a DST issue.

If MC is reporting that a file changed then it probably has changed. I would do a careful inspection of the file against a backup and check files dates and size. That will tell you what changed.

Next you need to find out what is changing it. The first place to look would be some other media player, like iTunes or Windows Media Player, that has some background media organization task running.

[Vocalpoint]

I have relied on a daily manually initiated auto-import to validate the integrity of my large library for about 5 years and have never seen a DST issue. If MC is reporting that a file changed then it probably has changed. I would do a careful inspection of the file against a backup and check files dates and size. That will tell you what changed. Next you need to find out what is changing it. The first place to look would be some other media player, like iTunes or Windows Media Player, that has some background media organization task running.

Well - I am skeptical as we have no other possible way to interact with these files. All computers use MC. No one buy me has edit rights and some of these albums that have a "touch" are so obscure - that no one but me would ever care.

The most alarming issue is as of 9:30 last night - same library, same workstation and same instance of MC - showed no changes on our one and only library stored on our one and only server. Then today - after DST - 7600 changes. The only explanation is that Windows Server did something to the files and then when rescanned today - MC suddenly "sees" thousands of changes.

VP

[InflatableMouse]

Do you run backups on your media files? Some programs might change file attributes.

My thinking is that if its DST as you suspect, you would have seen all files changed, and not only a portion. Something else must be going on like rjm suggests.

Antivirus program running background scans and storing fingerprint data?

[Random]

Out of curiosity I just ran auto import to see what would happen (this is in Media Center 18 not 19) and 2011 files were shown as having changes. As it happens I had added a couple of albums to my collection last night and had run auto import to add them which it did correctly. Between last night and now I had done no more tagging/adding/etc. to my collection. So, what happened?

[csimon]

Ah - interesting. I ran an auto-import on both my MC PC's last weekend, unfortunately I can't remember which day it was, but it updated thumbnails on 8000+ files on both machines, which I was surprised about. Yes, we had a time change last weekend. My files are stored on a Synology NAS.

[Vocalpoint]

Out of curiosity I just ran auto import to see what would happen (this is in Media Center 18 not 19) and 2011 files were shown as having changes. As it happens I had added a couple of albums to my collection last night and had run auto import to add them which it did correctly. Between last night and now I had done no more tagging/adding/etc. to my collection. So, what happened?

Exactly. Same as me. Added about 8 albums yesterday and the library was completely up to date at the 9:30pm manual scan. And then suddenly 7650 changes today.

@InflatableMouse

No backup software on the server. No AV on the server either.

The only thing that the tiny portion of files I have examined - have in common - is that all of them were modified AFTER the last DST change back on March 10. Not a single file on the list (that I checked so far) was modified prior to March 10, 2013.

VP

[Vocalpoint]

Ah - interesting. I ran an auto-import on both my MC PC's last weekend, unfortunately I can't remember which day it was, but it updated thumbnails on 8000+ files on both machines, which I was surprised about. Yes, we had a time change last weekend. My files are stored on a Synology NAS.

Hmm...How did you determine it was thumbnails that were updated?

VP

[rjm]

Wow, do I feel like an idiot. My apologies, I should have run a test before I spouted nonsense based on past experience.

There is a new problem in MC.

MC detected that 1638 (out 285,000) files changed.

I know for a fact that none of these files changed in the last few days because I ran a synchronization check against backups that reported no changes.

So MC thinks some files changed that did not change.

Here are a quick few observations that might help Matt find the problem:
1) All affected files are of types that MC writes tags to files (eg. mp3, jpg, etc.)
2) All affected files probably had some tag edited by MC or were imported into MC in last few months.

Matt if you need more information let me know because I have detailed records and can probably provide more information if you need it.

[csimon]

It said so! Unless I'm remembering it wrongly. The Auto Update progress displays in the bottom left Action window, it first scanned all the directories and it imports the *one* new file that I had put onto the server but then went on to update the thumbnails for 8000+ files. I suppose it might have said something like "updating files for external changes" as I know that's another common message that occurs, but it stuck in my mind that it had specifically mentioned thumbnails.

[Vocalpoint]

Wow, do I feel like an idiot. My apologies, I should have run a test before I spouted nonsense based on past experience. There is a new problem in MC. MC detected that 1638 (out 285,000) files changed.

Excellent. So glad that you found something as well. I knew I was not dreaming this.

RJM - if you happened to save your file list - do a check to see if any of the 1638 files have a modified date prior to March 10, 2013 (or whenever it was we last had the Spring DST change) I am betting the modifief dates will all be "after" this spring change.

Hopefully Matt can find out what's up....

VP

[rjm]

RJM - if you happened to save your file list - do a check to see if any of the 1638 files have a modified date prior to March 10, 2013 (or whenever it was we last had the Spring DST change) I am betting the modifief dates will all be "after" this spring change.

I did save the list but it would be a lot of work to confirm every file was modified after March 10 because they are split across 7 drives and many folders. Eyeballing the list I strongly suspect that all had tags changed after March 10. Some were imported before and some after March 10. If necessary I can confirm change dates with certainty but only if Matt requires it.

Sorry, forgot that I can filter by modified date with a few clicks in MC .

It would appear that all files detected as changed were modified after March 10, however many other files also edited after March 10 were not detected as changed by MC.

I am thinking that perhaps the editing of a specific tag or tags may be the explanation. Perhaps a rarely touched tag like Copyright or Grouping. I recall doing a cleanup on some of these obscure tags a while ago.

[Matt]

File dates are stored as GMT.  Daylights savings and time zones are not relevant.

[Vocalpoint]

File dates are stored as GMT.  Daylights savings and time zones are not relevant.

So how do you explain MC seeing zero changes at 9:30pm last night (or the night before and the night before that) and then suddenly 7650 this morning? (for me). Or 8000 in csimons case or 1638 for rjm...all as DST took effect?

Something is going on.....regardless of how MC stores file dates - this isn't the first time I reported this oddity. And I am certain that Windows Server (at least in my case) is playing some role (that MC is seeing as "changed" since my files are stored on the server and I haven't had so much as peep for changes until this DST this morning....

VP

[r_harms]

I'm not using a NAS, just a bunch of external's but this morning I was greeted with 116,000 thumbnails that needed updating. I canceled that and checked to make sure all my drives were at their proper locations, they were. All the thumbs look good in MC. I did an import a couple nights ago and all was normal.

I've had unexplained mass thumbnail issues in the past and would love to find a clue.

Rick

[Vocalpoint]

Luckily - I had "logging" on during my manual import this morning...here is what was showing in the log for a given album..

16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\01 - Soul Asylum - Summer Of Drugs.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\02 - Lucinda Williams - Main Road.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\03 - Pearl Jam - Crazy Mary.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\04 - Buffalo Tom - Merry Go Round.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\05 - Michael Penn - Weeds.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\06 - Shudder To Think - Animal Wild.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\07 - Lou Reed - Tarbelly And Featherfoot.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\08 - Maria Mckee - Opelousas (Sweet Relief).flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\09 - Matthew Sweet - This Moment.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\10 - Evan Dando - Frying Pan.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\11 - Jayhawks - Lights.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\12 - Waterboys - Why Look At The Moon.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\13 - Giant Sand - Big Fish.flac
16134154: 2444: Import: AddFile: Changed: \\SERVER\Music\A\Assorted\Sweet Relief - A Benefit For Victoria Williams\14 - Michelle Shocked - Holy Spirit.flac

What exactly does "AddFile : Changed:" mean? The adddate within the MC library is now suddenly different?

If so - that make no sense. The CD above was imported to my library on Dec 11, 2011 and has been relentlessly scanned for months upon months - never ever triggering a "change". Now - as soon as DST kicks in - it suddenly shows in the log as "changed"?

All 7850 files that came back as "changed" this morning are listed in the log with this same entry (Import: AddFile: Changed:)

VP

[rjm]

What exactly does "AddFile : Changed:" mean? The adddate within the MC library is now suddenly different?

If so - that make no sense. The CD above was imported to my library on Dec 11, 2011 and has been relentlessly scanned for months upon months - never ever triggering a "change". Now - as soon as DST kicks in - it suddenly shows in the log as "changed"?

If my theory is correct you edited some tags in these files sometime in the last few months. Probably an uncommon tag like Keyword, Grouping, or Copyright. Do you recall making any edits?

[Vocalpoint]

If my theory is correct you edited some tags in these files sometime in the last few months. Probably an uncommon tag like Keyword, Grouping, or Copyright. Do you recall making any edits?

Well - I make hundreds upon hundreds of edits in a week - and after each change session I run a manual Auto-Import to ensure all changes are correctly notated. Sometimes I run Auto import 10 times a day to ensure I have caught every possible change. It was run 6 times on Nov 2 heading into the DST change. Library was backed up manually 5 or 6 times as well. MC reported zero changes when I ran it the last time before I shut down the PC for the night.

This Victoria Williams comp - I haven't played it for well over a year...and the last mods to the tracks were on May 5, 2013. But I cannot understand how I could run Auto-Import manually at least 750-1000 time (or more) since May 5 and all of a sudden on Nov 3 - MC decides that something has changed on these files? That makes no sense whatsoever.

Whatever is triggering this behavior is not necessarily date driven (but logically makes sense that it should be)...but something has changed within these files and I feel it has something to do with my Windows Server OS and/or it's NTFS filesystem - coupled with the DST change. I see this behavior in MC every time a DST cycle happens and it would be good to know what the cause actually is.

Again - the only thing I can see in common with these files this time is a date/time around March 10, 2013. None of the files being reported as Changed - have a mod date either in MC or on the server - prior to that date. Which oddly - is the last time DST happened.

VP

[rjm]

Sorry, i was not clear. The files have not changed. MC only thinks they have changed and thus re-read the tags, rebuilt the thumbnail, and updated it's modified date (not the file system modified date). The question is why? My theory is that an earlier edit of an uncommon tag plus the DST change triggered the bug.

[Vocalpoint]

MC only thinks they have changed and thus re-read the tags, rebuilt the thumbnail, and updated it's modified date (not the file system modified date). The question is why? My theory is that an earlier edit of an uncommon tag plus the DST change triggered the bug.

Yep. But why would MC wait months and months to report these changes - uncommon tag or not.

Something had to have happened to just this weird collection of files (in my case anyway - modified on/after March 10, 2013) to cause MC to react. My best guess is that Windows Server rolled back modified dates (?) or some other parameter on ALL files BUT for a subset that MC somehow "sees" as relevant to the time between March 10, 2013 and Nov 2, 2013  - it does a complete re-read etc etc and reported 7650 changes.

Now - I have yet to do a manual Auto Update using my v19 test install. I would almost bet that v19 will see these "changes" as well and do it's thing (again). I wonder if there is anything I can supply for Matt or set up prior to clicking Auto Import so we could be better prepared to find out what MC is doing?

VP

[InflatableMouse]

My best guess is that Windows Server rolled back modified dates (?) or some other parameter on ALL files BUT for a subset that MC somehow "sees" as relevant to the time between March 10, 2013 and Nov 2, 2013  - it does a complete re-read etc etc and reported 7650 changes.

I mean no disrepsect, but please accept this: Windows does not alter date stamps on files during DST changes (or when you adjust timezone for that matter), it doesn't work like that. It uses GMT and simply calculates the value to display based on timezone and DST settings. Timestamps are not altered.

I'm not saying you don't have a problem related to DST (its obvious there is some kind of problem) but I think you're looking in the wrong place.

[Vocalpoint]

I mean no disrepsect, but please accept this: Windows does not alter date stamps on files during DST changes (or when you adjust timezone for that matter), it doesn't work like that. It uses GMT and simply calculates the value to display based on timezone and DST settings. Timestamps are not altered.

No problem - none taken or implied.

I am simply trying to understand what it is that is going on here. Here's what I understand now - if Windows Server is operating using GMT and "displays" it's time stamps according to a new DST setting AND MC apparently does the same (according to Matt) then we should have no problems whatsoever. However that is not the case.

My screencap that started this thread clearly shows that a specific file shows one modified time on the server and a different modified time within the MC library (At that moment). Therefore - Matt's statement that:

"File dates are stored as GMT.  Daylights savings and time zones are not relevant."

Is not exactly accurate. If MC was completely "DST Aware" in real time and DST was not an issue - I should have been able to open that Fine Frenzy record on the morning of Nov 3 and see that the library modified date display was exactly the same as the server. Therefore I believe the issue is not with MC storing file dates as GMT - but with storing GMT file date info in a static fashion.

I think it's now fair to assume that MC's GMT time stamp display is not a "live" thing but stored in the library fileset somewhere and NEEDS an update before it's timestamps - match the GMT/DST settings of the files on the server. So - is this really what is happening during a manual Auto Import (following a DST time change):

1. File enumeration begins in MC as it looks to the server for changes
2. MC determines that the server now has a new GMT setting based on the DST change and...
3. Does something? Consults the library? Perhaps looking for files that have had timestamp changes since the last DST change? (Total speculation here)
4. It then locate all files it finds based on Step 3 and updates something in it's library (or even the file itself - modified date or perhaps more?)
5. Auto Update completes - telling me that 7650 files needed updates.

Guys - I am totally fine with the updates if it makes things groovy between library and server and I am fine with how MC should uses GMT and should react favorably to DST changes.

What I am not fine with is:

1. Not knowing what changed
2. What exactly is MC looking for and why?
3. Getting a blunt notice that 7650 files are about to be updated - for reasons unknown

This last one is the one that makes me the most nervous. If MC is suddenly going to update 7650 files - I think I deserve to know what it's going to do and why.

I am hoping we can get a clear understanding or logic flow from Matt as to what MC is doing post-DST change to cause it to report so many changes need to occur.

VP

[csimon]

I've always found DST logic very difficult to understand and predict, LOL! But one thing that strikes me from reading through this is that the way historic timestamps are displayed should not change because of a timezone change, surely, or is that indeed the way it works?  For example, if I changed a file on August 1st at 18:00. Surely if I look at that file now it should still say 18:00, as that is when on August 1st that I changed it. The only thing that DST should affect is what time is returned if I ask the system for the time now.  If I had to restore a file to a version that I knew was correct as of 7pm on August 1st, i wouldn't expect to have to search for a version of the file that was instead correct as of 8pm on that day (or veice versa, can't be bothered to work out whether it would be forward or back from the time I want!). If I schedule a task to run at 15:00 every day, I don't expect to have the scheduler display 16:00 to me after we've passed the next equinox. I assume that along with some sort of universal time, a filesystem will store the timezone that was in effect when the file was modified, so that it will return the same time no matter what the current timezone is.

[Vocalpoint]

I've always found DST logic very difficult to understand and predict, LOL! But one thing that strikes me from reading through this is that the way historic timestamps are displayed should not change because of a timezone change, surely, or is that indeed the way it works?  

Totally agree.

Like that Fine Frenzy record I screen capped. I added that record to MC on 12/08/2012 @ exactly 7:58:40AM and that timestamp should remain for eternity - yet as clearly shown on the server - the "Created" timestamp is displayed as an hour earlier - which makes zero sense to me.

The create date will always be 12/08/2012 @ 7:58:40AM regardless of what time zone or DST settings are in play.

VP

[Matt]

When you change time zones, the display of your file dates in Windows will change too.

File times are stored as GMT and adjusted for your timezone and DST settings accordingly.

Some dates in MC are not stored as GMT, like the 'Date' field.  This is because a picture taken at 8:00PM in Hawaii should still show 8:00PM when you're back home in a different time zone.

[InflatableMouse]

Exactly. You can simply try this yourself. Change the timezone and hit F5 in explorer to see what happens to the dates.

Example.
I have a file I created at 03/11/2013 12:04 and modified on 04/11/2013 17.42 in Amsterdam TZ (UTC +1), but offset by -1 due to DST settings.

I change my TZ to Sydney (UTC +10). The dates displayed change to 03/11/2013 22:04 and 05/11/2013 03:42 respectively.

I change the TZ to Hawaii (GMT -10). The dates displayed change to 03/11/2013 01:04 and 04/11/2013 06:42.

No files were changed, only the time displayed is offset by the settings in windows.

[Vocalpoint]

Exactly. You can simply try this yourself. Change the timezone and hit F5 in explorer to see what happens to the dates.

I get this totally - no files ARE changed - just the display of the timestamps on screen

But does MC do the same thing - if I change the timezone on my PC and hit F5 - will every date I see within MC magically change like this?  From where I am sitting - I believe the answer is no...since I can see MC times being out by an hour in my initial screencaps.

This remains my original question - if time zones and DST changes are "irrelevant" to MC - why are the stored dates not correct to the current timezone settings on a given PC or Server (in my case) ?

VP

[InflatableMouse]

I get this totally - no files ARE changed - just the display of the timestamps on screen

This is correct.

The create date will always be 12/08/2012 @ 7:58:40AM regardless of what time zone or DST settings are in play.

This isn't correct, unless I misunderstand you? I don't mean for this to become a nuisance but I think its important to understanding the issue you're having or you will possibly be chasing ghosts.

This is what I tried to explain. The create date shown will be adjusted to the TZ/DST settings your pc is currently configured for, so it will not always show 12/08/2012 @ 7:58:40AM. If you change the TZ to -2 relative to the TZ that file was created in, that time will become 5:58.40AM.

Imagine I can have a look on your server from where I am. Let's say I'm 7 hours behind your TZ. Your example above will show to me as 0:58:40AM; the time it was in my TZ when you created that file.

[Vocalpoint]

This isn't correct, unless I misunderstand you? I don't mean for this to become a nuisance but I think its important to understanding the issue you're having or you will possibly be chasing ghosts.

I think you are misunderstanding me - a bit

To be clear - I get Windows Server and how it's timestamps are in GMT. And how "time" is either either added or subtracted based on timezone data. I get the F5 refresh thing...(Change the time zone, Hit F5, watch Windows roll the "display" of timestamps to the right time zone).

What I don't get is how Matt says that MC stores it's timestamps in GMT yet timezones and DST settings are irrelevant to MC - yet as my screencaps clearly show - the modified time in my MC library "was" wrong by one hour.(at the moment I took the screencaps)

In my first entry to this thread - I showed the same album in two places. First shot of the album on the server - using it's "now current" DST settings (viewed after 2:00am MST on Nov 2) - that show the timestamp displays were correctly "adjusted" by the OS by one hour. All correct and fully understood - from the "server" angle.

Then the second screencap shows what MC is displaying for the same album which clearly shows the timestamps of the same files but they display a timestamp that was written prior to 2:00am MST on Nov 2, 2013 (times show as one hour later).

If timezones and DST are truly "irrelevant" to MC and it's timestamp data is stored as GMT (the same as Windows Server) - I should have been able to open MC on the morning of Nov 3 and have it instantly "display" correct timestamps on all files (matching the same display as one would see on the server) since DST had now occurred. It goes without saying that I should have also been able to run Auto Import and have MC tell me zero files have changed. Because nothing actually did change on the server - except the way Windows was displaying it's timestamps.

VP

[Matt]

What I don't get is how Matt says that timezones and DST settings are irrelevant to MC - yet as my screencaps clearly show - the modified time in my MC library "was" wrong by one hour.(at the moment I took the screencaps)

There's a gross legacy thing with how Windows describes file times with regard to DST.  If you ask it to make a file time a local time, it doesn't apply DST like it should.  This can cause times to show differently in Explorer and MC by one hour.

We've just lived with this for a long time, but I finally cleaned it up today:
Changed: Revised how system file times are mapped to internal times to work around a legacy Windows issue with regard to DST (should be internal change, but could cause some file times to shift by an hour when updating library).

[Vocalpoint]

We've just lived with this for a long time, but I finally cleaned it up today: Changed: Revised how system file times are mapped to internal times to work around a legacy Windows issue with regard to DST (should be internal change, but could cause some file times to shift by an hour when updating library).

Wow! Awesome.

So will this change stop MC from gathering thousands of seemingly random files from the library and staging them as "changes" when we cross the DST timeline again in the spring?

VP

[Matt]

So will this change stop MC from gathering thousands of seemingly random files from the library and staging them as "changes" when we cross the DST timeline again in the spring?

Yes, I think so.

[Vocalpoint]

Yes, I think so.

Great. Really appreciate the update.

Cheers,

VP

[rjm]

Great news!

A clean auto-import is really the only tool we have to check if anything bad has happened to MC, our media files, or our system. We need to trust this tool to report no changes when there are indeed no changes.

[csimon]

So will this change stop MC from gathering thousands of seemingly random files from the library and staging them as "changes" when we cross the DST timeline again in the spring?

I'm wondering that it wouldn't have happened in spring anyway as the shift will be in the other direction, i.e.MC might only thinks that a file is changed if its timestamp is after the last time it's got. But we'll see!

[Vocalpoint]

I'm wondering that it wouldn't have happened in spring anyway as the shift will be in the other direction, i.e.MC might only thinks that a file is changed if its timestamp is after the last time it's got. But we'll see!

I got the mystical update at every DST cross-over regardless of time "direction". Back in March it was something like 4000 files had changed....here's hoping this update fixes that issue.

VP