My music (around 2000 albums in local storage) stopped because someone dug through a cable two streets down.
I don’t need search at all. I just want to click on an album cover and hit play. I’m happy to have no search function off line, I really do see the logic of online there. But being able to scroll through the local albums is an acceptable minimum, no?
Guess I’ll need to tune up the record player again.
Whilst I voted for this a long time ago, I have so far refrained from posting.
However, it appears to me that searching when online (with associated streaming services) is a very different proposition to searching when offline - when, by definition, you can only search your local library.
I’m not sure that an offline local library search has such a high value to me when compared to online search (including non-library content available via streaming) and much of what I would want to do can be achieved by the filter mechanism.
Consequently, if offline local search really can’t be provided, I too would be infavour of a fallback position where Roon continued to function for local library access but without search at all.
Edit: @Wade_Oram even offline, one would need search just to find something to play. even a listing is effectively a search.
i’d just add that an local or offline search is by definition on a very reduced dataset - one’s local library. in the case of no internet, there is no point in searching the streaming services, is there? and the local database is on an nearly empty SSD, run on a multicore machine… shouldnt be that complicated, or slow.
Its been decades since i wrote an sql query but I remember a college project of a 50k-record database on a 233mhz pentium and PATA drives, and it didnt seem slow at all. (or maybe i was just more patient at that time)
To avoid all doubt, it is the feature that Roon calls “Search” using the ‘magnifying glass’ that I can do without (if necessary) when no internet connection is available.
The feature that Roon calls ‘Filter’ is essential - even when there is no internet connection.
Oh please, you know what the point is! If a database query in 50k data records wasn’t rocket science a few decades ago, then it should be somehow feasible today with computers that are tens of times faster.
I’m pretty well convinced that Roon was developed by someone who had an idea, and didn’t really care if anyone else was on board. When it turned out that bunch of other people were interested, they hired some questionable coders, who built it into a hard-to-modify specialty platform, ignoring the state of the art and the adaptabilty that affords. Now, when the voices of the screwed are getting louder, they’re selling out to for medium money instead of sticking it out and making Roon work the way it should. Over their heads, angry customers, crap codebase, sell out and run away. It’s the American way.
I’ve recently been talking about Roon to some programmers at a very large and very successful company. Extremely successful, you might say. They said that RAAT was a great idea, but the idea that the network had to have perfect topology and hardware was ridiculous when considering the realities of scale— it’s fine if you have 500 wealthy and gullible customers, but when you start to deal with “the public”, that ain’t gonna fly, and it’s ridiculous to insist that it will. They had similar comments about search. It’s not an intractable problem, but it’s pretty damned hard if you don’t have any real clout. The services just don’t care, and you can’t force them to care, because Roon isn’t big enough to matter. Tidal and Qobuz and everyone else aren’t going to spend resources helping a tiny vanity project. They also pointed out that a codebase predicated on someone’s special idea is great if you don’t care if it works in most cases, and don’t care about updating it using programmers who are used to conventional databases and programming methods. “We’re special” works for companies like Apple, because they can force it to work, with a literal trillion dollars, but fails miserably when you’re nowhere near that, and have to please regular people. Now that they’re bought, we’re going to see a bunch of screwing around trying to fix things that aren’t designed to be fixed in any normal way, a bunch of deeply misguided corporate initiatives and misunderstandings, and then, in the not-too-distant future, Roon will be left to die with no support and no development. If it lasts five years, I’ll be amazed. It’s really too bad. Hubris is killing Roon, and it will ultimately be the death of what could have been a truly great product in the hands of a more open-minded and less hubristic group of people.
*of the nine people I talked to, six of them were Roon subscribers or lifetime license holders. They wanted it to work.
I think you have missed the point. Roon uses a NoSQL database, and therefore the example of an SQL query and comparison of such databases is irrelevant. There is no relational model nor indexes.
If you care to search the forum, the rationale for the database is discussed.
I am not a programmer, but a naive question I have is can’t Roon implement a filter on NoSQL database that you mentioned, or any database whatever database system is used? Even Excel, which is not a database software, could do filter (as well as search). So could a much more simple software like MP3Tag that I used quite a lot when I curated my files.
Search is preferable. However, filter is acceptable. Even for a small collection, simply being able to scroll up and down the album or track list and hit the Play button should allow anyone to just … play.
Any other explanation is simply an excuse or dodging something.
And NoSQL databases are no longer new, novel or “special”; there are plenty of developers working on them, day in and day out. Almost inarguably, software engineers who wish to be working with progressive tools and applications are vastly more interested in working on applications using NoSQL and graphing databases than working with applications that are suited to SQL databases, which are basically business applications that are important but incredibly boring.
I read you, but I can restate it as, it’s a choice between engaged developers who stay with you for the long haul to create an application that is using the right architecture vs rotating developers who come and go and contribute to a codebase that is hampered by inconsistencies and generations of ego-based refactoring.
Both have downsides, but I think Roon’s current approach has an edge.
What I’ve sensed from afar is they Roon’s core talent opportunity is in engineers who are very experienced with network-layer coding. I could be wrong, however. Armchair software engineering is dangerous, even if you are a software engineer (as I am).
1 Like
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
570
Speaking of engaged developers, it would be interesting to know what the stock-option situation at Roon is now that they’re part of Harman/Samsung.
Let’s not lose sight of what the real issue here is… Roon stops working when your internet stops working. Another way of phrasing the feature request is simply… 'Please provide a way to use Roon to play my local music when my internet service is temporarily offline".
I doubt Roon Labs is at a loss of developer skills. It’s a matter of priority and design choices. Hard to imagine this wouldn’t be a highly welcome “feature”, but I sure would like to know if Roon has any interest in stepping up to this. If not, say so and let’s move on. Perhaps the “[not on roadmap]” is a clear enough statement. I’m just not sure who wrote that into the title.
It’s a disgrace!
But who knows, maybe under the new owner of Roonlabs the priorities will shift a little and the needs of the customer will come to the fore again.