Crashing while playing music

Support
1

Core Machine (Operating system/System info/Roon build number)
iMac

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Everything is wired.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Streaming from Qobuz to an AirPlay device, iMac and AirPlay device are both wired to a gigabit network switch.

Description Of Issue
This happens very often for me, Roon Core just crashes in the middle of playing music with this same stack trace. Why is trying to write to a file named “[Unknown]” and how do I prevent it from happening?

Note to devs: you GOTTA check the file handle when you open a file rather than assume it always works and you gotta catch exceptions and provide feedback to the user. Sloppy code!

05/25 15:36:25 Info: 
Local Time:            05/25/2020 15:36:25 -07:00
Device Serial Number:  A2619BFD-4C1C-49F1-B3C1-87C986947FE2
User Id:               97f0994d-33d8-45e8-b9b4-b04a7b818688
Roon Version:       1.7 (build 537) stable
OS Version:            Mac OS X 10.15.4
Hardware Version:      iMac19,1
Mono Version:          6.4.0.208 (2019-06/07c23f2ca43)

Application Domain:    Roon.exe
Assembly Codebase:     file:///Applications/Roon.app/Contents/MonoBundle/Roon.exe
Assembly Full Name:    Roon, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

CPU0 Description:      Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz (64-bit)
CPU0 Num Cores:        Physical: 6 Logical: 6

SCREEN0 Name:          69943472 (primary)SCREEN0 Bounds:        0,0 2560x1440

   Exception Source:      mscorlib
   Exception Type:        System.IO.IOException
   Exception Target Site: FileStream.WriteInternal
   Exception Message:     Invalid handle to path "/Applications/Roon.app/Contents/Resources/[Unknown]"
   Exception Data:        none

   --[ Stack Trace ]------------
   System.IO.FileStream.WriteInternal(Byte[] src, Int32 offset, Int32 count)
       mscorlib.dll, IL 119, N 618
   System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
       mscorlib.dll, IL 144, N 274
   System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
       mscorlib.dll, IL 128, N 286
   System.IO.StreamWriter.WriteSpan(ReadOnlySpan`1 buffer, Boolean appendNewLine)
       mscorlib.dll, IL 363, N 882
   System.IO.StreamWriter.WriteLine(String value)
       mscorlib.dll, IL 13, N 242
   System.IO.TextWriter.WriteLine(Object value)
       mscorlib.dll, IL 47, N 282
   System.IO.TextWriter/SyncTextWriter.WriteLine(Object value)
       mscorlib.dll, IL 0, N 71
   UNKNOWN
       , IL 10, N 162
   System.Console.WriteLine(Object value)
       mscorlib.dll, IL 0, N 71
   Sooloos.RnetJsonClient/<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar)
       RoonBase.dll, IL 132, N 842
   System.Net.Sockets.SocketAsyncResult/<>c.<Complete>b__27_0(Object state)
       System.dll, IL 11, N 133
   System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
       mscorlib.dll, IL 8, N 78
   System.Threading.ThreadPoolWorkQueue.Dispatch()
       mscorlib.dll, IL 116, N 921
   System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
       mscorlib.dll, IL 0, N 122
2

It happened again:

05/25 16:49:38 Error:
Local Time: 05/25/2020 16:49:38 -07:00
Device Serial Number: A2619BFD-4C1C-49F1-B3C1-87C986947FE2
User Id: 97f0994d-33d8-45e8-b9b4-b04a7b818688
Roon Version: 1.7 (build 537) stable
OS Version: Mac OS X 10.15.4
Hardware Version: iMac19,1
Mono Version: 6.4.0.208 (2019-06/07c23f2ca43)

Application Domain: Roon.exe
Assembly Codebase: file:///Applications/Roon.app/Contents/MonoBundle/Roon.exe
Assembly Full Name: Roon, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

CPU0 Description: Intel® Core™ i5-9600K CPU @ 3.70GHz (64-bit)
CPU0 Num Cores: Physical: 6 Logical: 6

SCREEN0 Name: 69943472 (primary)SCREEN0 Bounds: 0,0 2560x1440

Exception Source: mscorlib
Exception Type: System.IO.IOException
Exception Target Site: FileStream.WriteInternal
Exception Message: Invalid handle to path “/Applications/Roon.app/Contents/Resources/[Unknown]”
Exception Data: none

–[ Stack Trace ]------------
System.IO.FileStream.WriteInternal(Byte[] src, Int32 offset, Int32 count)
mscorlib.dll, IL 119, N 618
System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
mscorlib.dll, IL 144, N 274
System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
mscorlib.dll, IL 128, N 286
System.IO.StreamWriter.WriteSpan(ReadOnlySpan`1 buffer, Boolean appendNewLine)
mscorlib.dll, IL 363, N 882
System.IO.StreamWriter.WriteLine(String value)
mscorlib.dll, IL 13, N 242
System.IO.TextWriter.WriteLine(Object value)
mscorlib.dll, IL 47, N 282
System.IO.TextWriter/SyncTextWriter.WriteLine(Object value)
mscorlib.dll, IL 0, N 71
UNKNOWN
, IL 10, N 162
System.Console.WriteLine(Object value)
mscorlib.dll, IL 0, N 71
Sooloos.RnetJsonClient/<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar)
RoonBase.dll, IL 132, N 842
System.Net.Sockets.SocketAsyncResult/<>c.b__27_0(Object state)
System.dll, IL 11, N 133
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
mscorlib.dll, IL 8, N 78
System.Threading.ThreadPoolWorkQueue.Dispatch()
mscorlib.dll, IL 116, N 921
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
mscorlib.dll, IL 0, N 122

