Tag Query Performance

James_I · February 28, 2018, 3:07pm

Happy to have Sallah find a technical solution for networking his PCs, but time to get this post back on track.

One thing I have noticed in combining Tags: it really slows the performance of the Roon search system quite a bit. I suspect there is some coding inefficiency in combining Tags.

My Roon Core is an AMD quad-core 3.6 GHz, 16 GB RAM, and plenty fast for almost anything. Just using it for upsampling without any DSD or similar format conversion. Library is on a fast Samsung SSD. Thoroughly modern.

So, I can have all albums or all tracks displayed (6800 albums, maybe 90k tracks). Filter by a single Tag works quite quickly to display only objects associated with that Tag. So far, so good. BUT, add a second Tag and then click it to minus for the “AND NOT” logical function, and it will show that little processing Roon symbol (looks like my son with his cheeks full of apples he is chewing) for 15-30 seconds or more depending on how many objects are involved in the AND NOT filter process.

Given the modernity of the hardware and the availability of system resources at the time, there must be some issue with the efficiency of the coding in this area. That’s not meant to be an attack - I am not qualified to speak to the overall coding quality – but this seems so much slower than almost anything else I see Roon do (other than wait for Tidal track streams to kick in, which can be really slow at times as well) that I have a sense that the coders have not yet optimized this process.

This slowness is also reflected when initiating a shuffle of the resulting tracks or albums…there will be a 5-15 second delay before the new Shuffle starts to play once the shuffle button is pressed.

So, in addition to the Roon features discussed above that the masses MUST have I think Roon also needs to look at the performance of multiple tags or filters being applied in layers.

anon74822662 · February 28, 2018, 4:47pm

am noticing slow downs also, james. i have many tags now!

Paulb · February 28, 2018, 6:59pm

Hm, just now I am spending some holiday time setting up my Tags & Bookmarks like:

James_I · February 28, 2018, 7:37pm

Try a complex query using one positive Tag and one minus Tag (i.e. AND NOT in boolean logic) and see what you get in terms of speed. I am getting the munching Roon symbol for a few seconds to 30 seconds depending on the amount of tracks or albums involved. 3-5 seconds is no big deal, but 30 is unacceptable. Oddly I don’t see this behavior with any other media manager unless a drive is waking up. But that shouldn’t be an issue with the Roon DB on an SSD.

Paulb · February 28, 2018, 8:12pm

I don’t have many tracks tagged yet, around 700 (no albums or other entities), with one positive and one negative it’s almost instant. With a complexer query it goes to seconds. With all Tags positive and one negative it’s indeed around 30 seconds.

James_I · February 28, 2018, 8:26pm

Thanks Paulb. As much as I don’t want to narrow the scope of the thread, I do think we have to add query performance to our Tag wish-list. (I almost wrote “wish-lust,” which indeed it kind of is…).

There’s no point in robust tag support if it takes too long to run a query. Instant is great, but there cannot be lag long enough to generate annoyance. Ruins the whole experience.

anon74822662 · February 28, 2018, 10:36pm

Agree with James; there must be some coding issues to create such slowdowns. Im getting much the same problem mixing tagsnbookmarksnviews. Maybe something to highlight in support. Cite our instances and hopefully they can establish the bottleneck coding?

James_I · February 28, 2018, 11:21pm

Tried it with some big Tags:

(1) Display all albums. Total Albums 6175.

(2) Filter by one Tag that has 1681 albums in it (the tags are actually applied to the Artist). Took maybe 15 seconds to display. Not good, but acceptable.

