this is right, but unfourtunately this was due to not hearing music … nevertheless e.g. on 2nd of March, I could hear for appr. 2 hours (in words: two ) music before the next crash appreared at 10:42 pm CET, it was again in the middle of a track without any interaction with Roon, it was the album “Dance” from Tingvall Trio.
both the QNAP where the library is stored as well as the NUC where ROCK is installed are directly conntected via ethernet to the same switch, a Netgear ProSAFE JGS524PE; there is no repeater involved and no WIFI; I would be surprised if the reason is somewhere in the network …
please keep in mind that we are talking about appr. 440.000 tracks … something like 12 TByte of data volume …
Do you think this issue is caused by:
this particular QNAP (my primary NAS, a TVS 671 with i5 and 16 GByte RAM), or
storing the library on a NAS in principle?
The background of my question is:
I have a backup NAS QNAP TS-251D (low spec compared with the TVS 671, no RAID, with nightly incremental updates) which I could mount alternativly to the NUC, and
I have also a WD DUO Book which I could hook to the NUC via USB (both hold also the entire libary)
Please check this with the team as this will need some work and will take again 2 weeks of analysis of the library …
I wanted to check in with you here, we haven’t forgotten about your case. In fact, I have discussed your case several times with the team including today, and have opened up an investigation into some potentially-related cases. We will keep you updated when the investigation is complete or when there is new info to share, it looks like your case could be related.
okay: stopped Roon core, mapped the drive, deleted the “orbit” sub directory, restarted Roon core, waited appr. 5 minutes until the core was up, opened Roon on iPad, started a track of album “Giulia” from “Triosence” - immediate crash , Wednesday evening, 10:13 pm CET
Waited 19 minutes until the core has restarted, started Roon Control on my Windows 10 Notebook, did nothing - 5 sec after launch CRASH
Sorry to hear that removing the Orbit folder did not help. I have scheduled additional time for the team to look over your case for next week, I will let you know once I’ve discussed the new findings and Orbit not helping with them.
ok, thx, looking forward to get this fixed sometimes …
the day before yesterday - for some reason - we could enjoy music with ROON for more than 2 hours (and NO crash); there is one observation / feeling: once the core crashed caused by one end point, it crashes always when using the same end point after reboot; but there is a chance that it works when using a different end point … at least for some time …
just had a look at the web admin page of ROCK / my NUC, NO music playing, DIDN’T touch any endpoint for the last 24 hours, and saw:
looks like the core also crashes “just on its own” … very puzzling …
additional 17 days without any progress … today installed 931 … behaves even worse than before: without doing anything (no song playing, no interaction with Roon - just takling on my phone) the core crashed, 11th of April, 9 pm CET …
I spent years with the QNAP and Roon was never stable, then moved end of last year to a NUC and Roon was never stable … I have no idea what I can do / shoud do to move forward … I am really really disappointed …
Sorry to hear that you are still having issues here. I’ve discussed your case with several teams, and now I am waiting for further input from our dev team as to what could be causing these Handle Assertion issues. We don’t see a pattern yet, so your case is being escalated up the chain to the senior devs.
Thanks for your patience here as we’ve been discussing your case internally. The team is wondering if this issue could be database-related, can we please ask that you stop RoonServer from running on your ROCK Web UI and then upload your entire RoonServer folder to our Zoho Workdrive here?
thx for coming back to my issue, I really really hope that the team can find the reason.
I succeeded in zipping the RoonServer-directory.
I failed to upload the RoonServer.zip file. It has a size of appr. 14 GByte, maybe that is the reason. I tried it several times, with firefox and chrome, even after a fresh restart of my win10 laptop (with 16 GB of main memory) and only chrome running - alsways at 80 - 85% the upload crashes:
My Dropbox is limited to 7.5 GByte.
Does Roon provide any other possibility to transfer such a large file with 14 GByte?
So what I have done (upload has successfully finished): I did split the file into 14 smaller pieces with 7z, you should be able to join the files together again with 7z … could you join the files?
Thanks for sending that database over, it is not an issue if split into pieces, we can join them back together. I’ve sent your database to the team reviewing your case, once I have more info I will share with you, thank you.
Hope you have been well since we last spoke. I wanted to let you know that we’ve been discussing your case internally and I’ve had multiple meetings with our developers regarding your diagnostics and we believe we’ve finally found a pattern to the issue.
Looking over the logs, the errors appear when there is an issue when the Roon Core communicates with your Linn device. We are investigating this further to see what we can change in this area, but we were wondering, can you please confirm if you remove your Linn device from the network and leave it unplugged for the time being, do you still see the issue occur on the Core?
Hopefully, our theory here is right and we can address this issue via a code change in the future, but please do let us know your experience with the Linn device disconnected and if removing it from the equation allows the Roon Core to work as expected, thank you.