4

Hi @Troy_Hakala,

Would you kindly use the directions found here and send us over a set of logs using a shared Dropbox link?

Thanks!

5

Here you go: https://www.dropbox.com/s/dpfmx2pmj3m7ayt/Troy_Hakala.zip?dl=0

FYI, it just crashed again, same stack trace.

6

It’s now crashed 4 more times since my last post 2 hours ago. This is exactly what I was experiencing days ago, when I decided to just start over with a new configuration and here I am again with the same crashing bug.

8

Hi @Troy_Hakala,

I brought your report to out meeting with the development team today. The error in the logs is happening in a place that is pretty uncommon and we haven’t seen any similar crashes. The place where it is crashing is generally pretty “safe” and the team believes that there is likely something specific to your environment that is causing Roon to crash.

Can you give some more details about your setup? If you disable any firewall or antivirus is there any change?

If you install Roon on a different user profile does the same issue occur?

9

Antivirus and firewall software has nothing to do with it, it’s so embarrassing to all software developers that Roon always points the finger like that. You gotta stop that nonsense. And I don’t have a firewall or antivirus software on my Mac (why would I?).

My setup is using Qobuz and a bunch of Chromecast and AirPlay endpoints. It crashed when I used Tidal too so I doubt the service has anything to do with it. It must be an endpoint because those are the only 2 things I configured.

The problem is that it is trying to open a file, it fails and you try to write to it anyway and then you don’t catch the exception. That’s 3 bugs right there, that’s hardly “safe code”. Those bugs should be easy to fix. And the dev who wrote it should be laughed out of Roon, it’s egregious coding practice. It’s the equivalent of a plumber not connecting the drain and claiming that any leaks are the fault of the sink operator.

But the real question is: Why is it trying to write a file called “[Unknown]” in the Resources directory? I don’t know .NET but is “[Unknown]” what .NET uses as a string for a null value? What could be in my setup that would cause that? Why does it even need such a file, what is it used for? Is it used for an icon for one of my endpoints? Which one? Does the name of an endpoint matter or can it cause a bad filepath to be created?

This is really easy for me to reproduce. Can you suggest that I try things to reproduce it and narrow it down? If not, can you show me the source code in question, I bet I could figure it out for you.

2 Likes
10

@danny, are you reading this thread?

There’s a real point being made here.

1 Like
11

He’s reported a bug – we are addressing it, but first, we must reproduce it. @Troy_Hakala thinks he knows what he’s talking about, but I disagree. He has just enough information to be dangerous, but he’s not reading the stacktrace properly, and instead trying to blame us for making trivial errors. The holier-than-thou attitude doesn’t help either.

My analysis:

The stacktrace is showing that something is writing to the console (System.Console.WriteLine) and then the stack is screwed up with the UNKNOWN entry – then the .NET framework seems to end up somewhere strange in something writing to the install location.

The offending code looks like the below.

                              } catch (SocketException e) {
                                  Console.WriteLine(e);
                                  OnDisconnected(e);
                              }

While this does trace, the problem is handled properly. Unfortunately, something is screwy causing the WriteLine to blow up. The bad stack entry points to memory corruption. The situation is occurring due to a network connection being lost in a non-clean (no FIN during TCP shutdown handshake) way. Even if there was no crash, the music would stop due to the lost network connection. I agree it shouldn’t crash, but the situation is no so clean cut.

You keep making condescending posts about our developers and code quality – it’s a pretty crap way for you to conduct yourself, especially when you clearly lack the knowledge to make informed comments. I suggest you focus on reporting the issue and less on the personal attacks.

1 Like
12

Thanks for getting involved.

