Print

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

[Arindelle]

I have a standard backup procedure of doing an incremental backup of changed files every two days or so. I do an archive complete backup twice a month

The software  I use (SyncBack free version) does a simulated run which I check before letting it run.

What I found was that 84,093 files were "modified". All were modified at the same date (5/11/2013) ... all were modified within approximately a one hour time frame.

8,035 files were unmodified.

I dug deeper and found that only 266 files had actual changes to which should be backed up.

Doing a spot check of a number of  the balance of the "modified" files   :

None had any changes in file size
None had any attribute change
None had any metadata change (that I noticed at least)
ALL had their date modified changed to the same date, timed stamped < 2 hours difference

There was also no indication as to why the 8.035 remained "unmodified" -- date modified remained unchanged

There was no new JRiver version issued (using 19.0.67 which was loaded prior to 11/05)

The only thing I might have done would have run volume analysis -- however only 10 new cds were added, this had been done previously on my collection. I might have rebuilt some thumbnails ...

So, why were all of the dates modified? If it was a windows system issue or external program why weren't they all modified?

I'm more than a little leery of  overwriting my backups. Not to mention the time

sorry for the wall of text -- thanks in advance for any input

[AndrewFG]

There was another post somewhere from somebody with a similar issue. The consensus was that it was due to the recent clock shifts from Summer to Winter time. Even though your files may not have actually changed, your backup software may have been looking at the file date and interpreted the one hour time shift as a change...

[Matt]

It's possible the DST shift could cause MC to do 'Update Library (from tags)' on some files.  However, this should not change the data modified.  Also, I believe the issue has been fixed for good (it was related to strange DST handling in a Windows API for legacy reasons).

What type of files?  Could you test a manual 'Update Library (from tags)' and watch the date modified on the file system?

[Vocalpoint]

There was another post somewhere from somebody with a similar issue. The consensus was that it was due to the recent clock shifts from Summer to Winter time. Even though your files may not have actually changed, your backup software may have been looking at the file date and interpreted the one hour time shift as a change...

That was mine. Yes this is a DST thing where MC was thinking thousands of files had changed as of Nov 3 (or the first time you did a manual Auto Import after Nov 3).

I just did a manual with my test version of v19 and again I had 7491 "changed" files.

Hopefully Matt's new fix will take care of this

VP

[Arindelle]

It's possible the DST shift could cause MC to do 'Update Library (from tags)' on some files.    Also, I believe the issue has been fixed for good (it was related to strange DST handling in a Windows API for legacy reasons).

No, not an issue with DST -- our time change in France was 27/10 and had no problems. It was not shifted by an hour it was shifted by more than a month for almost all of the files. I know this because that is when I re-analyzed all my files (volume analysis) this summer. Also the file dates that were not changed and were all in august reflecting this. Maybe I wasn't clear but these "modifications" took around two hours to do looking at the time stamps.

What type of files?

only audio files - no folder.jpg or txt files (see attached screen shot)

However, this should not change the data modified. Could you test a manual 'Update Library (from tags)' and watch the date modified on the file system?

Well, the actual modification date was written to disk; I tested update library from tags like you suggested Matt, and there was no change to the file system. The only files that are changed are the audio files as you can see (see s.s.)

(or the first time you did a manual Auto Import after Nov 3).

THIS has something to do with it! I always manually 'autoimport". To test this I just ran autoimport manually again and 84 files were "modified" (date changed). Autoimport is updating files that I neither played nor retagged. These files were on my screen however.

For info, my "autoimport" config is only Update for external changes and Fix Broken Links. Most of my metadata fields are set to write to the file. (including import date^^)

Also, just ran it a third time and always see "analyzing files 1-8800" which appears after the scan of 90K files (see SS) ?

Has there been any messing around with the autoimport function recently? If so would keeping the tag window open open and then closing without making any changes be interpreted as a modification to the library? If so this would be a real drag, but it almost looks something like that is happening.

