Good point. People who have zero issues generally don’t post much. So watching this forum you are seeing much of the worst and not able to compare it to the good.
Perhaps by way of explanation, and at risk of stating the obvious… “working on” does not necessarily mean “developed single-handedly”. One could “work on” a 20-30 million line code base by doing very little, if it’s already built and running successfully. I’m not saying that’s the situation for the OP, of course, but it perhaps explains why your calculated number of lines per day is not a useful number.
Lines per day is an abysmal measure of competence, productivity, etc. that’s the point I was trying to make. Stating that is just trying to puff up one self for no reason other than to provide a simulated air of I’m better than others.
Completely agreed, but the OP didn’t make a claim of “lines per day”. Reading things in a more positive light, the numbers are there to indicate that the OP is no stranger to working with large and complex software projects. That’s a reasonable point to make, I’d say, although I agree it could have been done more subtly.
My experience as a working developer was brief but I was presented with a mess of legacy in VB with newer stuff in C# . Data access was a mix of 3rd party library and raw SQL . Whoever designed it decided that logic should reside in stored procedures
So yes fixing your OWN code is easier than someone else’s , but we often don’t have the luxury of developing new stuff with “shiny new” technology 
Progress often requires a back end or db change , by not upgrading you will soon become incompatible with the background infrastructure.
Not screwing up your library I do agree with.
I have used Roon for coming up 6 years and have never been aware of my library being affected by anything other than my own metadata changes.
Each to his own I guess
1 Like
If experience in a field and in a particular workplace would not apply to the same field in another workplace, then experience would always be irrelevant. It’s like a Roon hiring manager telling a candidate: “Yeah, you do have a lot of experience in software development, but not at Roon, so it’s irrelevant”.
Your experience somewhere else or anywhere is irrelevant regarding these two issues at Roon unless you have actual experience AT ROON.
Excellent point, but I have to say I regard this as heroic. Multicast should work everywhere, and Roon’s use of its customers to help that along is more evidence that it’s not your usual software company.
In my [long] experience integrating disparate software systems and protocols, I find that internal protocols, that is, not 3rd party, are the most poorly documented. Things some programmer years ago, who has now left the company, thought was a good idea, but failed to write down anywhere but in the code.
That would be the intern.
1 Like
Who wrote the unreviewed code.
Roon is a software company, subject to the dynamics that apply to all such companies. They admitted to being a small team, and looking at how long it takes sometimes to respond to support issues, it suggests they are quite resource constrained. Not to mention, if there is no constraint at all, chances are you’re bordering inefficiency.
Regarding the division of work between developing features and diagnosing and fixing bugs, I don’t think you can get too far these days by putting people in silos with strict responsibilities, especially when you’re resource-constrained. We used to have dev and dev-in-test as different engineering roles. Many times during interviews, if a candidate was not deemed skilled enough for dev, we’d recommend for dev-in-test. We realized, at long last, this was not ideal, and now we only have devs. Every member of a team shares equal responsibilities across developing new features, testing them, diagnosing reported issues and fixing them. That’s my experience.
I’m not disagreeing with any of that. But, we don’t know the specifics at Roon. Maybe they are under staffed, under trained, or just inept, or some combination of all three. We don’t know. Or, maybe their product is too complex and too unwieldy. Maybe turnover is too rapid. Maybe they are not organized properly or managed properly. Or, maybe they do a great job and customers are just too picky and expect too much. Or, maybe everything is fine.
Of course we don’t know for sure, but we can speculate, can’t we? It’s fun.
2 Likes
It does not. IGMP snooping is a notorious offender, because different implementations use poorly-documented heuristics to decide whether to cut off particular IPs. If an app (like Roon) uses multicast in ways “unexpected” by a particular implementation, some endpoints can be cut off. That’s why replacing overly “smart” managed switches with cheap unmanaged ones can help. In any case, IGMP snooping is ridiculous overkill for a domestic LAN.
1 Like
Yep. I meant “should” more as a moral imperative than a description of the current state of practice.
I’m more of a music lover than I am a technologist and technology is what drives the discussions on this board. The advice on this board concerning an issue I had was solved via input from some folks much more knowledgable in networks, etc. Which ultimately moved me to install a mesh network in my loft - problems solved. I’m very appreciative of the board for that reason.
1 Like
Hope this isn’t a duplicate comment.
I’m in agreement that the complexity of Roon contributes to the problems at upgrades. But I can’t think of what I’d want them to remove. I’m impressed with the creativity and passion they have for the product.
One way to counteract problems with complexity is to allow toggling of features. In some contexts you don’t need all of the reviews and pictures for instance.
I’ve been thinking about how the complexity of Roon and fact it was designed for home use may contribute to my frequent ARC crashes. Does Roon server perform services designed for home functionality, that aren’t needed for a remote app? Like polling for new tracks or indexing maybe? Or more likely things like search algorithms are not optimized for a mobile app delivery?
Regardless, I’m upgrading my processor and motherboard hoping to get better performance.
Except that it is required for most IPTV networks (at least in The Netherlands). It will flood your home network with multicast traffic if you don’t use/enable IGMP snooping on your switches. IPTV is used by the biggest internet provider in The Netherlands.