Do i understand that if i upgrade to OS2.0 i will no longer be able to use my NUC running ROCK as a ROON core since it is connected to my network wirelessly by WiFi ? It is a 7th Gen i7 so currently works beautifully connected via WiFi…/ never ever had a single issue . If it means i can’t run it wirelessly i have wasted my money on a lifetime subscription since that is the only way i can do it.
I seriously doubt your conclusion is correct, but if you have concerns, why would you upgrade at all then? Remember we’re discussing RoonOS here, not Roon as such. And your core will continue to run 1.x as long as you wish.
Does Network bridging mean, I could have a direct Network connection between Rock and the streamer, without having a static IP on the streamer, as it is needed now? Could imagine, that this could be addl. improvement in soundquality, due to no devices between Rock and Streamer which could introduce addl. noise
Not sure it has been mentioned here before, but there’s one issue that keeps bothering me.
On one of my ROCK NUC’s, I have an interna 4Tb SSD and an external 4Tb portable drive for the less used parts of the library.
Problem is, that the external drive (which was originally cloned on a Windows 10 based computer) is reporting file creation dates which is off by two hours. I think this has got to do with the Roon OS not taking local time zones into account.
I use robocopy scripts on one of my Windows cans to sync my file library to various Roon Servers, and this one is the “black sheep” of the flock. The robocopy sync is run with the /DST option to allow for Daylight Savings time differences, but this doesn’t remedy this situation.
As I don’t feel the need to copy almost 4Tb over the network to this drive all over again, I have made some half wit work arounds in the copy script to allow for this.
Still, I think this wouldn’t be an issue if the Roon OS allowed for time zone differences.
@Mikael_Ollars, this is not correct reasoning. The file times are always stored as UTC. Only the display of the file times is impacted by local timezone.
I was just able to confirm this on my ROCK install here. Here were my steps:
on my Mac, open a terminal and type touch test.txt
type ls -l test.txt and confirm that the dates are in local time, and are from about 1 second ago
mount the //ROCK/Data share and copy test.txt there
look at the file times using Finder and the cmd-i File Info popup. Note that the times are still from a few seconds ago.
I have special access to get into ROCK, so I went into the box and confirmed the date on the file, and it is a few seconds short of 4 hours from now, but UTC. Given that I am on the east coast of the US, that sounds right.
Copy the file from //ROCK/Data/test.txt to my desktop, and check time using cmd-i. Confirmed same timestamp (local time) as the original test.txt file.
You may of course be right! And if i follow your steps, i get the same result.
Let me explain with pictures, but first some background. I use a Windows computer with a drive array of three 3Tb hard drives, this is used as a back up and template for my media which is to be syncronized to my ROCK and my other servers. Originally i attached the 4Tb portable WD Elements drive to this Windows PC and cloned a part of my library to it, locally. I have the correct time zone set up on the Windows PC, UTC+1h.
This drive has since been relocated to secondary storage on my true ROCK setup (NUC8i3, in a fanless enclosure).
With the WD Portable attached to the ROCK, i mapped the ROCK to the Windows PC, as Z: and created a text file, “Nytt textdokument.txt”.
I opened this file in Notepad, pressed F5 to insert current time+date. This is correct, but notice that the file creation date in the screenshot is an hour behind.
I shut down the ROCK, took the WD Portable to the Windows PC and attached it. I opened the text file, inserted a new line and pressed F5 once again, the inserted text once again is correct:
This is because you used two operating systems in your example. In most cases people are just interested in the data to become accessible on the other OS, completely ignoring the metadata that comes attached to i because it is of no special interest to them. In your case however, if you’re interested in correct metadata you have to copy over the files using CIFS/SMB which will correct the incompatible/“wrong” metadata. But seems you don’t want to - so you have to live with the situation.
As it looks to me that it is primarily Windows that is at fault here, I don’t see how a Roon OS 2.0 could change Windows behavior or how/why they should change Linux if it’s maintainers where unable to “fix” this in the last decades. This is actually no news.
Note: These are possibly not the sources with the best information about it, but the best I were able to find in a reasonable amount of time. Information is plenty as the problem is old and the cause for it buried somewhere in operating system history.
I cannot dispute any of this, and maybe i could remedy this by copying the files once again.
It may for sure be a Windows “issue” which surface here, but both NTFS and exFAT store file stamps in UTC so this should not be a problem. The WD does have exFAT as FS.