it’s on the macbook as well. Not as much as on the pi, bust still. (wifi, i don’t have a Lan-Adapter for the macbook)
So there has to be a problem with the place or the amplifier? The amplifier would be really weird… as it plays just nice via airplay.
Unless things have changed–I used Unraid some years ago–the OS is installed on a USB flash device with storage on spinning disks (incl. a parity drive.) What’s more, your ASRock appears to be running an Intel Atom C2550 (Avoton) and this simply doesn’t have enough resources to run Roon core.
You may be able to improve matters by adding an SSD and using this as a cache pool. However, I think you would get better performance using a regular OS such as Ubuntu installed on an SSD with the spinning disks for storage only.
Until recently I used an HP N40L for Roon with less than 50% the performance of your machine and it worked flawlessly without DSP (albeit browse was a little sluggish.) So you should expect improvements on your current situation.
Thanks for your reply,
a HP N40L is my backup-System which worked flawlessly for a few years as my NAS.
If you read the thread, a SSD was added recently and of course as a Cache on which the roon core is running.
There is no need for more performance, i proved that a few times. The server can handle 3 threads with DSP running at approximatly 20% CPU. The recently added SSD pushed the performance of the webinterface slightly, but didn’t do anything to the Problem described. UNRAID is bootet from an USB-Stick, that’s correct, but after booting, it barely uses it.
No Problems with errors here. On large amounts of copied data the performance drops a little, which is now gone with the cache drive, but there were never any issues with unraid or the hardware. it works better than ever expected and the apps and dockers are just wonderful.
I switched to unraid after testing a few other products, even some with zfs. But in the end, raid even on zfs is no backup, so i bought completely new hardware, moved from the HP and now use the hp as backup, so i don’t have to be afraid to lose something anymore.
Hi @Kai_Schmalenbach ---- Thank you for giving the proposed test(s) a shot and sharing your observations with us.
Moving forward, I would like to enable diagnostics on your account so our techs can have a closer look into this behavior. However, before I enable this feature may I very kindly ask you for the following:
Please reproduce the issue and note the time when error occurs.
Please verify the track(s) that were being played at the time of the error.
Hi @Kai_Schmalenbach ----- Now that I have the requested time frames (thank you again) I have enabled the mentioned diagnostics on your account.
What this action will do is the next time that Roon is active on your core machine a diagnostics report containing a set of your Roon logs will automatically be generated/uploaded to our servers. I will keep an eye out for the upload and will touch base again once it has come in so you know we have it.
since your last post, i have started the software, restarted the server, an update came in and i used it.
you said you would report on receiving the logs. Didn’t that happen?
What do i have to do?
HI @Kai_Schmalenbach ---- Thank you for touching base with me and my apologies for the slow response here. Been a busy couple of days with the release of 1.5 .
The diagnostics report has been received and is attached to your ticket for review by a member of our tech team. Once your ticket has been updated, I will be sure to share the team’s thoughts/findings with you in a timely manor.
A minor suggestion (if you haven’t already done so): move your DigiOne to a cooler place. I had mine sitting atop my new Dac, and before long, I had similar performance issues as yours. Turns out that the DAC heat was cooking my Digione. Moved it aside, and the problems ceased.
Dunno, just spitballing. Good luck to you. I know how frustrating troubleshooting such issues can be.
Hi @Kai_Schmalenbach ----- Thank you again for your continued patience here, it has been very appreciate both by myself and our technicians who have been evaluating the diagnostics we received from your system.
Based on the team’s analysis they are not seeing anything conclusive in the logs that are pointing to the cause of this behavior. However, the team feels strongly that this issue is more than likely related to something occurring in your environment and as such, our next move here should be to try and shrink down your network configuration down to the bare minimum and see if the issue presents itself again.
I find that when addressing a potential network issue the best course of action is to remove as much complexity as possible from the “chain of communication” and slowly add the links back in to verify where things fail, and where they succeed.
This is a process I have used myself whenever I am trying to diagnose a potential networking issue with my own audio setup at home. My “base configuration” always looks the same:
I bring any additional networking hardware offline temporarily (APs, switches, etc).
I mount my core directly to my router.
I use a single remote OR endpoint (depending on the issue - in THIS case it would be the endpoint)
I then try to reproduce the behavior.
… It goes away, I begin to expand back out.
… It doesn’t go away I now know that the issue is occurring elsewhere.
With the above in mind I would like to have you please verify how the Allo endpoint responds your with a very basic network setup in place, using the example provided above.
Additionally, the team has also asked if there is anything else mounted to the Allo besides your DAC and obviously it’s LAN connection.