Not having received a report from @eric about what to do I’ve decided to try something different. I’ve just manually ran one of my backups. Thus I suspect the scheduled version of that backup will start running again in the morning. It will be interesting to see if the other backup runs, or stays in the failed state.
Hi @Lloyd_Borrett ---- Thank you for the feedback and my apologies for the delay here.
Upon seeing your most recent posts this morning, I went a head and enabled diagnostics on your account so our team can have a look into the mentioned time frames above in the Roon logs attached to the report. I have now tried to re-enable this feature on your account three times and the report does not seem to be making it over to our servers.
In the interest of not wasting any time here, may I kindly ask you to please use the instructions found here to send us a set of your Roon logs from the NUC hosting ROCK. The logs can be sent to me in a PM.
Thanks!
-Eric
An update. Manually running just one backup caused both scheduled backups to run on the morning of 16th May.
A bit confused. The instructions say…
Remember to ALWAYS shut down your Roon Core before copying, moving, or accessing your Roon database.
But I can’t find instructions about how to shutdown Roon Core on my Intel NUC ROCK?
Shutting down the entire ROCK means no access to the files.
I’ve tried not following that part of the instructions and just creating a Zip of the Logs folder anyway.
Can’t upload a Zip file as part of a PM.
on the web interface you can stop roon
Hi @Lloyd_Borrett — Thank you for the follow up and the PM. Very appreciated!
Confirming that the the logs have been received and are now attached to your ticket for evaluation by our tech team. Once they’ve completed their analysis and have updated your ticket, I will be sure to share their findings with you ASAP.
Your patience during this process is very appreciated!
-Eric
this is only if you are manually touching the database files. If you are using Roon to restore or backup, then you don’t need to shut anything down.
your logs do not show backups configured to run on the morning of the 14th or 15th.
your logs show that they were configured to run at 1600hr and 1700hr (UTC – London timezone) on the 15th, and it ran just fine.
The results don’t match with the logs that I’m seeing here.
Could you please reproduce this today/tomorrow and resend the logs?
@danny You need to take a few things into account. First, I’m in Melbournre, Australia GMT +10. In Roon 1.4 there was a scheduling date/time issue. To get the backups to run a 1 am and 2 am in the morning, I had to schedule them for the afternoon. That’s been fixed in Roon 1.5, but maybe not in the log information.
Backups worked on the morning of the 11th (log afternoon of 10th). Backups failed on the morning of the 12th (log afternoon of 11th) because music was playing. Backups failed to run on the morning of the 13th (log afternoon of 12th) even though music wasn’t playing, and continued to fail to run on the mornings of 14th and 15th (log afternoon 13th and 14th). Did the logs show all of this?
My backups are scheduled to run EVERYDAY. But if they fail to run on any given day, say because music was playing, they don’t run the next day, or any day thereafter. They enter and stay in some sort of unscheduled/suspended state. THAT’S THE PROBLEM.
Not until I run the backups manually does this blockage free up and the scheduled backups start running again.
If you’re not seeing this in the logs I’ve already sent, then I suspect you just don’t have the right information being put into the logs. So maybe me going through it again won’t produce the log information you need anyway.
However, I will reproduce the problem again, and send the logs in a few days time. Meanwhile, why don’t you try and reproduce the problem on one of your systems. Maybe it’s not specific to my setup.
My setup is an Intel i7 NUC with my music files on a Synology NAS. One backup is scheduled to put the files on a SSD drive in the NUC, the other backup sends the files to a folder on the NAS.
Running at these scheduled times would have actually been the morning of the 16th for me. Did you notice in the logs that I did a manual backup between when the backup failed to run on the morning of the 15th and when they ran again on the morning of the 16th? This manual intervention is what cleared the blockage.
Update: My backups failed to run this morning because I had music playing. So if things go the way they’ve been, they won’t run tomorrow morning because Roon will now be in its blocked state.
By the way, unless I go and check the backup status deliberately I don’t get to see any warnings anywhere that backups have failed. It might be worth adding a warning somewhere in the GUI.
Just wanted to add my tuppence ha’penny worth… I too run Roon Rock on a NUC backing up to a NAS. When the back up fails because music is running (usually because I leave Radio running when I switch off my headphone amp and fall asleep) it never seems to try to back up the following day. It doesn’t even try 4 days later as per the schedule. The q4d schedule only restarts when I run a manual back up.
On the first occasion I didnt realise the back up hadn’t been run foe a whole month…
@danny I’ve just sent a PM to @eric with the link to another log file set.
It should show the two scheduled backups working, then failing the next day because music is playing, and then not working the day after that because backups are now in a failed/unscheduled/suspended state. That’s the state they’re currently in and will stay in until I run a manual backup.
I hope these log files will give you more information than the last set, but unless you’ve changed something to cause more information to go into the logs, then I doubt it.
REMEMBER: The logs will probably show the two scheduled backups running, failing, and not running an hour apart in the afternoon, I think at 4 pm and 5 pm. The real time they run/fail is 2 am and 3 am. Melbourne is GMT +10.
By the way, have you guys ever considered displaying the date and time of the ROCK on its web screen? Maybe even provide a way to set the ROCK’s timezone so that it matches the rest of our computers.
Hi @Lloyd_Borrett ---- Thank you for the newest set of logs, confirming they’ve been received.
Moving forward, I checked in with our tech team today and they have asked if you could please provide the exact backup schedules you are currently using and where the backups are being saved during both procedures.
-Eric
That information is already in one of my posts above. And notice how I’m not the only one having this problem. Have you tried reproducing it on your own systems?
Hi @Lloyd_Borrett ---- Thank you for the clarification and my apologies for missing that bit of information above.
Yes, our team has been testing in house which is why I asked for the backup schedule. We want to be sure that we match your environment/procedure as closely as possible 
Thanks again!
-Eric
Have you been able to reproduce the problem? Do you need any more log files from me?
Hi @Lloyd_Borrett — Thank you for reaching out to me!
I checked in with our tech team this morning in regard to your ticket upon seeing your latest post. As per our conversation, they are still testing/trying to make this behavior reproducible in house and at this time we are not in need of any additional logs. The offer is very appreciated!
Please rest assured that this is still on our radar and is actively being investigate by our techs. Once they have provided me some more feedback in terms of what progress they’ve made I will be certain to share their findings with you asap. Again, thank you for your patience during this process!
-Eric