Roon on ROCK crashes due to Linn devices with "CreateHandle: Assertion" error [Fixed in Roon build 1148]

Hello @noris ,

thx for coming back to my issue.

The LINN KSH/3 is normally my one and only playback device; as the error occurs nearly only when I press the “play” button I wonder how I cn check what you have asked for if there is no playback device connected … I have somewhere in the cellar an older low end LINN system (Kiko) … if needed I am willing to reactivate it and disconnect the KSH/3 and try it with the Kiko, but this would be also a LINN device … or can I use the iPAD itself to play music to it?

Cheers
Frank

Hi @fschmeis ,

As far as we can tell, this behavior affects multiple Linn devices, so trading out one Linn device for another may still cause the issue to occur, unfortunately.

The good news is that our devs are aware of this issue and the development ticket is in progress, with our change to more frequent Roon releases we are hoping to address this behavior sooner, rather than later.

If you don’t have any choice but to use the Linn devices, it’s likely best that we wait for the ticket to be addressed and circle back once the fix is out.

We know this issue has impacted you for quite a while, across multiple types of operating systems, but we believe we’ve finally isolated the common variable, your continued patience is very appreciated.

Hello @noris

After many years of crahes with Roon (on QNAP and with ROCK) I am starting to hope, that this story will have a happy end! :smiley:

If I can do anything to achieve this (e.g. testing of a beta release) please don’t hesitate to contact me.

Cheers
Frank

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Fortsetzung der Diskussion von Roon on NUC10i7 with Rock (227) crashes immediately when playing any track:

Roon Core Machine

NUC10i7 with 32 GByte RAM and 1 TByte SSD
running Rock and Roon build 970

Networking Gear & Setup Details

Switch: Netgear JGS524PE GBit Ethernet
Router: AVM Fritz!Box 6591 Cable
WIFI only for the iPAD

Connected Audio Devices

LINN NG Klimax System Hub

Number of Tracks in Library

appr. 350.000

Description of Issue

  • when using the streamer with the LINN App Kazoo the Roon Core don’t start anymore (looking at the web-site of Rock: it doesn’t start, crashes after some minutes during start up of the library)
  • when I don’t use the streamer in parallel at least the Roon core starts; I can also start the Roon App on my iPAD; once I try to start a track - immediate crash of Roon :sob: :sob: :sob: I have tried this for several hours many times, restarted the streamer before starting Roon core, restartet the NAS (where the library is stored) …

=> I cannot use Roon anymore :disappointed_relieved:

  • and if you look at the linked thread, this issue lasts now since beginning of 2022
  • and if you look at Roon stopping randomly, I am struggling with Roon FOR FIVE YEARS NOW

WHEN WILL THIS END???

I’m just a fellow Roon+Linn owner, but I thought the following might be useful: Linn does not recommend managed switches, neither does Roon. Your JGS524PE is a managed switch. From experience, I’d suggest you try a cheap unmanaged switch in its place for a test.

interesting idea that the switch might be the offending reason; didn’t think about the switch so far; I run the switch “as is” (no VLAN, QoS … ), only one time in the pasttime I had to chang the configuration: there was a parameter that made the detection of my LINN devices by Kinsky and Kazoo very cumbersome (don’t remember the details, but had something to do with repeated broadcasts which were optimized by the switch)

nevertheless: the issues I have for years seems to be linked to the combination of Roon and LINN, refer to: Roon on ROCK crashes due to Linn devices with "CreateHandle: Assertion" error [Ticket In] - #48 by noris

In the past I’ve had some issues between Roon and Linn, although not crashes, but currently the interactions between my Roon cores and multiple Linn systems on two locations are as good as they’ve ever been, and in part that has been through simplifying the network connection between the cores and the Linn systems, to avoid problems like you described where switches and other network components do too-clever-by-half things with multicast and UDP.

I agree that a simple network might avoid connection problems between LINN and Roon.
To my opinion my actual problem and the problems between LINN an Roon for the last years are not related to the network, as

  • the Roon server crashed as soon as I try to start a track, or
  • the Roon server crashes without any user interaction, e.g. it crashed last night:
    grafik
    it is Sunday, 11 am, therefore the crash resp. restart of Roon core occured at 4:30 am - I for sure was sleeping at that point in time …

Did you try to replace the switch by un unmanaged one? In my experience, doing what the Linn recommends has been a better use of time than trying to guess where a problem is.

I did not (yet); if Roon recommends that, I will do that, for sure

In the pastime Roon asked me

  • to port the core to a different machine (moving it temporarily from QNAP to Windows) with reduced library size . didn’t fix the issue,
  • later run extensive tests on the QNAP - both HDs as well as momory - didn’t fix the issue,
  • then moved the core away from the QNAP to a NUC / Rock - didn’t …

I’ve discussed network switches at length with my Linn dealer, independently of Roon. He’s very particular about which switches he recommends for Linn setups, along similar lines to Linn’s recommendations but even more strict. He’s a former DSP/networking engineer who moved into to high-end audio installation, he knows his stuff. My take: Linn’s use of IP multicast and UDP tickles obscure bugs in switches and servers.

1 Like

mhm, you really got me thinking about that topic … my Fritz!Box has a small built in switch and with my small patch field at home it be done within 15 min to patch the streaner and the NAS directly into the router … I will give it a try …

Hi @fschmeis ,

I’ve merged your post into the existing thread so that we can have all the information in one place.

I’ve recently spoken to the team about this issue, and I wanted to touch base with some good news, which is that development work regarding this issue is in progress.

It looks like there have been code changes made to a developer build of Roon, and now these code changes need to pass QA testing, and then they will be published to the public Roon release.

We are getting close to addressing this issue, I know you have been patient during this time and we greatly appreciate it, we are almost there. Thank you!

2 Likes

Hello @noris , this sounds like good news … I really hope, that this jouney will have soon a good end …

1 Like

Hello @noris,

Roon 2.0 was released and I was 3 months patient, just had another crash - what is the status of this issue?

Cheers
Frank

Hi @fschmeis ,

Thanks for the ping here, I can certainly update you on the status. The fix I mentioned in my earlier post did not pass QA testing, simply put, it caused more problems than it solved, so we had to go back to the drawing board and dedicate more resources to this issue.

Since the fix did not pass initial QA testing, a deeper investigation was required, and this meant mailing a Linn device to our dev team so that they can test any changes made hands-on. I can confirm that a Linn device is now with one of our senior devs, and that we are working on this issue.

Once the fix has been reworked and thoroughly tested, we release it. I know you’ve been impacted by this issue for a long time, and we want to make sure we fix this issue thoroughly, not introduce more problems. Thank you for your patience.

Hello @noris ,

thank you very much for the fast reply; sometimes it works for some hours, sometimes even changing the level of the sound causes ROON to crash … this is really a nightmare … hopefully the sen dev can fix it soon …

Cheers
Frank

1 Like

Hello @noris ,

any news on this subject?

Cheers
Frank