ROCK Accessing NAS Often [Expected Behavior]

Also - you say the ROCK is shut down after usage. First question - is that done gracefully so the database remains ok in any case? Secondly - why? There is a chance these scans of the library are triggered by this.

Roon, as far as I know, will always undergo a full rescan on startup. That is one reason to never shut the core down.

@rugby @Bernd_Kurte @Graeme_Finlayson @noris
What I was trying to say is that IF I were to shut down my NUC running ROCK then my hard drives DO go into standby mode. This tells me that ROCK is the guilty one that is banging on my hard drives and preventing them from going into standby mode. ALL I really ever wanted is for ROCK to leave my NAS alone if I haven’t listened to any music in an hour. This is NOT a difficult requirement to understand is it?

Tim, my understanding of how Roon operates is that it looks at your library and provides you information about the music in your library - main artist, contributing artists, discography, artist info etc. All of this information is saved in the database. Your ‘library’ comprises your local/networked music plus any streaming service provided music you have ‘added’ to your library. Roon uses various online sources to keep this information accurate and up to date. It also keeps track of what you’ve listened to, hours listened etc. etc

Presumably, this means regularly scanning your music library (NAS) storage plus streamed stuff added to your library and updating the database (SSD) on your ROCK.

All of this means that your NAS HDDs and your ROCK SSD are going to be accessed frequently.

I stand to be corrected, but I don’t suspect anything is broken here - it’s just how Roon works.

And honestly, drives aren’t that fragile. I have Seagate Ironwolf Pro HDDs in my main NAS array. I have 12 drives which have been running 24/7 for 4 years. I have had 2 drives fail in >420,000 drive hours, or 1 drive in >210,000 drive hours. For a single drive, at current use rate, that’s a lifespan of ~24 years.

Stop worrying about it.

Where is @noris.??? He KNOWS how ROCK works. You guys are just guessing at how ROCK works?
I want NORIS to tell me that this is HOW ROCK works. My digital music files are on my NAS. My ROON library is a SSD drive installed into the intel NUC. My Re-scan internal is set to 12 hours. There is no reason ROON needs to scan my library (or whatever it is doing) every 5 seconds which is EXACTLY what it is doing. I have my re-scan interval set to 12 hours. We don’t even know that re-scanning is what ROCK is doing? I would like to KNOW EXACTLY why ROCK is banging on my NAS every 5 seconds. Its been over 2 months and NORIS has refused to answer my questions.

Tim, please turn off your Caps Lock and stop shouting :wink:

The Re-scan interval is how often Roon checks for changes in your music library. That’s different from Roon checking for amended information on the music in your library from its various online information sources.

@danny @brian could you shed any light on this issue?

Tim, you’re a software guy. Have you fired up WireShark yet and captured the packets going to and from the NAS? It would be good to know just what SMB packets are coming from the Nucleus to cause this behavior. If you have, maybe sharing the packet traces here, or parts of them, would let us help you?

1 Like

Thanks, Michael. Yes, I’m kind of a protocol nerd, so I’d love to see some traces. But the real key is that post by @mike from 3 years ago, on exactly this issue:

And everyone should feel free to open a feature request related to us changing how storage works in Roon – this would be a big change, so we would want to see real interest in this kind of use case.

Roon support doesn’t see this as an issue. I can just picture the dialogue at the support desk:

“Hey, this guy TKelley has a problem with his set-up. The Core keeps banging on his NAS.”

“Yeah, that’s not a configuration we do well.”

“Where should I prioritize it?”

“Is his system still running? Can he play music?”

“Yeah, it looks like everything works, he just doesn’t like this part of it, and doesn’t want to change his configuration.”

“Well, if everything’s working, it’s a feature request, isn’t it?”

“Oh, yeah, I see. OK, I’ll send it to the development team to add to their queue.”

And let me say again: from three years ago. Don’t hold your breath.

2 Likes

Hi Tim,

Back on March 1, Michael-W posted a link, I will re-post it for you, in case you missed it. It might answer some questions.

Edit: re-saved the link to make sure it pointed to the specific post in that thread.

@Bill_Jansen its not by job to setup wireshark and debug ROON’s software for them.
That is what THEY are supposed to do. They do get paid real money right? My money?
Are they volunteers? Are they summer interns? Have their system architect call me and we can
debate this “feature”. I spend ALL day long staring at WireShark traces. Do you think I want to come home and look at ROON’s WireShark traces for them. Where is @noris? is he on vacation? Does he have covid? Does he care less that a customer is unhappy with their support? It’s just a simple thing? I’m a little shocked that ROON doesnt care. It’s not really a difficult thing to fix either. There are alot
of other software packages out there that do some incredible things with a NAS. Why is it so hard for ROON developers to get it right? It’s not hard. I have come to now understand ROON’s philosophy on their customer support. Don’t respond for 14 days and maybe he’ll let the topic close out.

Hello @TKelley ,

Thank you for your patience here while your case reached the queue again.

I spoke to the team today regarding your case and we have just enabled an advanced diagnostics mode for your ROCK which should make the NAS background activity a bit clearer.

Can you please reboot your ROCK Core when you have a chance and we can take another look at the advanced diagnostics just to make sure we aren’t missing something else here?

Thanks!

Okay thanks @noris.
I rebooted my NUC running ROCK via the ROCK web user interface
I will try to be more patient. Its hard when a week goes by and I haven’t heard anything from anybody!

I’m okay with checking on a regular basis, but do you need to do this EVERY 5 seconds? How about every 15 minutes? How about only doing it during the configurable re-scan interval. Why do you care whether the NAS is on or not? You should only ping the NAS if its time for the re-scan interval or the user wants to play some music or when the user picks up his iPad.

2 Likes

In response to @Graeme NAS being slow???
My NetGear router has an SFP+ port on it and my QNAP NAS has a 10GBe PCI board plugged into it.
I have NEVER had a problem when playing my music. This is the way to go! F-A-S-T

Hi Tim, didn’t realise your NAS had 10GbE. Maybe a dumb question, but did you consider running the core on your NAS rather than on a ROCK? There’s no way I’d downgrade to a ROCK/Nucleus from my current NAS setup.

Hello @TKelley,

Thank you for your patience here while we consulted further with the team on this. Based on the advanced diagnostics, it appears that Roon is checking for the drive availability and this is the reason why you notice the activity occurring on your NAS.

At the present time, this is expected behavior and as per Mike’s comment in the linked thread and any change in this functionality would fall under a feature request and would require considerable design changes:

Regarding Mike’s second part of the post (and the issue that @Michael-W is encountering) of accessing the NAS when the storage location is disabled, this is not expected behavior, and we are investigating this in a separate thread.

I wish I had better news for you here, but due to the way that Roon storage currently works, it is expected that Roon will check to see if the NAS is still available as a storage location, and this may prevent the NAS from entering power-saving mode.

2 Likes

Is @Michael-W issue related to my issue at all? sounds like the same issue to me.

I have to say, this strikes me as an odd thing to say.

Right now the Core is scanning removable storage (local or remote) periodically to see if it’s been removed, right? It does this every 5 seconds. But there must be some provision for handling exceptions when playback of music on an ejected volume is commanded between those 5-second checks, right? So lengthening the interval between checks, or turning them off entirely, and relying on the exception handling, can’t possibly be a big change. Add a binary toggle to each storage location, let the user turn checks on or off, and be done with it. Whatever you’ve got in there to handle the exceptions will catch any problems.

I find it difficult to imagine a software architecture which would make this a big deal. Though it’s clearly a feature request, not a support issue.

3 Likes

Completely agree Bill. Very disappointing response from Roon :frowning_face:

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.