(3) Use the minus on a second Tag to filter, this Tag had 845 albums in it (as above, the tags are actually applied to the artist. So, query is to display albums associated with first Tag but not the second Tag. Took over 2 minutes. Not workable.

(4) Reset. Took so long I stopped timing, closed the remote application. Reopened and it was blank until I walked over to the Core and clicked on the open Roon interface on the Core.

Something is a bottleneck here. It could be that the Tags are applied at the Artist level and I was querying on albums. Doing the exact same method applied directly to artists is MUCH faster. But a lot of the benefit of Tags is lost if you cannot use it with associated objects.

I’ll post a reference to this in Support. Not sure if that is how it is supposed to be done, so moderators, feel free to fix how I cross reference this.

Carl · February 28, 2018, 11:49pm

Just including @support should get their attention.

James_I · March 1, 2018, 12:03am

Thanks. I always thought only the moderators had that “power.” Well anyway now it’s there.

eric · March 1, 2018, 6:06pm

@Carl, as always thank you for dropping us a flag "here’’, appreciated!

@James_I and @anon74822662 thank you both for the feedback, the insight is always appreciated! I am going to schedule some time for our techs to investigate this behavior further, but before I do would you kindly please provide the following (if you have not already):

A brief but accurate description of your current setup.
Please verify where your musical collection is being stored/accessed from and the size of the collection based on number of track (approx.).
In regard to this behavior where is it being experienced? On all devices? On some?

-Eric

James_I · March 1, 2018, 6:13pm

Hi Eric - thanks for your attention. Will respond in substance ASAP. Hopefully by end of day today (Chicago time).

anon74822662 · March 1, 2018, 7:13pm

Hi Eric

Main rig, Core, HP desktop 3.4mhz, 16gb ram

Music collection stored on 2x 4tb HDD’s attached to the above desktop pc; chord mojo DAC connected

Remote Sony vaio laptop feeding KEF X300A’s

Desktop and Sony lappy are connected to TP Link MR400 router via ethernet cable.

Tabpro S and Tab A as remotes.

track count 152k or so.

Slowdown detailed above is apparent on whatever im using to control Roon.

CHeers!

anon74822662 · March 1, 2018, 7:16pm

funny, james i thought you were british somehow? Or maybe you are, a brit abroad, like me?

James_I · March 1, 2018, 9:44pm

Hi Sallah. It must have been my excellent grammar! Nope, I’m a yank, born and bred. But I’ve always been a fan of British rock, British beer, and the history of the British navy. That said, until we have a new president, I prefer people think I’m anything but…

James_I · March 1, 2018, 10:06pm

Roon Core: AMD quad-core 3.6 GHz, 16 GB RAM. OS and Roon DB on a Samsung SSD. Dedicated to Roon, nothing else going on in that machine.

EndPoint: An early version of the Computer Audiophile configurations: Intel embedded Atom CPU and a SoTM USB adapter feeding USB to Wyred4Sound DAC, not that the endpoint has much to do with the issue.

Remote: my current desktop: AMD A8-6600K quad core 3.90Ghz, 8GB RAM, Roon and OS installed on 2-SSD in RAID 0

Music storage: home-built UNRAID server running a bunch of 3TB spinning disk drives of various brands, pretty sure they are all 7200s. The UNRAID server was my old desktop to about 4 years ago and fairly fast. I don’t recall but I think I put in a lower power CPU than the quad core I had in it in order to reduce heat and fan noise, but I would still expect the UNRAID server to have more processing power than most of the NAS systems people are buying as dedicated boxes…it is not slow.

Library: 95,000 tracks. About 70k are on the UNRAID and the rest are Tidal.

Behavior where: I have not tried it on every remote I have (I went crazy and installed Roon all over the place. That said most of those PCs are currently off or Roon is not running on them). I experienced it on the desktop remote above and I just tried it on the Core (which is running regular Roon) and it was actually worse than reported above.

On the Remote, it was as above in terms of the time it took. On the Core, I just brought up the all Albums page, and went to filter by a Tag - the Tag has about 1400 albums (associated with the Artists, not the Albums) and it took about 70 seconds for the page to load. Then I brought up a second Tag that has about 900 Albums in it (again, associated with the Artists, not the Albums) and then clicked the minus sign on the second Tag. That query has been running since I started typing this and is still running. So maybe 3-5 minutes. There, it just finished. Way too long in any case.

As mentioned, this behavior seems much more severe with objects associated with a Tag applied to another object - i.e. filtering Albums by an Artist that is Tagged. It runs much faster when querying for objects to which the Tags are applied directly.

anon74822662 · March 2, 2018, 4:50am

I can’t seem to find the long post i made describing my problem?? Was it moved/deleted, did you see it?

Briefly I am having problem with specifically displaying

When drawing items from nested tags. Period. The more items embedded within tags of tags the slower it is.

eric · March 2, 2018, 2:55pm

@James_I and @anon74822662 — Thank you oth for touching base with me and providing the requested feedback!

Sallah_48, the post you are mentioning that can’t be found, was that listed in this thread or another one? I don’t recall seeing it and I haven’t deleted anything here

-Eric

UPDATE: @anon74822662 is this the post you are referencing? (see below)

anon74822662 · March 1, 2018, 5:41am

Hi, I am having similar issues with tag display.

I am working through all albums, bookmarking them with various attributes and am noticing like James, a slow down but in one specific view position. Ill describe it below:

System HP Desktop running 16gb ram I7 3.4mhz, Windows 10

latest Roon running about 11500 albums

Currently I have 1250 or so tags including nested tags

I am tagging each album with a reference and genres and in there I put all duplicates/different versions of albums

eg here’s a tag for Trick of the Tail:

and within the “master” album i tag for genre

Each tag of album no goes into a tag called “0 Albums”

Then I can view all albums in a nice, organised way according to my preferred way of view, date of acquisition.

When I “view all albums” from this 0 Albums tag, I get the big slowdown to view all albums of about 40 seconds.

Any further manipulate of this view takes a similar amount of time to re-view. Eg sort by date added, or reverse the view order or go for the “- 0 albums” view, etc. I use the latter view a lot to select albums which I haven’t processed yet with tags.

Note, if I do a VIew All… on other views it gives similar slowdowns, eg View All albums in the Rock nested tag

Note, if I do a View All in a non-nested tag, there is no slowdown.

Happy to explain further and hope this can help with debugging.

James_I · March 6, 2018, 8:31pm

I’m going to bump this - mostly to see if support feels this is a problem within Roon architecture or if these queries seem to run fine when you try to duplicate the issue at the company. My project of tagging artists with the intent to use them at album level is somewhat on pause until we see whether that query performance can be improved. It’s rather too slow to be useful now.