But running ROCK on such a server is not a supported platform in the first place. Then it seems that your first feature request would be to expand the supported hardware of Roon OS from certain NUCs and Nucleus to server hardware. (Not going to happen)
Nope! It runs fine for the last 3 years – I’m not asking for official support for non NUC platforms, unofficially it works perfectly and I understand if it goes wrong I’m on my own.
1 Like
I run one of my ROCK installs solely as an endpoint.
What more do you want in this regard?
I understand that it works on many MOCKs, but generic hardware is not supported. It seems far fetched that they would implement features for an unsupported platform.
Yep, thats fine – but they asked for suggestions / input…
Better explanation from Danny here: ROCK on Hyper-V - #12 by danny
Yeah I missed that Danny already addressed this above
Hmm, not sure you realize that you can run ROCK as endpoint only right now and always could, but OK.
1 Like
RAID1 is for speed (read) and redundancy. Don’t confuse redundancy with backups and failure recovery. If it’s 5pm on a Friday and a disk crashes I want to deal with it the next day. Mirroring allows me to continue enjoying my Friday evening as I intended with some music. Consumers often don’t have redundancy options. RAID1 is a cheap way to get there.
LVM and simple volume pool management would actually be pretty nice. “You have two external drives of similar size. Do you want these mirrored before formatting?”
2 Likes
+1 for more logging
like:
- temperature reading
- cpu usage
- ram usage
- disk io
- network speed
and maybe insight in the number of connected users - device - arc vs roon remote etc
Since a potential cause of a corrupted database is a power outage, an interface with a UPS to automatically shutdown in the case of a power outage would seem to be a necessary option…
1 Like
something like apcupsd would work for me. 
1 Like
music streaming is a real-time (time-dependent) process. latency is a key metric.
1 Like
Triple yes yes yes yes.
1 Like
Live streaming is real-time. Music streaming is a well-understood non-real-time process, implemented by dozens of apps everywhere. Latency is an issue, to be sure, but not an insurmountable one. Not clear it’s a “key metric”.
Not looking for a debate, and I realize the DAC should use buffering so theoretically latency of the server/streamer shouldn’t matter. However, in my listening tests with my Chord DAVE the lower the streamer latency, the better the sound. Many others have found the same. Do wish I had a clear understanding of the mechanism.
Sure. Much clearer when you cite your experience with a particular DAC/amp combo, rather than stating it as an axiomatic certainty. I see there is some controversy over whether the DAVE is well-designed; perhaps it’s just the box that’s the issue.
ASR / Amir, lol
1 Like
I know a bunch of folks (@Chris_Camphuisen @ipeverywhere @ogdens_sliced) have already asked for it and discussed it above, but I’m new to the whole rsync thing. Because of my particular situation - NAS in Home A, Rocks in Home A and Home B, OpenVPN site-to-site between Home A and Home B, using rsync to mirror full music directory from NAS master to USB-connected storage on ROCKs in both Home A and Home B. Having a mounted deep-linked directory from Home A ROCK on NAS in Home A is fine. But when I’m rsyncing across a tunnel, I’ll take every bit of efficiency and stability I can get, and having a mounted deep-linked directory from Home B ROCK USB storage on NAS in Home A always seems a bit fragile and possibly inefficient.
Here’s the feature request I could find… I’m the only vote currently!
2 Likes