Bugzilla – Bug 7992
Bad query used for CLI 'artists in genre' queries
Last modified: 2010-04-08 17:26:28 UTC
The SBC looses communication with SC if the SBC makes a request that initiates a query from the MySQL db that is slow to respond. How to replicate: Using SC7.1 and jive_7.1_r2360.bin: 1). Turn slow query logging ON for MySQL: Add the following entries to my.tt under both [mysqld] and [mysqld_safe]: set-variable=long_query_time=1 long_query_time = 1 log-slow-queries = /var/log/mysqld-slowq.log Create the log file: touch /var/log/mysqld-slowq.log chown mysql:mysql /var/log/mysqld-slowq.log 2). Restart SC. 3). Identify a genre with more than 4000 tracks. 4). On the SBC: browse to Music Library->Genres->The Genre identified above. On my system, the SBC never displays the artists for that genre and eventually (within 1 minute) looses communication with SC. Checking the slow query log, you should see an entry like: # Time: 080426 13:29:25 # User@Host: squeezecenter[squeezecenter] @ localhost [127.0.0.1] # Query_time: 37 Lock_time: 0 Rows_sent: 1 Rows_examined: 4801573 SELECT COUNT( DISTINCT( me.id ) ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) WHERE ( ( ( genreTracks.genre = '7' ) AND ( contributorAlbums.role IN ( '1', '5' ) ) ) ); # Time: 080426 13:30:03 # User@Host: squeezecenter[squeezecenter] @ localhost [127.0.0.1] # Query_time: 38 Lock_time: 0 Rows_sent: 43 Rows_examined: 4801659 SELECT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) WHERE ( ( ( genreTracks.genre = '7' ) AND ( contributorAlbums.role IN ( '1', '5' ) ) ) ) GROUP BY me.id ORDER BY me.namesort LIMIT 43; Note: the value for genreTracks.genre = '7' will be different for you. Notice that the above queries examined over 4.8 MILLION rows apiece and took 37 and 38 seconds to execute, respectively! Test the above queries in the MySQL Query Browser gui app to see just how slow those queries are. To fix this, one or two things must be changed: The timeout value in the SBC code where it's waiting for the db request to be returned must be increased... --or-- the code needs to be changed to produce more efficient SQL queries. For instance, the query: SELECT Count( DISTINCT( me.id)) FROM ((contributors me INNER JOIN contributor_track ON me.id = contributor_track.contributor) INNER JOIN tracks ON contributor_track.track = tracks.id) INNER JOIN genre_track ON tracks.id = genre_track.track WHERE (((contributor_track.role)=1) AND ((genre_track.genre)=7)); returns the same data as the inefficient query above (the count of artists in the genre) but returns in a fraction of a second, rather than the 37 seconds that it took my system to return the results via the inefficient query. Also, the query: SELECT DISTINCT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM ((contributors me INNER JOIN contributor_track ON me.id=contributor_track.contributor) INNER JOIN tracks ON contributor_track.track=tracks.id) INNER JOIN genre_track ON tracks.id=genre_track.track WHERE (((contributor_track.role) IN ( 1, 5 ) ) AND ((genre_track.genre)=7)) ORDER BY me.namesort; ..again returns the requested data (the artist's names, etc.) in a fraction of a second versus the 38 seconds required by the inefficient query.
In the instructions for turning slow query logging on, please add the following command: chmod 0666 /var/log/mysqld-slowq.log ..so as to set the appropriate permissions.
Please see more info on this at http://forums.slimdevices.com/showthread.php?t=46850
I can confirm that browsing my Pop genre (88 artists) does take >30 seconds on a ReadyNAS using the Controller, during which mysql is at full load. The web interface still takes lengthy <10 seconds, but it's mainly in SC building the page. MySQL doesn't work a lot in this case.
Created attachment 3309 [details] Proposed patch Can you guys try this patch? It removes the bad contributorAlbums join and uses the contributorTracks table for the role lookups.
This seems to fix the problem, with 7.1 at svn 19249. I'll test with 7.01 too.
OK, testing with 7.0.1-0.1.19242: your patch seems to completely fix the problem on 7.0.1 too. Thanks!
Great, fixed in 7.0.1 change 19251.
(In reply to comment #6) > OK, testing with 7.0.1-0.1.19242: your patch seems to completely fix the > problem on 7.0.1 too. Thanks! > Closing bug
Hi Folks, This might be fixed for some folks, but it's still going strong for me (I'm using 7.0.1). In my case, the genre with lots of tracks in it is 'Rock'. I have 17,000+ tracks (1500+ albums) in that genre, which is quite a bit more than the 4000+ tracks suggested in this bug. Perhaps that accounts for why I'm still seeing this issue when the 7.0.1 fix has worked for others? My symptoms are exactly the same. If I select Genres->Rock from the SBC, mysqld will sit on top for about 2 or 3 minutes using 100% of the CPU. Meanwhile, the buffers will underrun in any playing squeezebox or transporter and the controller will lose connection to the server. In contrast, when using the web interface, selecting Genres->Rock takes < 10 seconds. I've captured a slow query log as suggested. In my case, almost 9 million rows examined in the queries. The log follows. Let me know if there's more I can provide. /u1/opt/squeezecenter-7.0.1/Bin/i386-linux/mysqld, Version: 5.0.21-standard-log. started with: Tcp port: 9092 Unix socket: /home/slim/Cache/squeezecenter-mysql.sock Time Id Command Argument # Time: 080703 13:32:45 # User@Host: [slimserver] @ localhost [127.0.0.1] # Query_time: 10 Lock_time: 0 Rows_sent: 1 Rows_examined: 8949789 use slimserver; SELECT COUNT( DISTINCT( me.id ) ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = '0' ) ) AND contributorTracks.role IN ( '1', '5' ) AND genreTracks.genre = '13' ) ) ); # Time: 080703 13:33:42 # User@Host: [slimserver] @ localhost [127.0.0.1] # Query_time: 57 Lock_time: 0 Rows_sent: 198 Rows_examined: 8950353 SELECT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = '0' ) ) AND contributorTracks.role IN ( '1', '5' ) AND genreTracks.genre = '13' ) ) ) GROUP BY me.id ORDER BY me.namesort LIMIT 198; # Time: 080703 13:33:53 # User@Host: [slimserver] @ localhost [127.0.0.1] # Query_time: 10 Lock_time: 0 Rows_sent: 1 Rows_examined: 8949789 SELECT COUNT( DISTINCT( me.id ) ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = '0' ) ) AND contributorTracks.role IN ( '1', '5' ) AND genreTracks.genre = '13' ) ) ); # Time: 080703 13:34:51 # User@Host: [slimserver] @ localhost [127.0.0.1] # Query_time: 58 Lock_time: 0 Rows_sent: 198 Rows_examined: 8950353 SELECT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = '0' ) ) AND contributorTracks.role IN ( '1', '5' ) AND genreTracks.genre = '13' ) ) ) GROUP BY me.id ORDER BY me.namesort LIMIT 198;
Reopening per request of user...Andy, initially targetting for 7.1. Re-target as you see fit.
John: What build of 7.0.1 are you running? The SQL you posted looks like it doesn't contain the fix for this bug, did you get a nightly from after the fix was applied?
Here's my squeezecenter version info: SqueezeCenter Version: 7.0.1 - 19705 @ Wed May 14 19:53:43 PDT 2008 - Linux - EN - iso-8859-1 I checked the code before I updated the bug to verify that I had the patch (I thought the same thing - that I must have a nightly which predated the patch, but I don't think that's the case).
OK, thanks for checking.
I can aid in debugging this if it will be helpful. I write perl for a living, but I know nothing about database queries. Let me know if there's something I can help you track down.
Going to have to punt on this for 7.1 I'm afraid.
John: do you, by any chance, have 'Group compilation albums together' enabled in Settings->Music Library->Compilations? If you disable that, do the symptoms disappear? If so, then I think I just duplicated this bug with my bug 9582 report. I didn't realize that this bug had been reopened. Andy, is it possible that your initial fix didn't cover the VA cases?
Yes I do have group compilation albums on, however, I'm in Mongolia right now and won't be able to test turning it off until early next week. Stay tuned...
Results from turning database.sql logging to info: Queries triggered by Jive with 'Group compilation albums together' DISABLED ============================================================================= [08-09-26 15:37:32.4115] Slim::Schema::Debug::query_start (26) SELECT COUNT( DISTINCT( me.id ) ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) WHERE ( ( ( contributorTracks.role IN ( ?, ? ) AND genreTracks.genre = ? ) ) ): '1', '5', '7' 1 row fetched in 0.0006s (0.0941s) [08-09-26 15:37:32.5119] Slim::Schema::Debug::query_start (26) SELECT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) WHERE ( ( ( contributorTracks.role IN ( ?, ? ) AND genreTracks.genre = ? ) ) ) GROUP BY me.id ORDER BY me.namesort LIMIT 40: '1', '5', '7' 40 rows fetched in 0.0008s (0.1309s) ============================================================================= Queries triggered by Jive with 'Group compilation albums together' ENABLED ============================================================================= [08-09-26 15:38:26.9052] Slim::Schema::Debug::query_start (26) SELECT COUNT( DISTINCT( me.id ) ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = ? ) ) AND contributorTracks.role IN ( ?, ? ) AND genreTracks.genre = ? ) ) ): '0', '1', '5', '7' 1 row fetched in 0.005s (3.6190s) [08-09-26 15:38:30.8220] Slim::Schema::Debug::query_start (26) SELECT COUNT( * ) FROM albums me LEFT JOIN tracks tracks ON ( tracks.album = me.id ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = tracks.id ) WHERE ( genreTracks.genre = ? AND me.compilation = ? ): '7', '1' 1 row fetched in 0.0005s (0.0484s) [08-09-26 15:38:30.8812] Slim::Schema::Debug::query_start (26) SELECT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = ? ) ) AND contributorTracks.role IN ( ?, ? ) AND genreTracks.genre = ? ) ) ) GROUP BY me.id ORDER BY me.namesort LIMIT 24: '0', '1', '5', '7' 24 rows fetched in 0.0009s (6.8317s) The inefficency of these querys is reflected in the MySQL slow querry log: Time Id Command Argument # Time: 080926 15:56:22 # User@Host: squeezecenter[squeezecenter] @ localhost [127.0.0.1] # Query_time: 4 Lock_time: 0 Rows_sent: 1 Rows_examined: 2220765 SELECT COUNT( DISTINCT( me.id ) ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = '0' ) ) AND contributorTracks.role IN ( '1', '5' ) AND genreTracks.genre = '7' ) ) ); # Time: 080926 15:56:29 # User@Host: squeezecenter[squeezecenter] @ localhost [127.0.0.1] # Query_time: 7 Lock_time: 0 Rows_sent: 24 Rows_examined: 2220813 SELECT me.id, me.name, me.namesort, me.musicmagic_mixable, me.namesearch, me.musicbrainz_id FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) LEFT JOIN genre_track genreTracks ON ( genreTracks.track = track.id ) LEFT JOIN contributor_album contributorAlbums ON ( contributorAlbums.contributor = me.id ) JOIN albums album ON ( album.id = contributorAlbums.album ) WHERE ( ( ( ( ( album.compilation IS NULL ) OR ( album.compilation = '0' ) ) AND contributorTracks.role IN ( '1', '5' ) AND genreTracks.genre = '7' ) ) ) GROUP BY me.id ORDER BY me.namesort LIMIT 24; ============================================================================= I'll do some experimenting over the next couple of days to see if there is a way to rewrite that 2nd query so that it returns data more efficiently.
Um...anyone noticing that with 'Group compilation albums together' enabled the Jive returns different data than the Web UI when doing a Genre->Artists browse ? Specifically, with my library, the Web UI returns 20 artists + 'Various Artists' whereas the Jive returns 24 + 'Various Artists'. From the web UI: Home > Genres > German Baroque Various Artists Bach, J S Bach, W F Benda, F Bodinus, S Buxtehude, D Erlebach, P H Falckenhagen, A Fischer, J C F Graun, J G Klein, J Kropfgans, J Marpurg, F W Molter, J M Quantz, J J Schaffrath, C Schenck, J Telemann, G P Various Weiss, S L Zelenka, J D count:21 List returned from CLI: artists 0 9999 genre_id:7 id:1880 artist:Various Artists id:2 artist:Anonymous id:802 artist:Bach, J S id:1123 artist:Bach, W F id:1126 artist:Benda, F id:1127 artist:Bodinus, S id:1159 artist:B%C3%83%C2%B6hm, G id:1128 artist:Buxtehude, D id:1129 artist:Erlebach, P H id:1130 artist:Falckenhagen, A id:1100 artist:Fischer, J C F id:1131 artist:Graun, J G id:986 artist:Handel, G F id:1132 artist:Klein, J id:1133 artist:Kropfgans, J id:1134 artist:Marpurg, F W id:1135 artist:Molter, J M id:799 artist:Pachelbel, J id:1136 artist:Quantz, J J id:1139 artist:Schaffrath, C id:1142 artist:Schenck, J id:1145 artist:Telemann, G P id:18 artist:Various id:1179 artist:Weiss, S L id:1180 artist:Zelenka, J D count:25
OK - flight back from Mongolia just got in and since this bug is a top issue for me, I tested it before even unpacking. As you suspected, turning off compilation grouping does indeed "fix" the issue for me. Glad we're narrowing in on this one. I'd love to test a patch if/when someone has one.
A much, much more efficient form of the VA query would be this: SELECT DISTINCT me.id, me.name, me.namesort, me.namesearch, me.customsearch, me.musicbrainz_id, me.musicmagic_mixable FROM (((contributors AS me INNER JOIN contributor_track AS contributorTracks ON me.id = contributorTracks.contributor) INNER JOIN genre_track AS genreTracks ON contributorTracks.track = genreTracks.track) INNER JOIN tracks AS track ON genreTracks.track = track.id) INNER JOIN albums AS album ON track.album = album.id WHERE (((album.compilation)=0 Or (album.compilation) Is Null) AND ((contributorTracks.role)=1 Or (contributorTracks.role)=5) AND ((genreTracks.genre)=7)) ORDER BY me.namesort; This returns the same data at the Web UI VA Genre->Artist query: 20 rows fetched in 0.0017s (0.2491s)
*** Bug 9582 has been marked as a duplicate of this bug. ***
I see this bug was moved to 8.0. Is there any possible way we could move it back to 7.3.1? This bug is really killing me. I write perl for a living and would be willing to help with a fix, but I would need some guidance from Andy.
This bug just got a whole lot worse with 7.3. I gave browse-by-genre a try again in a desperate hope that 7.3 would behave differently than 7.2.1. It did - a whole lot worse. mysqld sat on top using 100% of the CPU for about a half hour before I finally killed squeezecenter. Upon restarting squeezecenter, mysqld returned to the top using 100% of the CPU until I killed squeezecenter again. Squeezecenter is completely unusable during these times. None of the players can even connect. The only fix was to blow away the cache and restart squeezecenter, allowing it to rescan the music library from scratch. My frustration with this bug is growing by the day. I'm 100% serious that I will help fix this if I can only get a little guidance from Andy. I looked over the code for a few hours, but I'm just not a database guy and I couldn't really find a place to even start debugging. I write perl code every day for a living, so with a little guidance, I can probably help out with this.
Since I recently upgraded to new server hardware with more horsepower and with 4 times the amount of memory, at least the VA queries return before the SBC times out and disconnects and has to be rebooted. But it still takes way, way, way too long: 30 seconds or more. 'Group compilation albums together' is still totally unusable with my library and this bug is as annoying as ever. If there is to be any sort of interim release of SC before 8.0, I respectfully request that this bug be taken off the back burner, retargeted to 7.3.1 and be given some attention. I think that the sql queries that I posted above have conclusively proven that the problem here isn't a limitation with the underlying structure of SC's present db. It's just a mal-formed query that's returning a Cartesian result set. Andy solved half the problem last April. He just didn't address or test the VA==on case, and, as a tester of his patch, neither did I. But this IS fixable and hopefully wouldn't require much more attention than Andy gave it last Spring. John: If you look at Andy's patch from April that's still attached to this bug, that at least ought to give you file names and line number ranges to look at. Beyond that extremely superficial 'guidance', I've really got nothing to offer, myself. I'm a rank beginner in terms of writing perl code and dbi is a total black box to me.
I'm fixing this for 7.5 as part of rewriting the queries in this method.
I should say, 7.5-embedded, not 7.5.0.
== Auto-comment from SVN commit #29695 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29695 == Fixed bug 7992, refactored CLI artists query to use native DBI to improve performance
Andy, sorry if i asked this before... but when will all the "fixed" bugs for 7.5 embedded be merged into normal 7.5? i'm assuming when its officially released, (no longer a beta). is that correct?
I don't know, when it works on all platforms and we feel it's stable enough. The more testing people do, the faster it will happen. It will almost certainly not be for 7.5.0.
i see. i'm using 7.5b now on windows btw. seems very stable to me. what i find fascinating about the "7.5 embedded" is this seems to be the new SBS. what i mean by that is that its a closed system, where logitech has complete control of the environment, and you guys seem to develop first for that now, and propagate the changes out to the other platforms later. i am a fan of this approach, i think it will lead to faster development of SBS, at least on the embedded platform. i have said for a long tme now i would like logitech to do just this, ie. create a closed environment "server box" for sale, and develop first for it, only include the webui and so on, etc. my only concern is how do you know what things to merge later? once the bug is closed, how do you know what was fixed for just SBS embedded as opposed to SBS global? and how are we, the users, supposed to know when a bug, like this one, is eventually merged into all platforms? i thought you had off this week? ;) -mdw
This really belongs on the forum btw... but really what you describe isn't exactly the case. Right now we are just focusing on TinySC, but all the things we're doing for that will benefit all platforms. But as we're focusing on a Linux system certain things may not work right on Windows for example. All changes from 7.5-embedded will be merged back, but not for 7.5.0. This is because QA should spend most of their time on Touch and not on testing tons of SBS changes on all platforms.
Hurray!!! My #1 bug is finally getting fixed! Thanks Andy! I wish I didn't have to wait for 7.5-embedded to be merged into a normal 7.5.x release. Is there a patch I could apply to the normal sb server to test the fix, or is it too dependent on other changes which have gone into 7.5-embedded?
You could probably apply these patches to 7.5 trunk, but I would appreciate it if you just tested the embedded build. http://downloads.slimdevices.com/nightly/?ver=7.5-embedded
BTW this query is still the slowest one due to the number of joins that have to be made, but it should be better than it was. If anyone wants to look at optimizing it more please feel free. You can enable database.sql debugging to view the query that's being run.
I'll try to test this in the next couple of days. Thanks, Andy.
I gave this a try and, unfortunately, do not see any improvement. In 7.4.1, it took 18 seconds to select my "Rock" genre. In 7.5.0-embedded, it took 19 seconds (technically longer, but I think its fair to say it is relatively unchanged). Note that these times are improved from the 2 minutes it used to take as I upgraded my linux server a few months back. The new speedy cpu has helped a lot, but ~20 seconds to select a genre still makes browsing by genre unusable. Also note that browsing by genre from the web interface works fine (a second or two at the most to select a genre). Is there no way we can use the same query which is used by the web ui? I think this bug needs to be reopened again, unfortunately... Thanks, John
== Auto-comment from SVN commit #29836 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29836 == Bug 7992, rework the artists-in-genre query for much better performance when VA pref is on
Andy, that latest commit from Jan 18 fixes the problem. I am extremely happy to report that, at least for me, my #1 bug is now fixed. I'm so happy. Can I send you a bottle of wine or something? Thanks a million! Cheers, John
Great, thanks for testing!
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!