Roon OS Update Forcing Re-Analysis

Roon Software Discussion ROCK
1

I just applied the ROCK update to my NUC , it has now taken off Re-anlysing my library

Is this normal.

I checked the Back Up there were around 100 files that had changed due a metadata correction, I would expect these to be re analysed

I am at 10000 / 50066 and still counting !!

EDIT:

It would seem to be the external USB drive (57k tracks) not the Internal SSD

EDIT 2

All the file date stamps are 2 hours out !!, this drive was backed up 2 days ago .

This is SyncBack pro , comparison of files , what has changed these times

image
image1848×202 32.5 KB

Any idea, I am just letting it run for the time being

2

ROCK (or something) would seem to be reporting wrong date/time stamps by exactly 2 hours ?? My regional settings are GMT + 2hrs Coincidence ?

There was a Windows update recently.

This is an album on ROCK attached USB Drive

image

and from a backup taken 2 days ago read through Windows 10

image

3

From RoonOS (Nucleus / ROCK) build 254 production is live!:

includes vastly improved support for USB storage devices formatted with the exFAT or NTFS filesystem.

Don’t know what you expected. Read/write access was already possible before so the “improved support” is likely in metadata handling only – which also implies that changed behavior may occur.

So exactly what you experience here.

4

A little warning may have helped …

@AMP are you aware of this ??

Not quite the case here . It would appear it has altered file date/time stamps at least how they are read.

What I expected was a seamless update :sunglasses:

What does “Vastly Improved mean” ? There is a new exFAT Driver - I Wonder …

This morning I updated the ROCK software , it seems to be reading the date stamps different from the 3 back ups by Exactly 2 hours (the 3 BU are all the same as per the pics above) so Roon sees them as changed files and re-analyses them.

According to Settings Storage the USB drive has 57763 files, Settings > Audio Analysis is currently 36950 / 50203 so I am even more confused

It will be over soon and as long as it’s a once off I’m OK but I will have to Re BU the 3 drives I did last week !! Painful.

This is a NUC/ROCK with a 4tb SSD internal. I last week attached a 5tb USB HDD formatted exFAT. 6 months trouble free

Just like to know what’s happening !!

5

No, RoonOS operates in UTC so it’s reporting timestamps two hours behind your computer set at UTC+2. Nothing has actually been changed with the files themselves.

We were not aware of anyone experiencing an issue like this and we had hundreds of testers involved in this release.

6

Hi Andrew

But those were the timestamps on the back up drive. The 2 images in the second post are taken from an album on the ROCK USB drive and the USB BU Drive finished less than a week ago, they are different . All 3 BU drives agree. One or two albums I can accept but the entire drive (and after a software change) I find suspicious , wouldn’t you.

What else could have caused it ? The USB drive in question has only ever been connected to ROCK ,except for its initial formatting under Windows it was brand new, formatted exFAT as recommended and the loaded with 50k Files via ROCK (Not windows) and then backed up from the ROCK to main PC and then to USB

The 4Tb SSD internal drive has not been affected so it looks like something USB to me

I use SyncBack pro which Backs Up only changed files , I Mirror with the ROCK USB as source , the BU Drive as Destination , a procedure I do every 2-3 days

I literally finished backing up on Monday (the USB drive is a new addition in the last week or 2) , if I ran the Back up “MIrror” once complete it would do nothing because the drives match , as it did and should

I backed up to 2 USB External drives and one HDD in my main computer all of which show date/time stamps 2 hours out compared with ROCK.

This morning doing exactly the same procedure SyncBack wanted to copy 50k + files because they were “changed” ie the drives no longer matched, the details of the first post show the dialog difference screen . (the green & red pic)

ROCK either changed these files or changed the way they were reported such that SyncBack believed they were changed !! I still have to start that BU process so at the moment my BU drive reads 2 hrs different from the ROCK USB drive .

