Print

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

[Vocalpoint]

Morning,

I have a question (and confusion) as to exactly what this messages means:

Updating Library to Match External Changes

When I do a manual import via a toolbar button attached the bottom left toolbar.

Now let me set the stage - yesterday - I did a small Find and Replace operation on a ton of files. The operation went perfectly and MC gave lots of feedback telling em that all the tags were correctly updated. So - what exactly happens when a tag is updated manually? Is just the actual tag in the file ONLY being updated - and the library then "gets" these changes at the next import?

Now my understanding of this process logically suggests that if all my tags were updated by me manually - inside that actual program interface - shouldn't this information also be written to the active library at the same time?

I have always been perplexed by this message since it uses the word "External" - it implies that I was messing around with some files in Windows Explorer or something and it's these "external" changes that MC is trying to catch up with.

Appreciate any info on why MC needs that secondary step during the "import" process to get the library right.

Cheers,

VP

[MrC]

Morning,

I have a question (and confusion) as to exactly what this messages means:

Updating Library to Match External Changes

Consider this additional case.  In Windows Explorer, you rename an album folder.  MC is smart, and will eventually notice this change, and will update its database (aka: the Library) to reflect the new location for each of the tracks (it minimally would need to update each track's [filename] field).

When make changes in the UI, you are changing MC's database (again, fields in the Library).  By default, MC will automatically write out these changes to the files themselves.  But this happens in the background pretty soon, when MC gets around to it.  You can manually instruct MC to Do It Now by manually updating tags from the library.

[Vocalpoint]

Consider this additional case.  In Windows Explorer, you rename an album folder.  MC is smart, and will eventually notice this change, and will update its database (aka: the Library) to reflect the new location for each of the tracks (it minimally would need to update each track's [filename] field).

This make total sense - because it is an "external" change (outside of the MC UI)

When make changes in the UI, you are changing MC's database (again, fields in the Library).  By default, MC will automatically write out these changes to the files themselves.  But this happens in the background pretty soon, when MC gets around to it.  

I beg to differ on this point - especially the part about "when MC gets around to it". I have Auto Import shut off - so MC will never get around to anything. Case in point - after I made a field update to 1700 files...I left MC running for at least 3 more hours...but the actual library never got any of these updates - until I pressed my Run Auto Import Now toolbar button this morning.

You can manually instruct MC to Do It Now by manually updating tags from the library.

So if I click "Update Library from tags" with all the files selected - that will do it?

I guess I still want to know why it just doesn't happen automatically when I update anything from within the UI. What possible reason could there be for NOT writing my 1700 updates to the actual library a second or two after the field update has occurred? I mean - if I go to the trouble of doing a bunch of manual work - it only makes good sense that this is exactly what I want and that I want it saved to the library like - immediately? I am starting to think what would happen of something got botched some time in between when I made my changes and went I actually press Auto Import...sounds like a possible problem area if something got messed up (Not sure what).

Just wondering why the "two stage" process is necessary? And why is something that I have done within the MC UI is interpreted to be "external" . I would think that any change made to any files within the MC UI should be "internal" in nature if anything.

VP

[MrC]

Can you check your setting for: File > Update Tags when File Info Changes.

[Vocalpoint]

Can you check your setting for: File > Update Tags when File Info Changes.

This is set to on.

VP

[rjm]

What file types are you seeing this with?

I am aware of some weird behavior with dvds imported in MC. Changing a dvd seems to require 2 passes (once for the initial change and a 2nd time on next auto-import) before MC thinks nothing has changed.

I never see "updating library" for simple file types like mp3 and avi.

Any chance you've got something running in the background that is changing tags?  Windows Media Player or iTunes with certain settings can cause this.

[MrC]

Auto-import directories are not required to have tags updated, so there's something unique about your system.

I just tested an MC16 install, with no Auto-import directories configured.  I changed a tag, and immediately saw MC's notification that it had finished updating tags.  Looking at the file via Windows Explorer confirmed the tag had been changed and the file was updated.

[Vocalpoint]

What file types are you seeing this with?

I am aware of some weird behavior with dvds imported in MC. Changing a dvd seems to require 2 passes (once for the initial change and a 2nd time on next auto-import) before MC thinks nothing has changed.

I never see "updating library" for simple file types like mp3 and avi.

Any chance you've got something running in the background that is changing tags?  Windows Media Player or iTunes with certain settings can cause this.

My files are exclusively FLAC. Windows Media Center is not even used (disabled) and iTunes...well ...please

Also - are you understanding the question? There is nothing really wrong - I just want to know why - when I change a file in any way - the library isn't updated instantly (right after whatever change I am making). The change works fine and the file gets the change instantly - but the "library" does not. It needs a second "Run Auto-Import" for the library to get these changes...and then calls them "external"....which they are most definitely not.

VP

[Vocalpoint]

Auto-import directories are not required to have tags updated, so there's something unique about your system.

I just tested an MC16 install, with no Auto-import directories configured.  I changed a tag, and immediately saw MC's notification that it had finished updating tags.  Looking at the file via Windows Explorer confirmed the tag had been changed and the file was updated.

That's not the issue. That exactly what I see...when I make a change in the UI - I see the MC notification that it's "finished updating tag information". That's always been fine. And the file is in fact updated correctly.

But the "library" is not. As is the case yesterday - I updated 1700 files in a single pass. MC duly noted that it would take a while to do this and when it completed - I saw the notify that 1700 files had been successfully updated. However - when I ran "Run Auto-Import now" this morning, manually as I always do - then and only then - did the library finally "catch up" with what I had done the previous night by posting a message that 1700 files "were updated"...with the dialog title Updating Library to Match External Changes"....

VP

[MrC]

Something is interfering (virus checker?).  Or is this a library server client?

When you make a change via the MC UI - it is the library you are changing*.  Then and only then are changes reflecting into physical media files.  If you're seeing changes to the physical files, MC's library is already done.

The updating tags message will hang around for a while if you have scheduled recordings that are actively recording.

* to be clear, in the MC UI, you're changing a media file's properties for one or more specific database fields.  These are what you see.  Every media file essentially has the collection of the database fields and this collection is per-library.  And these subsequently are/can be written to physical media file tags (and vice versa, upon command).

[rjm]

Also - are you understanding the question?

I do understand. I only see on dvds. But then I rarely work with flacs.

[Vocalpoint]

Something is interfering (virus checker?).  Or is this a library server client?

When you make a change via the MC UI - it is the library you are changing*.  Then and only then are changes reflecting into physical media files.  If you're seeing changes to the physical files, MC's library is already done.

The updating tags message will hang around for a while if you have scheduled recordings that are actively recording.

* to be clear, in the MC UI, you're changing a media file's properties for one or more specific database fields.  These are what you see.  Every media file essentially has the collection of the database fields and this collection is per-library.  And these subsequently are/can be written to physical media file tags (and vice versa, upon command).

Well...the files in question all reside on another server. The library is local to my machine. And I am still baffled by the messaging - since - if as you say - I am really "updating" the library and then the physical file - I would expect to see a "no changes" message when I manually run "Run Auto Import Now"...

As a test - here's what I see in the Summary dialog after just pressing "Run Auto Import Now"...in the last minute or so:

Library now has 24239 files. Search and update took 0:08.

Imported 0 new files.
Updated 1 file that had external changes.

In-depth details:
Updated:
    \\SERVER\Music\Mott The Hoople\Mott\01 All The Way From Memphis.flac

And as is the case for the thread topic itself - I edited this one Mott file (via the UI) over 4 hours ago (changed the rating and that's it). MC acknowledged the change 4 hours ago with it's notification at the bottom of the screen....but now - some 4 hours later - the library finally "catches up" via manual import.

Tis weird....must be the fact that the file is on the network and not local.

Cheers,

VP

[MrC]

Ok, we're narrowing things down.  Good data.

Check the dates on the two systems.  Also, are the remote disks immediately accessible on the local system, or is there a long delay when trying to access them?

What you're seeing seems to indicate something about the remote file has changed *after* the date MC maintains to track changed files ([Date Modified]).  Hence, MC updates its library to reflect that remote change.

[Vocalpoint]

Ok, we're narrowing things down.  Good data.

Check the dates on the two systems.  Also, are the remote disks immediately accessible on the local system, or is there a long delay when trying to access them?

What you're seeing seems to indicate something about the remote file has changed *after* the date MC maintains to track changed files ([Date Modified]).  Hence, MC updates its library to reflect that remote change.

The dates/times on each computer are identical as they sync to the same internet time server. No delay to access the files - it's as instant as a local drive.

VP

[MrC]

Ok, I can reproduce this easily enough when file system permissions don't allow MC to be able to write to the remote file system.  MC maintains the status message that it is trying to update tags.  If I quite MC, an error dialog indicates the issue.

Once I change permissions to allow writing by the MC process, the write occurs pretty quickly and Done Saving Tags message appears.

So, if there is one file that can't be written, its status message blasts over any previous ones, and that's all you'll see.

[Vocalpoint]

Ok, I can reproduce this easily enough when file system permissions don't allow MC to be able to write to the remote file system.  MC maintains the status message that it is trying to update tags.  If I quite MC, an error dialog indicates the issue.

Once I change permissions to allow writing by the MC process, the write occurs pretty quickly and Done Saving Tags message appears.

So, if there is one file that can't be written, its status message blasts over any previous ones, and that's all you'll see.

Well...I don't have any permissions errors on the server and I have never had MC stall on the message that it's writing tags. That always has been and always is - instant. Again - no problems whatsoever having my changes via the UI written back to the files instantly.

Only this strange message when using Auto Import via manual button click....

VP

[Alex B]

"Update for external changes" is an an Auto-Import option that makes MC to re-read the file info (= file format & possibly existing file tags) if the last modified time stamp of the disk file has changed after the time stamp was stored in the Date Modified library field. (Normally a tag change that is written to a disk file updates the Date Modified value accordingly.)

The "Update for external changes" option should work with any standard library file that points directly to a disk file (exceptions include e.g. referenced files like cue audio tracks and VIDEO_TS folder structures). This option is not anyhow limited to the listed Auto-Import folders. The folder list is used when MC imports new library entries.

It will work automatically if Auto-Import is set to run in background. It also works when Auto-Import is started manually - i.e. it will then run once as a part of the process (if it is enabled).

[Alex B]

The dates/times on each computer are identical as they sync to the same internet time server. No delay to access the files - it's as instant as a local drive.

Perhaps the server file system still somehow reports a different time stamp later when you run Auto-Import.

As a test you could do the following:

- Place a file in a new folder on your server
- Create a copy of the file with Windows Explorer (keep the copy the same folder).
- Import the folder to MC and create a playlist of these two files.
- Change a tag in one file. Don't change the other file.
- Export the playlist in MPL format.
- Run Auto-Import (manually).
- Export the playlist again to a new MPL file.
- Open the playlist files with Notepad and compare the Data Modifed values (the value is in the "Unix" format: yabb.jriver.com/interact/index.php?topic=59513.msg404286#msg404286).
- Do the values differ?

[leezer3]

Random thought-
If the server either Linux based (or a NAS), it may well be using UTC.
In a lot of cases, the Windows time and UTC differ (Please don't ask me to explain, my head hurts already) & I'm wondering if they are thus different

-Leezer-

[AoXoMoXoA]

I have gotten the same message about external changes since early versions of MC, and I never make changes to my FLAC files except from inside MC.

The term 'external changes' in the Import summary is the part that raises the question when the changes were actually made by MC and within the same library.

I posted this question once years ago, but never did get an answer.

It has not changed, I simply began to ignore it as simply a poor choice of wording.

[Vocalpoint]

Perhaps the server file system still somehow reports a different time stamp later when you run Auto-Import.

Well - here is the workflow (again) and since all files reside ON the server - I do not see how time stamps have anything to do with anything - here we go :

This workflow uses my Main library (whose library files sit on my personal workstation - while ALL actual media files are located on our Windows Home Server) And let's say - I do this update right now (8:54am)

1. Highlight 20 albums (inside of MC UI)
2. Chose File Replace (for example)
3. Use File Replace to update a single field (say - the comment field like I did) in all tracks for all 20 albums
4. MC immediately says - This could take a while to make this change on 212 track - sure you want to continue?
5. And I continue
6. And I can see MC making the updates (at the bottom center of the UI) as it updates these tags
7. Then is says "Tags updates successfully) or similar
8. And then I decide to just play music for three hours and do nothing else "edit" wise
9. If at 11:54am - 3 hours later - I decide to press "Run Auto Import Now"....
10. MC's messaging reports that 212 files were successfully updated as "external" changes?

Hence my question.

And with a nod to AoXoMoXoA  - this message may very well just be a bad choice of wording. Or perhaps - during the initial update in step 6 above - I am writing date-stamps to the files from my workstation and then MC uses some other time stamp (Server or something) when I run Auto import at a later time.

Overall - it's not a huge deal - just makes me wonder why the library proper is not properly updated with Step #6 in my workflow.

I will try your test as well to see if I can nail down any date/time oddities going on here.

VP

[rjm]

I have 266,000 files in my library and I follow your workflow on an almost daily basis. At the end of each day I Run Auto-Import Now as an integrity check to ensure nothing changed that should not have changed, and as a crude confirmation that my library is ok. I never see the "updated external changes" message that you see except in the extremely rare case (once every 2+ years) of a corrupted library after a crash, or the dvd weirdness I discussed above.

Half of my media is on local drives and half of my media is on Windows 7 network shares. This would suggest that what you observe has something to do with Windows Home Server.

[Vocalpoint]

I have 266,000 files in my library and I follow your workflow on an almost daily basis. At the end of each day I Run Auto-Import Now as an integrity check to ensure nothing changed that should not have changed, and as a crude confirmation that my library is ok. I never see the "updated external changes" message that you see except in the extremely rare case (once every 2+ years) of a corrupted library after a crash, or the dvd weirdness I discussed above.

Half of my media is on local drives and half of my media is on Windows 7 network shares. This would suggest that what you observe has something to do with Windows Home Server.

Good to know. I have 24000 files (all FLAC) and all have always resided on some flavor of Home Server (v1 from mid 2008-mid 2011) and now v2 (Mid 2011 - present) and I have seen this message consistently in all that time - but ONLY after changes have been made via the UI.

If I copy 10 new albums worth of files out the server (that are new to the library) and run Auto-Import - I fully expect to see that message acknowledging the fact that 10 new albums have suddenly "shown up" out on the server and that they need to be properly added into the library.

However - If edit those same 10 new albums worth of stuff AFTER they have been added to the library via the UI and MC acknowledges the instant changes while I am in the UI - I expect to see no message at all about "external" changes when I run Auto Import at any time AFTER the changes have been completed.

To me - there should never be any "external" changes pending since  - presumable - they have already happened and the library correctly updated at the time of the edits.

VP

[Alex B]

...Overall - it's not a huge deal - just makes me wonder why the library proper is not properly updated with Step #6 in my workflow.

If you can see the changed tag values inside MC, the library data was correctly updated and if the tag write was successful, the file tags are not supposed to differ from library data.

When "Auto-Import/Update for external changes" runs MC has no way to know if any of the tags have actually changed inside the media file. It just re-reads file data if the last modified time stamp has changed.

The final "updated changes..." message indicates that the re-read was successful. It does not necessarily mean that one or more file tags actually differed from the library data, though normally this is the case (people do tag files outside MC). My test procedure may explain what triggers the seemingly unnecessary tag re-read in your case.

If you don't tag files outside MC it is quite unnecessary to have the "Update for external changes" option enabled. Even when it is disabled you can always use the "Update Library (from tags)" tool if you sometimes need to import externally changed metadata.

[Vocalpoint]

If you can see the changed tag values inside MC, the library data was correctly updated and if the tag write was successful the file tags are not supposed to differ from library data.

When "Auto-Import/Update for external changes" runs MC has no way to know if any of the tags have actually changed inside the media file. It just re-reads file data if the last modified time stamp has changed.

The final "updated changes..." message indicates that the re-read was successful. It does not necessarily mean that one or more file tags actually differed from the library data, though normally this is the case (people do tag files outside MC). My test procedure may explain what triggers the seemingly unnecessary tag re-read in your case.

If you don't tag files outside MC it is quite unnecessary to have the "Update for external changes" option enabled. Even when it is disabled you can always use the "Update Library (from tags)" tool if you sometimes need to import externally changed metadata.

Hmmm...so - I may just solve this issue by turning off "Update for External" changes?

Also - it would beneficial to note how I actually "tag" using MC. To be clear - 99% of my tagging is done via MC and 1% via Tag N Rename. But none of the actual media files ever reside in any MC library for this process.

I do all of my tagging using MC via the Drives and Devices tree item - effectively opening up my FLAC files from a local drive (staging folder) - and then get them into shape (Clean file properties, Analyze Audio, add cover art etc) ALL locally. Once the files have passed thru this edit sequence - five things happen - the first three steps being "external" to MC:

1. The master "play" copy is sent to the server (Windows Explore->Copy)
2. A mobile copy is created from the master (using dbPowerAmp->Convert) and sent to my local Music folder (for iPod use)
3. The master copy is moved to my master archive on a separate external drive (Windows Explorer->Move)
4. Once the copies are complete - I click Run Auto Import Now - within the MC UI
5. The resulting entry is checked within the UI for consistency (shows up under my Recent Albums view)

Will try to run off that option and see the results...

Cheers,

VP

[Matt]

Well - here is the workflow (again) and since all files reside ON the server - I do not see how time stamps have anything to do with anything - here we go :

This workflow uses my Main library (whose library files sit on my personal workstation - while ALL actual media files are located on our Windows Home Server) And let's say - I do this update right now (8:54am)

1. Highlight 20 albums (inside of MC UI)
2. Chose File Replace (for example)
3. Use File Replace to update a single field (say - the comment field like I did) in all tracks for all 20 albums
4. MC immediately says - This could take a while to make this change on 212 track - sure you want to continue?
5. And I continue
6. And I can see MC making the updates (at the bottom center of the UI) as it updates these tags
7. Then is says "Tags updates successfully) or similar
8. And then I decide to just play music for three hours and do nothing else "edit" wise
9. If at 11:54am - 3 hours later - I decide to press "Run Auto Import Now"....
10. MC's messaging reports that 212 files were successfully updated as "external" changes?

This isn't normal.  Something is changing or incorrectly reporting the 'last modified' time of your files.

You might watch the 'Last Modified' column in Media Center and compare it to what's on disk.  It should look like:

1) Times match
2) You tag a file
3) Tagging finishes
4) The file system time and the 'Date Modified' match (and show the time that #3 finished)

Something is breaking down in that flow.  I don't think it's a common problem, so virus or NAS software are possible explanations.

[Vocalpoint]

This isn't normal.  Something is changing or incorrectly reporting the 'last modified' time of your files.

You might watch the 'Last Modified' column in Media Center and compare it to what's on disk.  It should look like:

1) Times match
2) You tag a file
3) Tagging finishes
4) The file system time and the 'Date Modified' match (and show the time that #3 finished)

Something is breaking down in that flow.  I don't think it's a common problem, so virus or NAS software are possible explanations.

Matt - I will walk thru it later this evening and see if I can isolate any oddities. There is no antivirus or anything that can modify files on the server. I do have AV on my local station but all MC processes have been white listed - as I have done for years. Also all local media file types (like .FLAC, .MP3 etc) are globally excluded from any scans on any drives.

It will be fun to find out what's up...

Thanks!

VP

[Vocalpoint]

Perhaps the server file system still somehow reports a different time stamp later when you run Auto-Import.

As a test you could do the following:

- Place a file in a new folder on your server
- Create a copy of the file with Windows Explorer (keep the copy the same folder).
- Import the folder to MC and create a playlist of these two files.
- Change a tag in one file. Don't change the other file.
- Export the playlist in MPL format.
- Run Auto-Import (manually).
- Export the playlist again to a new MPL file.
- Open the playlist files with Notepad and compare the Data Modifed values (the value is in the "Unix" format: yabb.jriver.com/interact/index.php?topic=59513.msg404286#msg404286).
- Do the values differ?

Alex,

I completed this test - and the Date Modified value in both mpl files are identical.

I also got the message that 1 file was updated with "external" changes when I hit step 6 of your list above.

Ideas?

VP

[Vocalpoint]

This isn't normal.  Something is changing or incorrectly reporting the 'last modified' time of your files.

You might watch the 'Last Modified' column in Media Center and compare it to what's on disk.  It should look like:

1) Times match
2) You tag a file
3) Tagging finishes
4) The file system time and the 'Date Modified' match (and show the time that #3 finished)

Something is breaking down in that flow.  I don't think it's a common problem, so virus or NAS software are possible explanations.

Matt,

Tried this test too. I found that when I tag a file via the UI (Step 2)...the tag completes successfully, I get the message at the bottom of the screen - but no amount of "refreshing" within the MC UI will actually make the "Date Modified" value change to the time the tag was edited. Only after I run Auto Import manually - do I then see the freshened "date modified" within the MC UI. And - of course I get the message about 1 file being updated due to external changes

Wilder still - even after all of the above - when I compare the Date Modified value that was written to MC with the actual time stamp on the file on the server - they are identical. So nothing on the server is changing any time stamps in any way.

Cheers,

VP

[Alex B]

I did a test:

1. Imported a file and a copy of it from a network share

2. Exported an MPL playlist of them. Here are the Date Modified values from the MPL file:

<Field Name="Filename">\\Ab-h\share\test\04 - The Times They Are A-Changin'.flac</Field>
<Field Name="Date Modified">1270917097</Field></Field>

<Field Name="Filename">\\Ab-h\share\test\Copy of 04 - The Times They Are A-Changin'.flac</Field>
<Field Name="Date Modified">1270917097</Field>

3. Changed the track number in the "copy" file and exported a new MPL playlist. A bit surprisingly the Date Modified value did not change:

<Field Name="Filename">\\Ab-h\share\test\04 - The Times They Are A-Changin'.flac</Field>
<Field Name="Date Modified">1270917097</Field></Field>

<Field Name="Filename">\\Ab-h\share\test\Copy of 04 - The Times They Are A-Changin'.flac</Field>
<Field Name="Date Modified">1270917097</Field>

4. Then I did "Run Auto-Import Now". MC reported:

Library now has 103136 files. Search and update took 0:22.
Imported 0 new files.
Updated 1 file that had external changes.

In-depth details:
Updated:
    \\Ab-h\share\test\Copy of 04 - The Times They Are A-Changin'.flac

... and the new Date Modified value was imported:

<Field Name="Filename">\\Ab-h\share\test\04 - The Times They Are A-Changin'.flac</Field>
<Field Name="Date Modified">1270917097</Field>

<Field Name="Filename">\\Ab-h\share\test\Copy of 04 - The Times They Are A-Changin'.flac</Field>
<Field Name="Date Modified">1315925571</Field>

Apparently the file system does not report a changed Date Imported value immediately when the file is on a network share. I opened a Windows Explorer window that displayed the files and the dates and repeated the test. The new value was displayed automatically, but that took over 10 seconds. In my case the shared folder is on a Windows 7 machine and the MC is running on an XP machine. I have a fast wired LAN.

EDIT

When the same files are on a local drive the process works as expected, the Date Modified value changes immediately also inside MC and a subsequent import does not "update for external changes".

[Matt]

I can also reproduce this.  It's a Linux Samba thing.  After closing a file, the file system reports the wrong date modified for about 2 seconds.

It doesn't occur with local drives or Windows shares.

We may add a delay after tagging before updating the last modified time to avoid this trouble, although it seems like a Samba bug to me.

[Alex B]

Hmm... My test files are on a Windows 7 share and the delay seems to be over 10 seconds (as I reported).

I would not like to see any significant delay in the tagging process. Of course if you can just delay the final update for a certain amount and still tag as fast as possible that would by fine (i.e. do not delay the tagging process of each tagged file individually).

[Vocalpoint]

When the same files are on a local drive the process works as expected, the Date Modified value changes immediately also inside MC and a subsequent import does not "update for external changes".

Yep - I saw this too...as I never get that "update for external changes" messages with a library that is local to this machine.

I also saw a very long wait with no "date modified" changes within MC until I did an actual re-run of Run Auto Import now. Well over 10 seconds with files on a Windows server share...so it's not just a Samba thing...

I also think that any modified dates need to be retrieved and written ASAP - especially if the change is coming directly via the UI. The date modified field should change immediately after the change is completed.

So - possible fix at some point? Glad I finally have a bit of info on what's actually going on here.

Thanks!

VP

[Alex B]

Actually this is not MC's fault. The operating system reports outdated data when MC asks for it. The date modified value is maintained by the server OS and there seems to be a delay before the client machine reports the changed value.

I can reproduce the problem simply by tagging a network file and doing "Update library from tags" (without running Auto-Import). The tag change is written correctly and immediately (i.e. as fast as possible), but if I want to see the correct Date Modified value I need to wait several seconds before doing the update.

[Matt]

Hmm... My test files are on a Windows 7 share and the delay seems to be over 10 seconds (as I reported).

Sorry.  You posted after I had typed my response.  Interestingly Windows 7 shares here don't exhibit the problem.

I'm not really sure how to proceed.  I suppose updating the size and time right away and then again after a delay might be reasonable.  I wonder if there's any way to know if a delayed update is necessary, by comparing the different file times or something?

[Vocalpoint]

Actually this is not MC's fault. The operating system reports outdated data when MC asks for it. The date modified value is maintained by the server OS and there seems to be a delay before the client machine reports the changed value.

I can reproduce the problem simply by tagging a network file and doing "Update library from tags" (without running Auto-Import). The tag change is written correctly and immediately (i.e. as fast as possible), but if I want to see the correct Date Modified value I need to wait several seconds before doing the update.

Hmm..so I just pulled up a track in MC - with Windows Explorer open along side MC. I make a change in MC...the change is written successfully. I immediately refresh Explorer and see the modified date change out on the server as fast as humanly possible. But then when I hit Refresh in MC - it's Date Modified column - never changes. Until a manual import is done.

So - what I am seeing here is - tagging is instantaneous between MC and the external file target (MC->File). But retrieving updated data (File->MC) when clicking Refresh in the interface - does nothing? Something? Isn't refresh supposed to pull the latest data on the file. Or better yet - why isn't the Data Modified field in MC's db/library updated immediate with the time-stamp of when I pressed the button to make my change? Which brings me right back to my original question.

Seems that there is a serious disconnect with MC's date modified field and the act of pressing a button to make a tag change via the MC UI. Logically I would expect Date Modified to be written to the db/library AND to the file in the same instant. But it seems that is not the case. I can only get fresh "Date Modified" data in MC following a manual import now.

VP

[Matt]

So - what I am seeing here is - tagging is instantaneous between MC and the external file target (MC->File). But retrieving updated data (File->MC) when clicking Refresh in the interface - does nothing? Something? Isn't refresh supposed to pull the latest data on the file.

You would need to use 'Update Library (from tags)' to refresh database values from disk values.

Logically I would expect Date Modified to be written to the db/library AND to the file in the same instant. But it seems that is not the case. I can only get fresh "Date Modified" data in MC following a manual import now.

The problem is that the network share returns stale values, despite tagging being finished and the file being closed.  The file system isn't doing its job, in my opinion.

[Vocalpoint]

The problem is that the network share returns stale values, despite tagging being finished and the file being closed.  The file system isn't doing its job, in my opinion.

I guess I still am not clear why the db must rely on the files "modified date" when the real modification takes place when I click the button in MC to make a change. I see it like this:

1. I make a change
2. Tag field on file is changed (or whatever)
3. File "modified date" updated
4. DB/Library reference  to file "Date Modified" updated

Or better yet

1. I make a change
2. DB/Library "Date Modified" updated
3  Tag field on file is changed (or whatever)
4. File "modified date" read from Step 2 (DB Date Modified) and sent to file.

VP

[Alex B]

MC does not directly write the Date Modified value to the file system data. The OS maintains it. Perhaps MC could write the current time stamp to the database field at a certain stage during the tagging process, but the value would not necessarily be accurate within one second as required, especially when the file is on a network share that has a separate clock.

By the way, I just noticed that the same +10 s delay shows up also on the server, not just on the client. I had the "dir" command ready for running in a CMD window on the server. I tagged a file on the client and about five seconds later pressed enter on the server's keyboard. The displayed data was old. It was correct after a few more seconds.

[Matt]

In a coming build:
Changed: After tagging Media Center explicitly sets the last modified time of the tagged file instead of assuming the file system will do it automatically (because network file systems are sometimes slow to update automatically).

[Alex B]

I just tried the same with Mp3tag. It works differently. The server file got the time stamp from the client clock (I changed the server date and time to test this) and the update was apparently immediate. Mp3tag can write the Date Modified value over LAN to the server file system. I wonder if MC should/could do the same.

EDIT

In a coming build:
Changed: After tagging Media Center explicitly sets the last modified time of the tagged file instead of assuming the file system will do it automatically (because network file systems are sometimes slow to update automatically).

So it will work like Mp3tag, correct? (You posted while I was testing and typing my reply.)

[Vocalpoint]

The server file got the time stamp from the client clock (I changed the server date and time to test this) and the update was apparently immediate.

This exactly what I was getting at. Having MC set the modified time instead of waiting around - great job guys on the upcoming fix

Cheers,

VP

[JimH]

To be clear, this appears to be an OS problem, not an MC problem.

[Matt]

I agree with Jim.

If I open a file, write to it, close it, then ask for the modified time, it's pretty unexpected for the modified time to still be a month ago.

Local disks work fine, so it's related to how the networking stack works.

We live in an imperfect world.

[AoXoMoXoA]

Local disks work fine, so it's related to how the networking stack works.

We live in an imperfect world.

I guess I forgot to mention that all my files are local?

[JimH]

Try the tests above.  Alex's, for example.

To be even more clear, Windows does not always do what you might expect.

[Vocalpoint]

To be clear, this appears to be an OS problem, not an MC problem.

Well - I would still like to know why MC's db/library is not instantly updated "first" with the only true "date modified" time stamp that matters - the actual instant that a user makes a change from inside the UI. Then a very, very distant second would be to understand why MC would even bother retrieving timestamps from the actual files (when the db timestamp would be true and deadly accurate) now that we have shown that several OS's do their own thing on their own sweet "non-accurate" times.  

In the end - all I care about is ensuring that MC is accurately recording, displaying (and reading) the REAL when from data recorded in the actual db/library - and could really care less about what Windows wants to display for it's file modification times.

VP

[Matt]

I think you may be misunderstanding the date modified field.

It's the file system date, and is used for comparing the library to the file system.

Storing a date that doesn't precisely match the file system's clock would defeat the purpose of the field.

[Vocalpoint]

I think you may be misunderstanding the date modified field. It's the file system date, and is used for comparing the library to the file system. Storing a date that doesn't precisely match the file system's clock would defeat the purpose of the field.

Yes - I now realize it's the actual file system date. And since MC cannot get an accurate (and real-time) read of the actual file timestamp - this effectively renders the library always "late" for a network files (that have had changes) and will always display that messaging about "external changes"...which they are not.

My takeaway on all of this is finally clear - MC will always require a manual import run to self-correct any timestamps for any file not located on the machine where the library resides. And that "external" message will always appear. Sorted!

VP

[Matt]

As I said, we've found a workaround:
http://yabb.jriver.com/interact/index.php?topic=66413.msg445813#msg445813