But now I’m seeing more and more instances of the following log Warn message:
09/11 13:16:17 Warn: [cast/discovery] unexpected KeyNotFoundException error in device data: System.Collections.Generic.KeyNotFoundException: The given key 'md' was not present in the dictionary.
at System.Collections.Concurrent.ConcurrentDictionary`2.ThrowKeyNotFoundException(TKey key)
at Sooloos.Audio.Cast.CastDeviceData.ParseProperties(ConcurrentDictionary`2 props)
And by “more and more”, I mean I current have 585,684 instances of this log message in my RoonServer_log.??.txt files.
As far as I know I’m not running any Sooloos code, tools, or apps in my environment (but something I’m running on the Pi may be related? not sure…).
Of course the goal is to actually resolve the original issue, but this error has become so common in my logs it’s really starting to bother me.
Can Support share what this log entry is meant to Warn me about? Thanks!
This may not be pertinent to your most recent problem, but looking at your network reachability issues, I wondered if you may have some network interface (wired or wireless) on the MacbookPro that keeps going to sleep causing a network change event that confuses Roon. By design, Macs “like” to put things to sleep when they aren’t used, and it’s conceivable that Ubuntu does not know how to manage that perfectly (I’ve not used Ubuntu on laptops recently, but it used to be pretty much a nightmare because of power/sleep management).
Now, even if that is a problem, I have no idea why that would cause a key to disappear from a disctionary inside Roon, but that problem seems to be around device discovery, which is very network-dependent.
I run several Ubuntu Server boxes with Roon cores, but I’ve tried to make sure their network configuration is simple and always-on. Never saw any problems like yours on them, in 7 years of Roon use.
Thanks for your patience while our team works through each thread!
Following up on your issue, its likely a case where one of your cast devices is missing properties Roon is expecting, therefore throwing the exception.
How are your cast devices grouped? Can you provide any information about their setup?
Good tip but not that I can tell. No sleep or suspend notifications in syslog and not interruptions in streaming, SSH, etc, but to test it I’ve completely disabled sleep, suspend, and hibernate and will keep an eye on the system for a while and see if it helps.
I typically group multiple devices at once, ranging from a group of two and five devices.
It’s a split of wired devices and wireless
The devices are a true hybrid:
Cambridge 851N (wired)
Pi’s running Ropieee with HiFiBerry HATs (two of these, one wired, one wireless)
Pi running HiFiBerry OS with HiFiBerry HAT (wireless)
Pi running Linux and RoonBridge w/ USB out to a DAC (wired)
I never have any real problems with grouping – audio is always in sync, volume leveling works for ever device, etc – but once in a while I’ll get weird anomalies where one device, usually the 851N, will report that it’s lossy and that there’s an unknown filter in the signal path (which seems to be a bug b/c it only happens every once in a while with grouping and never when streaming directly to the 851N). Other than that, nothing to report. Let me know if you need anything more specific.
I have been running a full grouping of all 5 devices today to test to see if I received the KeyNotFound issue I haven’t been able to reproduce it all day.