My point.

Agree with that.

I await the resolution with great anticipation. :slightly_smiling_face:

2 Likes
13

Roon and their developers are throwing their hands in the air and pointing the fingers at everyone else like antivirus software, firewalls and network topologies. You find me condescending, you’re right. I feel it’s condescending to blame everyone else and to assume your code is perfect, so yes, I’m condescending to the people who are being condescending. I’ll stop the condescension if you will. A mark of a good dev is one who wants to find the problem and fix it, even (or especially) if it’s their code. I’ll give you the benefit of the doubt and assume that you want to figure this out…

Now you’re suggesting that .NET is causing memory to be “corrupted”. That’s more than likely Roon’s fault, right? Do you believe that .NET itself is corrupting memory and no one has ever discovered that bug in .NET and it has nothing to do Roon’s use of .NET?

So you’re saying that something bad happened in the way I configured Roon and it’s causing an exception to be thrown and caught and the debug-print line (Console.WriteLine) is throwing another exception that isn’t caught? The user shouldn’t be able to configure the software to make the software crash. There’s a Roon bug there and it should be traced down and prevented so other users don’t cause the same problem. Can we figure out what it is about my configuration that is causing this?

On my latest crash, right before the stack trace, I see these 2 lines that happen in the same second as the stack trace (the line before is 2 seconds earlier):

05/28 09:49:41 Error: [cast/client] [BeoSound-Core-2bb07c9129435d31a2fa0440dcad9f8a._googlecast._tcp.local] Unable to authenticate TLS connection
05/28 09:49:41 Trace: [rnet/RnetJsonClient] no data received for >10000ms. Killing connection.

The first line is innocuous since my logs are littered with that same line and it doesn’t seem to affect anything. (But I’m curious why it happens so often). Is the “Killing connection” the cause? What is RnetJsonClient talking to when it’s waiting for data and gives up? Qobuz or Tidal? Or the endpoint? Is it giving up and killing the connection the cause of the initial exception?

That line says that it was waiting 10 seconds before giving up. If I go back in the log more than 10 seconds earlier, I see this:

05/28 09:49:28 Info: [stats] 8488mb Virtual, 3024mb Physical, 1107mb Managed, 138 Threads, FDs
05/28 09:49:29 Error: [cast/client] [Google-Nest-Hub-Max-94bfda781f6b3472a8e53e1898fdf9e1._googlecast._tcp.local] Exception writing message to stream:
05/28 09:49:29 Error: [cast/client] [BeoSound-Core-2bb07c9129435d31a2fa0440dcad9f8a._googlecast._tcp.local] Unable to authenticate TLS connection
05/28 09:49:32 Trace: [library] endmutation in 34ms
05/28 09:49:33 Info: [transport] destroyed zone Front Yard was playing? False
05/28 09:49:33 Trace: [zone Front Yard] Suspend
05/28 09:49:33 Info: [transport] destroyed zone Troy’s Office was playing? False
05/28 09:49:33 Trace: [zone Troy’s Office] Suspend
05/28 09:49:33 Trace: [transport/zonedisplay] [Chromecast-b132b424a7ccbeb5e7f5ff1e0339b781._googlecast._tcp.local] un-associated endpoint
05/28 09:49:33 Info: [transport] destroyed zone Beoplay A9 was playing? False
05/28 09:49:33 Trace: [zone Beoplay A9] Suspend
05/28 09:49:33 Info: [transport] destroyed zone Gym TV was playing? False
05/28 09:49:33 Trace: [zone Gym TV] Suspend
05/28 09:49:33 Trace: [transport/zonedisplay] [Chromecast-35d128ee948197a5a8be221ba34b8fcc._googlecast._tcp.local] un-associated endpoint
05/28 09:49:33 Info: [transport] destroyed zone Backyard was playing? False
05/28 09:49:33 Trace: [zone Backyard] Suspend
05/28 09:49:34 Trace: [library] endmutation in 33ms
05/28 09:49:37 Info: [transport/zonedisplay] Zone display unregistered: Google Nest Hub Max
05/28 09:49:37 Trace: [library] endmutation in 34ms
05/28 09:49:37 Warn: [ui/slowness] widget selectionbar_channelbrowser_mystations(200) > hpanel(202) > hpanel(208) > hpanel(209) > hpanel(210) > label(213) took 431ms to _PreUpdate
05/28 09:49:38 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
05/28 09:49:38 Trace: [push] retrying connection in 5410ms
05/28 09:49:39 Trace: [library] endmutation in 30ms
05/28 09:49:39 Trace: [library] endmutation in 30ms
05/28 09:49:41 Error: [cast/client] [BeoSound-Core-2bb07c9129435d31a2fa0440dcad9f8a._googlecast._tcp.local] Unable to authenticate TLS connection
05/28 09:49:41 Trace: [rnet/RnetJsonClient] no data received for >10000ms. Killing connection.