[Arindelle]

Version : 19.0.74

Just thought I would watch this for a week or so before bumping ... seen as how no one seems to still be having this problem, it probably is somehow network related on my end.

I still have intermittent issues testing with a small number of files.

I recorded some screen grabs during the import process with some unusual results.

For info my files reside on a D: drive path; they are mapped to a network drive Z:

A "copy" path was being created AND imported from another drive (F:) which is a backup drive and not referenced in jriver before

the text file you have to scroll down half way to see the F: drive files

[Vocalpoint]

Version : 19.0.74 Just thought I would watch this for a week or so before bumping ... seen as how no one seems to still be having this problem, it probably is somehow network related on my end.

We cut over to 19.0.74 on all machines here and are seeing no further import or DST issues.

On this one - I have seen this before but it was always my fault...where I somehow manage to rename something differently thus creating a copy - which is then read back into MC upon Auto import. Easily fixed.

In your case - it almost looks like you copied/moved some files to the backup drive (F:\) but MC still thinks they are part of your active library and then pulled them back in during auto-import?

VP

[Arindelle]

In your case - it almost looks like you copied/moved some files to the backup drive (F:\) but MC still thinks they are part of your active library and then pulled them back in during auto-import?

VP

well I do one of my backups to that drive.  Do you think syncingthe drive while mediaserver is up would do that? seen as how its a mapped drive? Thanks VP.  I'm going to try to look into that

[Vocalpoint]

well I do one of my backups to that drive.  Do you think syncing the drive while mediaserver is up would do that? seen as how its a mapped drive? Thanks VP.  I'm going to try to look into that

Here I never have any backup software or sync actually running against the Music share out on the server. Everything out there is tracked within the  MC library and only used by MC.

I create the actual physical archive (backup) copies when doing my staging routines. The only thing MC ever gets is it's own "play" copy of each album. The master archive files are moved and copied to two physical drives and taken offsite monthly. None of these archive files are ever entered into the MC library or ever subjected to the server.

I learned a valuable lesson several years ago when I lost a large portion of the library when a couple of mirror scripts went off the map...so now it's all about separation and isolation. Haven't lost a file since then.

VP

[kstuart]

Here I never have any backup software or sync actually running against the Music share out on the server. Everything out there is tracked within the  MC library and only used by MC.

I create the actual physical archive (backup) copies when doing my staging routines. The only thing MC ever gets is it's own "play" copy of each album. The master archive files are moved and copied to two physical drives and taken offsite monthly. None of these archive files are ever entered into the MC library or ever subjected to the server.

I learned a valuable lesson several years ago when I lost a large portion of the library when a couple of mirror scripts went off the map...so now it's all about separation and isolation. Haven't lost a file since then.

VP

I don't use automated backup software in my home setup, because as a software engineer, I expect the backup software to have as much of a chance of failing, or itself causing problems, as any other software.

Instead, I have a USB hard drive dock, and any important file (which includes my rips of CDs) is copied to the drive in the dock.  In the middle of the night, a scheduled task does a directory listing of all hard drives (otherwise if a hard drive crashes, you may not know what you have lost).

Then every so often, I change the hard drive in the dock, doing a directory listing.  The listings are all in a folder, and I can search that folder to find the backup of any important file.

I use basic DOS commands that could have been done in the 1980s, again for reliability.

[gh2060]

Hello
I have the very same problem as Arindelle, and had it for months
Every time I use MC 18.0.212 for it's audio function exclusively, without adding anything to my database (new Cd's or any modification), that generates several gigabytes of modifications on hundreds of wav files when I perform my regular backups using SyncToy
My concerns are first that MC might be tampering with my database and time consuming meticulous ripping of Cd's, and second that my backups take too much time when actual modifications are minimal
Obviously that does not seem related with MC's version since Arindelle is using the latest 19 version
Thank you for your feedbacks.
GH