Also if there was no change then why did Roon OS re-analyse 50k + tracks this morning which it did , it still hasn’t finished. I spotted it because the NUC was noisy due to working , something it never is normally

Its not a train smash but now I have to repeat the BU exercise while dodging power cuts ,last time it took me 4 days (I can’t leave jobs running overnight due to power cuts)

This is what SyncBack is showing me NOW , 1.2 Tb of “Different Files”

image

Nobody else noticing it does not explain the facts !!

An explanation would help, before it happens again. What am I missing ?

PS UTC + 2 is in fact the time setting we are on in South Africa. I created a new txt file which was correctly time stamped so Windows is behaving

When SyncBack copies it retains the original time stamp on the copy so eventually the 2 drives match

7

What explanation do you expect exactly? You already found and documented the changed behavior in reporting timestamps which seems to be the explanation. The main issue here is FAT/ExFAT with its vague definitions.

Not when done over the network. Timestamps get interpreted in this case and obviously the new driver in Roon OS changed the interpretation rules.

8

The changed behaviour should have been anticipated and warned about in the release notes (Ironically I did read them before updating) , the explanation I want is whether its something else or just a USB “Thing”. If I hadn’t added the external USB drive I would never had noticed . Did any of the beta testers have external USB formatted exFAT ?

I was under the impression that ROCK required drives to be formatted ex FAT and not NTFS, I must have read it somewhere. I deliberately didn’t choose the Windows default NTFS.

Maybe this update removes that limit , 2 weeks too late for me !!

I am just a bit p***ed off at repeating the BU process all over again , and the fact that Roon has been occupied all day (even of all 12 cores) re-analysing a good portion of my library. This should not have been necessary .

We are getting power cuts 2 or 3 times a day at the moment, running an overnight BU job simply cannot happen , this adds to the frustration.

9

I can feel you. If you’re interested in the thematic, you can follow the past discussion and explanations posted in What’s coming in Roon OS 2.0 (not Roon 2.0, but Roon OS 2.0)?, starting with:

and following related posts down until:

With NTFS you should not encounter such issues because it clearly defines the TZ for timestamps. Also ext4 should work the same. ExFAT is recommended for portability (ability to use the drives with different machines running different OSes) of the data. Sadly the metadata, like timestamps for example, doesn’t necessarily have to have the same portability as the data.

10

Interesting that it was spotted a year ago @Mikael_Ollars

I am not bothered what time stamp is used, it doesn’t affect anything, my gripe is tha something has changed.

The ext USB drive was put in the ROCK formatted but empty and the copied to so any time stamps would by ROCK ones. I think I probably used Sync Back so time stamps would have been preserved. Indeed the BU once everything was finished show so.

My sync software doesn’t change the time stamp as it writes to the BU so at the end the drives match until a time stamp changes. Something clearly has changed. The end state of my BU process was that Sync Back required no file transfers as it should. Today after the upgrade it asked for 1.2 tb of copy , ie the whole USB drive. I DID NOTHING To required this so ROCK must have

Never mind back to listening while I BU all over again :sunglasses:

11

Would reformatting NTFS and starting again make any difference?

The drive in question will only ever be plugged into the NUC so portability isn’t an issue

12

Aside from the benefits resulting from the overall more modern architecture of NTFS over FAT it should prevent from (potentially) changed interpretation of timestamps in the future (because file timestamps and their interpretation are defined for NTFS).

Note: For FAT-derivates the interpretation is defined by the driver used and the driver changed with current Roon OS and obviously also led to a different interpretation in this case.
To repeat what AMP already wrote: “Nothing has actually been changed with the files themselves.”

PS: I personally would avoid FAT-derivates in use cases that rely on correct metadata (primarily timestamps) like for example backup by timestamps (because they are not reliable as demonstrated).
This time it was Roon OS, next time a change in Windows (version) might lead to issues (maybe not in your current use case specifically because AFAIK timestamps and their interpretation in SMB/CIFS are also properly defined).