Note the 2nd line where it says it couldn’t write a message to a stream, apparently in relation to a Google Nest Hub Max. That is configured as a display device but it seems odd that it’s involved at all because I wasn’t playing music in that room when this happened. In fact, I wasn’t playing music at all anywhere for this latest crash, the server just crashed yesterday morning on its own and has been down since. So this is more evidence to me that this has nothing to do with playing music and how my network is set up.

There’s some other interesting lines in there, like the ui/slowness and an interrupted connection. What is Roon doing when it’s not playing music? Is the Roon app on the iMac talking to the Roon server and is it causing the server to crash?

1 Like
14

No one is throwing their hands in the air. We are gathering information.

No, its most likely triggered by a bug with how the Beosound’s SSL implementation is interacting with our SSL stack. We have enough information to try to reproduce this now – so we will.

Then expect to be treated accordingly. Life’s too short to deal with your type.

15

You should read your own forums and see what Roon people are saying. I’ve been trying to get Roon to work for several weeks and trying to figure out issues by reading the forums. Far and away, the most common response is to blame the network and end it there. Recently, apparently because one user had a firewall on their computer, a common point of blame is firewalls. Your own FAQ says firewalls are unlikely to be the problem but is something to look at, but support people tend to end it there.

No, its most likely triggered by a bug with how the Beosound’s SSL implementation is interacting with our SSL stack. We have enough information to try to reproduce this now – so we will.

It does this even if it’s not playing music to that device? Why does it happen on Chromecast and AirPlay devices too?

Life’s too short to deal with your type.

Hmmmm… sounds like a quitting attitude. You’re the one who signed up to develop a product that is to be used by lots of people and you’re paid to make it great. If you want Roon to succeed you’d better develop a thicker skin. I’m not the first and won’t be the last to suggest that Roon is imperfect. As I said in another post, people who succeed welcome criticism and people who fail fear criticism.

Life’s also too short to deal with buggy software. I suspect that’s why Roon’s software is much less popular than you would like it to be — my guess is that most people who try it have issues that can’t be resolved and give up. What percentage of people try Roon and pay vs those who try Roon and quit? Come on, even your fans admit that the software is buggy, quirky and slow. The good news is that there’s plenty of room for improvement!

I don’t like to quit and I’d like to believe that Roon can work and being a developer I find things like this fun to figure out (even if I can’t see the code). Most people are not as willing to struggle. So you can be angry at me or you can be grateful that someone who doesn’t quit is willing to help you improve your product.

1 Like
16

Roon is not buggy, quirky, and slow for me streaming Tidal and Qobuz. I’m not sure why except my system is relatively simple and I have a very good ISP. I have ethernet to Nucleus, HDMI and ethernet to Oppo 203. Also have an ethernet connected RPi4 running RoPieeeXL, USB to Meridian Prime, and a WIFI connected, battery powered RPi4, USB to Dragonfly Cobalt.

I have had zero issues since I got the Nucleus in late November and ethernet to everything. So, Roon does work flawlessly for some. If I knew the difference, I would certainly say what it is.

Early on, I had firewall problems and also problems running Roon core on Dell XPS 15 and trying to use WIFI. Now, I only use WIFI for control devices and my second, portable RPi4 with the Dragonfly.

17

[snark]This may be first time ive been accused of not reading our forums.[/snark]

Most of the issues we encounter are network related. It’s a good bet it is network. No one is ending anything.

1? It’s probably more like 1 per day, or even more. Same for antivirus that inject code into processes. Less common on MacOS, but it does happen!

Yes. Discovery is always happening. Those devices appear automatically because they are looked for and talked to in the background. Looking a bit further into this, my current guess is that you are running out of UNIX file handles. Unsure why since we have a lot of users with more devices than you. This is triggered by your environment, but unsure what exactly it is yet. The SSL failure points in the same direction. Also, it’s unclear if the log message about the filename is correct. Resource exhaustion issues often result in bad information.

I’m not quitting the issue at hand, I’m just not dealing with your attitude. We have forum guidelines, which expect everyone to talk to each other with respect. I know it’s a pretty foreign concept on the internet, but we try to maintain civility anyway. If you wouldn’t say it to my face, don’t say it.

