AceRimmer
(Smoke me a kipper, I'll be back for breakfast!)
62
I certainly do not own that many CD nowadays but I have sold many over the years but have always ripped them so kept them on hdd.
Then there is my daughters collection which I have copies of as well, which does include a lot of mp3 grade stuff I admit.
Best guess right now is …
2100 records
740 cassette tapes
300 CD
That the actual physical hard media in my possession.
My daughters collection…
300 records
600 CD
Thats her physical hard media.
Then I have rips of EVERY CD I have ever owned at any time.
I did also buy a used USB HDD on a fleamarket and it had about 3000 albums on it!
I had maybe 20% of those already so that helped boost the track count a lot.
I admit the likelihood of listening to the majority of the rest of the stuff on that particular HDD is remote…
If you’re experiencing app crashes, then this is NEVER down to whatever setup you have yourself. App crashes should be fixed… nobody should have to jump through hoops to avoid app crashes. Let’s place the responsibility where it belongs: the developers should fix it. Everything else is just a workaround, NOT a solution.
Crashes, in general, bring down the overall quality of any application to alpha software, since it should be absolute priority to keep things stable and usable. Forget about features as long as things are not working properly. Create a stable experience upon which to build new features. Priority 1.
BY FAR most people have a very simple home network setup: a modem/router, maybe a few devices wired, the rest wifi. Most people don’t even know what a network switch is, what dns is, what ping is… and they should not need to know. So once again the same rule applies: if there are networking issues, those should be ‘caught’ by the application. Create a ‘Network Diagnostics’ tab to check whether things are working properly. For a VERY network-intensive application like Roon, I strongly believe this is a necessity… and quite frankly, this should have been a priority from the start. Priority 2.
Then there’s priority nr. 3: decent communication. Give your users the notion that their problems are heard. Use a ticketing system. A community like this is brilliant, but it should be all about user-to-user communication and help, maybe some announcements from Roon (f.i: which bugs are fixed in bug-fix releases). But a forum should NOT be about sending in issues because it’s the only way to be heard and get a response! It’s nice to see Roon people replying here and getting involved, but I’d rather have them focus on anything except getting bogged down in these endless discussions with a terrible amount of ‘static’ (just look at this thread here… it’s not even about what OP posted anymore).
So… Roon people… no pressure whatsoever! But really, just focus on these nr. 1, 2 and 3 priorities. Otherwise, you’ll keep busy extinguishing fires only to find them re-occuring somewhere else.
@hook_menu_alter – I don’t really have any useful suggestions, but FWIW, I can confirm that issues that I could not believe were network-related were in fact so:
I used Roon very stably from a Win10 laptop for about 1 years on a 20 Mb/s down - 0.8 Mbs up DSL connection. I was running the Win10 laptop wireless. But I was playing only local files, no streaming.
After 1 year of usage as above, I started using Qobuz. At this point, I had to connect the Win10 laptop via ethernet, or streaming was flaky.
This was despite every other application on every device in my house working fine via wireless (including video streaming services).
After 1.5 years of using Roon, I migrated my Core to a NUC running ROCK. At this point, Qobuz streaming fell apart.
But Qobuz on the same NUC running Win10 was very stable.
This is the point at which I really could not believe that I had a “network issue” (b/c of points 3 and 5 above).
Right around this time, for different reasons, I upgraded my ethernet service to 40 Mbs down - 3 Mbs up AND a new modem (still DSL, and still not at all blazing fast), and NUC + ROCK + Qobuz now ran stably (with NO other change).
My conclusions:
I did NOT have a “network issue” in the usual sense of the term
BUT: Roon is more sensitive to network conditions and/or modem/router performance than just about any other piece of software I’ve ever used that relies on network connectivity
AND: ROCK is also (even more?) sensitive to network conditions and/or modem/router performance than just about any other piece of software I’ve ever used that relies on network connectivity
As for why this is the case with Roon:
I found the explanations provided by @ged_hickman1 extraordinarily insightful and helpful:
As for why this is the case with ROCK: I’ve been told that Windows/MacOS have mitigation measures to stabilize DNS lookup (something to do with buffers…?), that ROCK does not.
@ged_hickman1 – how on earth did you learn about the information quoted above? IMO, that is such valuable information/insight that, considering how often the network is the issue, it ought be in the Roon Knowledge Base somewhere (or is it already?) In any case, thanks for sharing it!
This has been my experience, too. Sometimes it works, sometimes it doesn’t. When it doesn’t, I switch to another player. I can’t be arsed to fool around rebooting every device and my network just because Roon decided not to work properly especially when other apps have zero issues playing. It’s just too frustrating and arbitrary. Roon’s great when it runs, but robust it is not.
There is also the buy-it-and-dump-it scenario: Say I make $USD500k per year, and, on a whim, spend $450 on Roon Lifetime. If it doesn’t work, I’m less likely to screw around on support forums trying to solve it, and I’m more likely to just delete it and keep moving. As Roon is a high-end luxury software product, I suspect this happens pretty often. I’d love to see a licenses-sold v.s. active users figure.
Knocking on wood and drinking water upside down, but I feel I’m on the other side now.
I feel for all the hard working people who buy Roon and they have constant problems. I also see way too many threads were people are asking for help, and they get a response 7 days later.
Work at college and then commercial radio stations for a few years in the 80’s and 90’s, and you amass an amazing collection for very little money. Alternatively, there are plenty of people who can spend $USD20k per year on music and not even notice.
2 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
69
Technically, at least in the USA, if you sell a CD you’re violating copyright laws if you don’t delete all the rips and backup copies of that CD that you have.
1 Like
AceRimmer
(Smoke me a kipper, I'll be back for breakfast!)
71
Only if you don’t have another good router behind it.
And do not use the ISPs WiFi. Disable that. Only plug your router into the one in bridge mode. Build your local network off of the router you provided.
Verizon and their MOCA crap used to mess up everything. Not sure if they still do that.
Normally you are able to change some wifi settings in the ISP routers. Just turn the wifi off and connect your new router to one of the switch ports in the ISP delivered router. I’ve done that (and also switched off DHCP) and if I just create a new subnet with the new router I can ignore the ISP router completely. Works perfectly!
Thanks for the suggestion, I have tried a similar solution in the past but did not turn off DHCP (in the ISP router) or create a new subnet (with the new router), which I think led me to having double NAT issues on my network at the time I tried. Will give this a go, sounds like it might help at the same time as hopefully solving the double NAT issue I had in the past.
I’ve mostly fixed my issues (i.e. 98% of the time Roon is running without hickups) mainly due to where I have placed my endpoints in relation to the shoddy ISP router…but I am always looking to make my network more robust (not just to run Roon) and being able to bypass my ISP router would be a great help.
A bit late in responding but fantastic summary @Chris_Roon and +1 on the ticketing system. I’m speculating but I suspect that would be much easier to manage from roon’s side too.
Totally agree on the points about software resilience and diagnostics too.
Finally, just a point about prioritisation - as I was putting my original post together, I was thinking along the same lines. With my teams at work, I push for huge focus on stability and actually leaving features out to the point where there has to be a hugely compelling argument to put something in - the default answer on any request is “no”.
Adding shiny new things is great, and helps to sell a product, but if, overall, things are flaky, you’ll pay the price in the long run.
But really, just focus on these nr. 1, 2 and 3 priorities. Otherwise, you’ll keep busy extinguishing fires only to find them re-occuring somewhere else.
