Bugzilla – Bug 7330
certain chunked queries never request the right parts to correctly complete the entire request
Last modified: 2009-09-08 09:29:05 UTC
If you step the BLOCK_SIZE in DB.lua down from 200 to 20, this exposes a particularly nasty problem with requesting the wrong chunks for certain requests and never filling the holes. example: Music Library->Genres->Rock (> 100 artists in my collection) first query artists 0 20 second query artists 100 20 third query artists 0 20 fourth query artists 100 20 etc. forever
is this the same as bug 7327?
the looping queries you see is what I tried to describe with my flipping display of the 21st element :)
*** Bug 7327 has been marked as a duplicate of this bug. ***
Created attachment 2993 [details] only add Favorites item to the end of the list please test
this bug is not the same as 7327. patch is applicable to that bug, not this one
I captured some debug from DB.lua that might gives some insight into the problem-- this is tested while using the top patch attached to this bug. DB.menuItems stores some information on which chunks have been already received, which SlimBrowser then uses to decide what needs to be requested to fill in the holes. For a query that is currently working, this is how the return values look like (block size is 20 for this test)-- 100134:28091 WARN (DB.lua:182) - self.count: 98| key: 0| cFrom: 1| cTo: 20 100134:28096 WARN (DB.lua:182) - self.count: 98| key: 4| cFrom: 81| cTo: 98 100134:28100 WARN (DB.lua:182) - self.count: 98| key: 1| cFrom: 21| cTo: 40 100134:28104 WARN (DB.lua:182) - self.count: 98| key: 2| cFrom: 41| cTo: 60 100134:28110 WARN (DB.lua:182) - self.count: 98| key: 3| cFrom: 61| cTo: 80 to interpret-- there are 98 items in the list. The first chunk is from 1 to 20. The next request is the last chunk, from 81 to 98. This is key 4 in the stored table. From there, requests for the chunks that fill keys 1, 2, and 3 patch the holes in the menu list of 98 items. For a query that exhibits this bug behavior (Library->Genre->any genre with more than 20 artists)-- 100204:58627 WARN (DB.lua:182) - self.count: 48| key: 0| cFrom: 1| cTo: 20 100205:59358 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 100206:60075 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 100206:60871 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 100207:61566 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 100208:62262 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 100208:62962 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 (etc.) in this case, the second request should have marked the key as 2 instead of 1, and instead of asking for 40 to 48, it asks for 39 to 46. There is still missing data, and the subsequent requests aren't asking for the right chunk (they keep asking for 39-46 instead of 21 to 39). I confirmed there are 46 artists in this Genre + 1 "Play All" + 1 "Various Artist" + 1 "Add to Favorites". By that, I'd expect a working second request to look not like this: 100205:59358 WARN (DB.lua:182) - self.count: 48| key: 1| cFrom: 39| cTo: 46 but like this: 100205:59358 WARN (DB.lua:182) - self.count: 49| key: 2| cFrom: 40| cTo: 49
Created attachment 2995 [details] Alternate patch This patch apperas to solve both this bug and bug 7327 at least for the artists query case.
Created attachment 2996 [details] updated patch for this bug that extends Andy's fix beyond artistsQuery Also -- encapsulates any _jiveAddToFavorites() call in an if ($menuMode) {} clause -- per recommendation from Andy, changes all 'offset' return values to the requested offset from the cli query
fixed in SC change 17725 on 7.0 branch
Great work! But I'm still sorry to spoil the party: songinfoQuery seems to be still broken. Going to Album->Song still causes the looping queries in some cases, in others I can't reach the end of the details list.
The reason for the looping is Jive expecting a chunked response, but we're returning _all_ data at once. While this clearly is broken, it doesn't matter in a normal environment, as we'll hardly ever have more than 200 song information lines for a single song.
One more, more important issue: if the number of items returned is exactly the number of items from the DB, a favorites item will be added, but lack of an item_loop Jive won't accept it as a valid response.
Created attachment 3002 [details] correctly add Favorites item if it's the only item in the last chunk - don't add Favorites if chunkCount is already reached - define item_loop & offset even if Favorites item is the only item in a chunk - potential fix for no. of songInfo items > chunk size I'm not sure about the ".. || start == 0" check in _jiveAddToFavorites: this would add this element whether it's the first or the last chunk? Doesn't make sense to me.
I test Michael's patch thusly: I have a genre that returns 20 items, including the extra items above and below the browse list. Set the BLOCK_SIZE to X and browse through menu (this was confirmed to be broken before the patch when BLOCK_SIZE == size of list) tested with X = 20, X = 19, X = 18, X = 10, X = 21 all of these worked without an issue. However, all songinfoQuery menus are broken (endless request loop, broken menu). Still some work to be done...
Created attachment 3005 [details] Keep Jive from requesting a last chunk if it already has all items Jive will make an extra request for the last chunk if count == chunk size, even though it already has all data. This patch fixes that.
Created attachment 3009 [details] michael's patch plus one line fix for when the comment item is suppressed
Jive patch checked in as r2063.
paired with Andy's jive checkin in comment #17, SC change 17731 should fully fix this issue.
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html