There are 2 ways to do this:
Most receivers these days offer IP Control. Denon/Marantz receivers and processors since 3 years ago have IP based API.
Yes, my AVR (an Anthem MRX 520) supports both. It’s great to hear that HDMI-CEC volume is on your list.
Meanwhile, is IP control something I could set up in Roon without previous experience with extensions? Is there a guide that would help me get started?
Thanks, @Enrico_Castagnetti, for expanding on the IP control option.
I have the same interface on my Marantz. Can you actually change the volume using that interface? I seem to be unable. I’m using API calls from a RPi4 running openHAB. Yes, just for volume control.
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.
There are simple and cheap ways of getting WiFi to Ethernet if you had to.
HDMI CEC Support (if the core can turn on my AVR/pre amp remotely when play button toggled this one would be very nice)
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
Network bridging would not impact sound quality, just convenience, eg, a direct core to endpoint.
Be nice to have a ups backup option too…most ups these days are standard usb interfaces and or a NUTs client would be another option.
Yes it would allow that. The primary benefit would be convenience, any others would be on a case by case (and user) basis.
Is there an approximate ETA of Roon OS 2.0 for ROCK?
My vote would be for securing the web ui and smb share.
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:
touch test.txt
ls -l test.txt and confirm that the dates are in local time, and are from about 1 second agotest.txt there
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).
So, i did a similar test as yours:
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:
So, even if you are correct, this does not gel very well for me at least…
+1 for UEFI, that would allow installation of ROCK on older Mac’s.
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.
Some reads (for interested people only):
http://www.peterdonis.net/computers/computersarticle3.html
Filesystem Timestamps: What Makes Them Tick?
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.
