Poll: Does 'Group compilation albums together' work for you?

[gharris999]

If you have 1). a SBC and 2). a genre in your library with more than 4000 tracks that includes Various Artists compilations and 3). you're using the 'Group compilation albums together' feature (or if you've had to turn it off because it doesn't work for you), please take this poll.

I'm trying to get a sense as to how many users are effected by bug 7992: http://bugs.slimdevices.com/show_bug.cgi?id=7992

Thanks.

[radish]

My Trance genre has almost 6000 tracks in it, including compilations and artist albums. I have Group Compilations switched on and the artist list comes up in maybe 2 seconds. The artist list itself only has 60 entries due to VA artists being excluded - it would probably be closer to 3k otherwise. Am I testing the right thing?

[Scardeville]

Just to be clear; infinite when the query is on the SBC, a couple of seconds in Squeezecenter or on the SB3.

[schiegl]

I won't vote because i miss one condition but i did the test nevertheless. My soundtrack genre has over 2000 tracks from 40 artists, the "various artists" alone contributes about 800 tracks. The test query on the SC and SBC take no longer than 3 seconds. Don't know if this helps...

kind regards,
Markus

[gharris999]

My Trance genre has almost 6000 tracks in it, including compilations and artist albums. I have Group Compilations switched on and the artist list comes up in maybe 2 seconds. The artist list itself only has 60 entries due to VA artists being excluded - it would probably be closer to 3k otherwise. Am I testing the right thing?

If you are testing on the SBC and you have 'Group compilation albums together' enabled, then, yes, you are testing the right thing. Can you describe your sever hardware?

There's a problem with the VA sql query that SqueezeCenter executes at the SBC's behest. Part of the query returns what is known as a "Cartesian result set", i.e. because of something like a circular reference in the joins, the query must search through many, many more rows of data than actually exist in the database. The problem is exponential, meaning that the more tracks you have, the bigger the problem. There seems to be a critical number of tracks involved here: fewer than a few thousand tracks and mysql and your hardware can handle it. More than a few thousand tracks and suddenly the query balloons and mysql must literally sift through millions and millions of records. With a lower-power server, the query takes longer than the SBC's communication time-out and the SBC looses connection with SqueezeCenter and has to be rebooted.

With a higher horsepower server, mysql successfully completes the query before the SBC times-out. But with my library, the wait times are still totally unacceptable.

AndyG fixed half of this problem last spring. Several of us woke up a couple of months ago to the fact that his fix didn't cover the 'Group Compilation Albums' instance. We've been trying to make the case since then that this bug deserves some more attention. If the number of users effected by the bug really is small, then it's hard to argue with the current plan, which is, essentially, to ignore the bug until the database rewrite for SC8 makes this a mute point.

[radish]

If you are testing on the SBC and you have 'Group compilation albums together' enabled, then, yes, you are testing the right thing.

Yes and yes.

Can you describe your sever hardware?

Athlon 64 LE-1600 w/ 2GB RAM. Running SC7.3 on Ubuntu 8.10 (headless). If cartesian products are the problem, then it's very possible that memory will play as big a part of the problem as CPU, because if you start paging in the middle of chomping those rows it'll make the problem exponentially worse. I'll run the test again tonight and keep an eye on memory usage.

[gharris999]

Radish: would you be willing to turn the mysql slow query option on, as described in the bug report? It would be interesting to know just how many records mysql is plowing through to sift those 6000 tracks.

[radish]

Sure - will report back.

[2eleven]

I've posted in other threads about this issue. I personally rank it as my #1 bug, as it eliminates my favorite way to browse for music (genre->artist->album). My library stats: 1713 albums with 25822 songs by 487 artists. Note that this issue only affects my largest genre - 'Rock' - which has 1441 albums with 18738 songs by 350 artists. It also only affects the controller - the web interface is fine (and by fine I mean it takes about 10 seconds to make the query, which certainly usable, but not snappy). On the controller, the query times out and the controller loses connection with squeezecenter and usually has to be rebooted. Meanwhile, any playing squeezebox or transporter will experience a buffer underrun and will quit playin. On the server, top shows mysqld sitting on top hogging 100% of the cpu for about 2 minutes in 7.2.1, or seemingly infinite with 7.3 (I've since downgraded back to 7.2.1). I suspect those folks with dual core CPUs would not experience the lost connections or stalled playback, as the other core would still be able to handle squeezecenter itself while the other core is tied up with mysqld.

Folks, if this bug affects you, I urge you to vote for it (not in this poll, but in bugzilla). That's where the importance of fixing it will be highlighted. I'm amazed a bug this severe has gone this long without a fix!

Cheers,

John

[radish]

Radish: would you be willing to turn the mysql slow query option on, as described in the bug report? It would be interesting to know just how many records mysql is plowing through to sift those 6000 tracks.

OK, so I tried it again watching CPU & memory usage - when hitting the biggest genre mysql spikes for around a second, then SC for less than that. No increase in memory usage by either SC or mysql.

I tried enabling the slow query logging but I couldn't get anything to appear in the logfile. Not sure what I was doing wrong (but in case it's important, the my.tt I found didn't have a mysql-safe section). I did enable SC logging for database stuff (as also mentioned in the bug ticket) but that didn't give any data, just the actual SQL. Happy to try any other tests, just let me know.