Bugzilla – Bug 13233
Random Mix does not update
Last modified: 2011-01-14 13:15:48 UTC
Trying to start a 2nd random mix will cause WEB UI and Player UI to halt and display spiny Steps to repo Start a Random Mix with all (or 1) genres selected Change genres selection Start another Random Mix - Notice that the Web UI mouse cursor will display a spiny Random Mix should 'auto' stop when trying to start a new mix. If I "stop adding songs" via the Web UI, then start a new mix, it works just fine.
> Trying to start a 2nd random mix What's a 2nd mix? Another mix on the same device or a mix on another device? I'm using this all the time. Never seen this. > will cause WEB UI and Player UI to halt Player as in Boom or Jive? > Start a Random Mix with all (or 1) genres selected Song, Album, Artist mix? > Change genres selection > Start another Random Mix - Notice that the Web UI mouse cursor will > display a spiny So the important point is the change in genres? Sounds like another bug we had... can't find it right now. Log file?
Try just reproducing the steps. The idea is, if you dont like the first mix (in my case, it included the Holiday genre -- so I went in to uncheck that and restart the mix), you can't start a new one without clearing out the old one manually. You used to be able to.
log file?
Which logs would you like?
(In reply to comment #4) > Which logs would you like? server.log Andy - is this a dupe or the other bug described in bug 10391?
James - could you please provide the server.log when this happens? thanks!
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
SC 7.4 r28276 still has this issue. See attached log
Created attachment 5699 [details] Server Log Server log with randomplay set to debug
Hmm... while I've never been able to reproduce this, I think I've run into this issues a few days ago. Eventually I killed it, only to find out that MySQL was running at max. This thread seems to be up to something: http://forums.slimdevices.com/showthread.php?t=66669 "I put the debug logging on and this query seems to take forever in MySQL: SELECT COUNT( * ) FROM tracks me LEFT JOIN tracks_persistent persistent ON persistent.url = me.url WHERE ( ( audio = ? AND ( persistent.lastplayed IS NULL OR persistent.lastplayed < ? ) ) ): '1', '1251308488'" Andy - does this make sense to you?
OK that is a really slow query, the problem is the index on the url field. I'll see about improving it.
== Auto-comment from SVN commit #28296 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28296 == Bug 13233, comment out slow query for now
(In reply to comment #11) > OK that is a really slow query, the problem is the index on the url field. > I'll see about improving it. Why join on BLOB columns? URL could be tied back into tracks one time and all joins between tracks and tracks_persistent then could be done on a nicely indexed integer column. Then there's continued use of NULL values as data. If lastplayed were set to 0 instead of NULL then this: WHERE (me.audio = 1) AND ((tp.lastplayed IS NULL) OR (tp.lastplayed < 1251308488)) becomes WHERE (me.audio = 1) AND (tp.lastplayed < 1251308488) A quick test on my server has the first one at 610ms and the second at 16ms.
Well one reason is that the persistent data never gets deleted, so any track ID mapping would be invalidated by a rescan. I guess it could be rebuilt but just linking based on URL (or MB ID) seemed better.
7.4.x milestone is in the past
Probably invalid with various SQLite/DB changes.