With this update I’m getting volume jumps when I start playback on my ls50wII. Before that Roon always used the volume set in the app before playback. One way to reproduce it is to play something with volume set to eg 50. Then switch the speakers to TV, lower the volume to eg 20. Then play something in Roon. It switches speakers back to the “Wi-Fi” mode, waits a bit and then suddenly changes volume to the first sessions level which in that case was 50 and blasts music instantly. This could cause a heart attack seriously. One of the main reason I kept Roon for was rock solid and predictable volume control.
of the 2 layouts… i guess one is an error. note that the 2 screens have the same 16:9 ratio, i don’t see any reason for different layouts. and in my opinion, that’s the first layout with 2 dark stripes is simply wrong.
the second is almost correct because the black square IS an error (as pointed out in some comments).
finally, about slowness. you tell me the reason, i tell you the experience: now if you scroll on any page like artists, albums … you have to wait. i think one of the points appreciated in the community was the great responsiveness… now it’s not the same. you say it is cached… maybe i have to increase the cache memory? (there was a setting for that somewhere). is it possible that restarting roon delates the cache?
anyway: can i live with a bit of slowness? yes, if there is the advantage of many more pictures thanks to the new system. we’ll see.
i’m just giving my feedback…
Try dragging your window much wider and much narrower and you will see that it is not an error. It is part of the design. There are gutters on the side of the page when you get too wide, and that’s why you are seeing small strips of black on the side of the 16:7 image. At the smaller size, the same 16:7 would consume too much vertical space , so the image has been made vertically shorter. Maintaining that 16:7 aspect ratio means that the image is also less wide, and the designers concluded with his design of the box on the side. There is a bug, that the box is almost always black. It should be gray and white as well, depending on the color of the left edge of the image.
i understand the logic.
at the same time, i think that on a large 16:9 screen (that’s when there are the 2 strips, and they are not small…) it would be better a smaller picture (not a problem on a big screen) and mantain a costant layout (ie the square on the left), with more text at the bottom. but i guess it’s a matter of opinions (i’d like to see the layout on a bigger screen, like a TV)
anyway, it’s clearly difficult to get good results with so many formats…
i appreciate that the banner picture has now a fixed ratio (something between the old 1.55, and the pre roon 1.8-880 very large stripe)
1 Like
ROCK just updated to build 884
Sharing a update on 884 that does still feel a little buggy. I run the core on a modern Win 10 PC - nothing fancy or complex. I had an update problem with 880 but that was solved with 882. Below are some remaining issues….
- Restarting / loading Roon seems to take long time relative to before the update.
- I am getting dropout/skips to some of the music zones. I had some of this before, but hoping the update might have addressed. It feels worse than before.
- On occasion, upon start up, it seems to do a full library scan. And sometimes, it says that it is loading some random number of albums (44 of a library of 8000) and but it takes hours to complete that task. Just a spinning circle. This happened in an old release, but i haven’t seen it for a long time.
- On occasion, i get a zone duplicated, e.g. Kitchen and Kitchen again… In these cases “Kitchen” is on a Chromecast plugged into a an Airplay device, but the Airplay device is NOT enabled.
- On occasion, i have a zone playing but no sound. The ipad or Core PC shows time elapsing for the music, but no sound. A restart fixes the issue… but who wants to be restarting when you are expected to be listening to music.
- On occasion, i am getting a warning sign that metadata updates are paused. This has happened 2-3 times since the update. It seems to eventually resolve itself. I haven’t had any network issues.
Otherwise, all seems to be good; i am a strong ROON supporter. Ummm, on Playlists…
I really like the playlists, but can you share more info on them: Are they permanent? I would hope the holiday ones would eventually be pulled back. If the “types” are permanent, are the songs in them updated? If so, generally how often? Will you be creating many more? What are your thoughts here?
Hoping for a 886 release that will smooth some of the above out.
I have also experienced these issues for some months and am hoping for a fix sooner than later.
Dear all,
Due to the fact, that the original thread was closed and discussions moved here by Roon Labs I want to let you know what an other user successfully experienced regarding the corrupted database issue within Build 880:
Unfortunately, I was not that optimistic and started with a new database two days ago.
So, I cannot verify that. But, please feel free to try and help others with your own experience.
I performed the update today to 884 (core/server on Ubuntu 20.04.2 LTS). Was kind of a nail-biter though as core was hung up on the downloading screen (I kicked off the update from one of my win10 controllers) for 20min+ ?
I was about to SSH to it and stop/start the service, but opened roon on my ios device which worked (since server is still in process of updating from 850), went to settings > about and the server status bar was showing the downloading graphic but was at a snails pace, like “1kb sec” speed. I just left it alone and eventually server finished etc…
Not sure if the time it took was due to this specific update or maybe the roon download server was just being hit hard, dunno.
I’m not sure if there is a bunch of background processes going on temporarily (optimizations, DB tasks) but I took a look at my server via HTOP and this mem usage doesn’t seem right (3GB sitting idle and 27GB virt) - no clients connected, no music playing just rebooted server after all was completed. Maybe its temporary for a couple days, but anyone seeing similar stats?
This is normal for the Microsoft .Net runtime. Virtual alloc is higher than it was with Mono. But actual resident memory stays pretty low, and doesn’t really move around once the server settles. That the runtime has a bunch of RAM in virtualalloc is pretty much moot, all that really matters is the resident memory usage, which hasn’t materially changed from when Roon was using Mono (at least on my CentOS 7-based system).
Thanks, good to know. I hadn’t checked my server resources since last update to .NET, so it was prob similar to this. I usually don’t log into the server much.
I recall .NET post updates (other platforms) need to recompile libraries and settles down after awhile.
It’s been a weird few days since the first piece of equipment updated until finally today. I have multiple set-ups running across both windows and IOS based interfaces and topped off with an Innuos server running as my core.
Things were working but poorly, sound signatures were “off” in all 3 of my “big” (ie. more expensive) systems. My core server was running poorly and my library was missing all my ripped cd’s for some reason.
Today i powered down every single tablet, laptop, phone, the server, the multiple endpoints, each and every DAC was unplugged and every usb, spdif, bnc and aes cable was unplugged and re-inserted during each separate power up sequence.
Finally, everything sounds good again and i even managed to get the Innuos experimental squeezlight player back online and sounding better than ever.
My library is all messed up, not sure what happened there, but small loss to gain access again to the squeezebox feature on the Innuos, that sounds best out of every other software that i’ve tried on my high end stuff. Good job, very appreciative of the work, glitches and all. Eventually it all seems to come back together. (Keeping fingers crossed to not jinx myself)
Thank you.
1 Like
Sorry to add to the pile on, but I thought I would share this here in case it is helpful. I had an issue with Roon incorrectly labeling Roon Ready devices as “uncertifed.” Doesn’t seem like it would have anything to do with Build 880 database corruption, but for whatever reason, restoring a backup from just before the 880 launch fixed the problem. 
1 Like
Hi Jim,
Reading other end user reports here in the community, I don’t think, that this will be a general procedure. Tor these people, who have the database issue, the crucial question is : When did the database become inconsistent? And that could have been any time before, because it seems to be not depending on the updates but more on typical end user accidents (system reset, hardware crash, power failure) which everyone has at some point.
Best regards
1 Like
Those without database issues have a question too: when this, or something alike, it will happen to them? (just a masochistic/rhetoric thought inspired by a very unstable roon…)
Hi occasionallyhere,
it was a critical issue, indeed. There have been some or maybe a lot of people loosing data.
But I learnt, that such a thing should not occur in future.
Starting with Build 880 Roon backups only consistent databases.
So, hopefully, in future everybody should have the opportunity to restore his backups.
And to be fair: It has been my first really critical issue with Roon.
Before, Roon has been running without any problems.
The causes that have been suggested by Roon include power outages and hard drive failures (though I suspect there may be others). A UPS for your core covers the first, and most modern drives allow SMART monitoring, so that helps to prevent the second. I suspect that even having both isn’t a 100% way to prevent database corruption, but I guess they’ll both help.
1 Like
Indeed, I had a database issue (not identified as a corruption by support) and had to start afresh with a new one to cure the issue. Never did find out what caused it but it was my original Roon database and was over 4 years old. The ROCK NUC had always been on a UPS.
1 Like
And to be fair, that (power interruption issues) shouldn’t be an acceptable ‘excuse’ for corrupt db anyway. The software should be more robust than to be susceptible to that sort of thing at this point in its dev, and at this point in general. This is 2022 after all.
2 Likes
Roon pointed the/that finger at the users’ setups since the beginning. The exceptions are the ones that make the difference between good software and bad software. Everybody knows IF/THEN, TRY/CATCH/FINALLY… not so many.
Since the first iteration of 1.8, roon just looks more and more like an untrustworthy software with each release.
1 Like