Roon server status is that it is running but the roon back-up service thinks it is not. The system is hung and I need to re-boot. I tried that several times with the same result and then tried re-installing roon. Same result.
Everything else seems to be working but I cannot backup.
If I look at the status in “About” I see the roon remote is waiting for the Roon Server and yet I am playing music on two end/points right now:
@Ivan, I already posted the error message I get when I attempt a backup. See above. I get “Uh, oh, something’s not right”. Roon then hangs, becomes unresponsive and I have to re-boot. For the moment I have given up any further backup attempts.
This error message is just as uninformative to me as it is to you. Perhaps if roon issued a more boring but traditional error code, that would be more helpful to all parties with the diagnosis?
All I meant by “Everything else seems to be working but I cannot backup”, is that after updating to build 1353, I can play music but roon will hang if I attempt to backup.
So in a nutshell, not only am I experiencing terrible response and unusable search after the update to 1353 as reported by many others, in addition I can no longer make a backup.
Ok, thank you. Could you, please, reproduce this issue once again and upload a zip archive with logs from RoonServer here? Instructions on how to find your logs folder – link
I am getting a little confused. I have multiple scheduled backups and the one at 5am this morning to my D: drive appears to have been successful. Is there any easy way to verify that?
So I don’t know why backups now appear to be working. All I can think of is that I have re-booted multiple times so maybe I have “double-booted” as has been mentioned as a fix for performance issues. Also, my library is not the largest but it is largish and maybe some background process to do with the build 1353 update had to complete.
In case my logs can shed some light I can upload them for you but your instructions do not work. That link goes to an article not written yet page.
I can’t comment on anything else related to this issue, but I think I can explain this part. The failure is related to large changes in the number of server “objects” the client wants to be kept updated on. I would guess that the difference in behavior is due to differences in what pages you opened in the Roon UI between starting the client and starting the backup.
I would also guess that restarting Roon, either the server or remote or both, would be equivalent to re-booting the whole machine for the purposes of clearing the error state and letting you use the app again.
I think you are at least partially right. The same thing happened just today. My knee-jerk reaction to having made a lot of edits, for example to a Qobuz box set with poor metadata, is that I want to backup as soon as possible so that there is no risk of loosing the edits due to a crash or other unforeseen circumstance. This doesn’t happen often but it does happen so I have learnt the hard way.
So, today, just re-booting once or twice doesn’t seem to be enough. I didn’t time anything but I had to stop editing and just wait a while and try again until it worked. I interpret that as maybe some background process needing to complete before backing up was possible again?
Whatever the exact cause, I think it is perfectly natural to want to backup over the course of an editing session, maybe several times. I was certainly able to do that prior to build 1353 but now this vulnerability has been introduced that a system crash may wipe out a lot of edits that cannot be recovered from a backup because roon wasn’t allowing a backup during the course of an editing session.
I really have the impression over recent releases that roon is getting worse at scaling So many issues at their root seem to be the same cause of arbitrary limits on the number of server “objects”. Is that a consequence of this new cloud based architecture? So I notice the effects not just with backups. After a shortish while, I would say less than an hour or so, if I have been playing and editing at the same time (which I often do) roon becomes very unstable and unusable. Editing and searching and navigation features become so slow as to be unusable and playing music becomes impossible also with a lot of stop/go stuttering. This is fixed by a reboot for about an hour or so and then the same symptoms return.
Ben, just a thought. Is the queue a bunch of “objects” the server wants to keep track of? That is, will a long queue or multiple queues to different zones have an impact on performance?
@ben, I have spoken too soon. Since 24 hours I am unable to make a backup. The circumstances are the same. I have edited a number of files. When I attempt to make a backup I get the “uuh, uuh, something has gone wrong” message. Roon then locks up and becomes unresponsive and I have to shut down roon. What I do is I quit the server as well and restart roon. But I cannot backup.
I waited overnight to let a scheduled backup run to see if that would make a difference. Seems like a long shot but when I try to force a manual backup it fails.
Any movement on this case? Making a dependency like this between editing a library and being unable to backup (which is exactly what you want to do after an editing session) just doesn’t make any sense.
I wanted to update you here to let you know that we have been able to reproduce similar behavior on our end in the QA lab. We are still looking into this issue and will let you know if more information is needed, thanks!