I think the thing that makes you most irksome is that you seem to have a set of ideas about how things work, and they are completely wrong. Let’s nail some now:

  • you seem to take a very offensive position when all we are doing is asking questions
  • you aren’t in even in the right ballpark when it comes to debugging this stuff, nor are your intuitions right about how things work. A part of this is a lack of access to the code, but a lot is just because you are unfamiliar with what Roon does.
  • we have pretty thick skin and take criticism well. We do require the criticism be constructive. The thing that’s irking me about you is your tone, which is focused on personal attacks (against our community guidelines).
  • you seem to believe that you are being ignored and you are making noise about it. your issue has been looked at multiple times in the last week but we have no answers yet.
  • you keep making insinuations that we are a failing company with a product that is grossly unpopular. Conversely, we are a healthy, profitable, growing company, with no outsider investments and have created a product that wins accolades (3x product of the decade by top members of the press in this niche) and have dominated in the space we set out to play in. Can we improve? Yes! Does Roon have bugs? Yes! Could things be improved? Absolutely! Are we failing because we failed to catch an edge case felt by a very small number of our trialers/subscribers? No! The community is a tiny percentage of our user base, but they are the most vocal (obviously) and this is also were we do almost all of our support. Of course, you will see complaints here.

I’m not angry at you. I just want to find the solution to the problem. Your attacks are not helpful. No, you can not help by looking at the code. You seem pretty technical (or at least you think you are)… run lsof and find out if you are indeed hitting file descriptor limits and if so, what are they all being used by?

1 Like
18

If you wouldn’t say it to my face, don’t say it.

I would tell you to your face that your software is buggy, quirky and slow. It’s pretty hard to defend crashing software.

you keep making insinuations that we are a failing company with a product that is grossly unpopular. Conversely, we are a healthy, profitable, growing company

I never said Roon is “failing” or it’s “grossly unpopular”. My point is that you NEED the Roon software to succeed in order to make Roon Labs work as a certification/licensing business. If no one uses Roon’s software, there’s no reason for any OEM to pay Roon Labs to license Roon Ready. Maybe you have millions of Roon app users, but I doubt it. Maybe you don’t need millions of users, but I bet you need more than you have. And you can’t get more with just marketing, the product has to perform well for many people. Writing off your forum complaints as the minority is a bad idea. They are the canary in the coal mine.

This attitude is good to hear, although it’s very different than what I’ve been reading.

You seem pretty technical (or at least you think you are)…

You’re trying to insult and condescend to me, I get that, but it would have been a more effective attack and a more professional response if you left out the parenthetical expression. :wink:

run lsof and find out if you are indeed hitting file descriptor limits and if so, what are they all being used by?

My soft limit is 256 and the hard limit is 10240 files (which are MacOS defaults). RAATServer currently has 79 open files and the Roon app currently has 419 open files.

RAATServer has several DLLs open and many more TCP/UDP open. The Roon app has DLLs, TCP/UDP and a lot of stuff under Roon/Database open.

19

Another item you got wrong … our business is not certification or licensing of Roon Ready – we don’t charge for that certification or integration. Same goes for Roon Tested.

You aren’t getting it. That’s not the violation, this is:

Do it again and you will be banned. The comment is not only ignorant (which I have demonstrated), it is against our community guidelines to do personal attacks. Stick to the bug, stop making comments about the staff or any other person on this community. You do not speak for them, and you should not speak about them.

Anyway, I’m going to focus on the crash and not on your personality issues.

Unfortunately, you aren’t crashing right now, and those numbers look in the right ballpark. I’m running just the remote, and I have about 550.

The problem occurs prior to the crash, and if you are indeed running out, it’s because something is triggering that. Knowing that it is indeed the situation and seeing via lsof what they were, would be the smoking gun evidence.

20

What do you mean I’m not crashing? It crashes every few minutes for me. It crashes even if I’m not playing music, just the app and the server sitting idle will crash it. If I restart it now it will crash within minutes.

Is it possible to run the server without the app on the same machine? It feels like the 2 talk constantly to each other and maybe that’s causing the crash.

What else can I check to figure out the cause?

21

You could try connecting your iMac directly to your router and playing through Roon to headphones and see if it still crashes.

22

That’s essentially what I’m doing. The iMac is connected to a network switch (a Ubiquiti switch, not junky hardware) which is connected to a router (a Ubiquiti USG, not an ISP’s router) and the output is over USB to a DAC and headphones amp. But it crashes regardless of which device I send the music to and even if I’m not sending music anywhere.

Interestingly, it seems to play the longest when streaming radio stations, it seems to go for hours that way before crashing. Playing tracks from Tidal or Qobuz seem more problematic and it’s between tracks that it crashes, usually not in the middle of a track. Of course, that’s when Roon is doing the most intensive work. But that doesn’t explain why it crashes when idle.