GNOME Bugzilla – Bug 653120
Search action always gives NumberReturned 1
Last modified: 2012-01-29 11:33:43 UTC
With the following search action from tracker-miner-upnp-content-directory.vala at around line 200, NumberReturned is 1 when the starting index given is what should be one after the last item. Is this correct? _service.begin_action ("Search", index_cb, "ContainerID", typeof (string), cont.id, "SearchCriteria", typeof (string), "*", "Filter", typeof (string), "*", "StartingIndex", typeof (uint), cont.index, "RequestedCount", typeof (uint), ITEMS_PER_REQUEST, "SortCriteria", typeof (string), "", null); Apparently some UPnP servers return fewer than the requested number of items, though I assume always some, despite there being more items remaining that can be requested within the container in question. This means that subsequent requests need to be made to be sure that all items have been obtained. And then one needs to have some condition based on which one knows that there are no further items. An easy one would be if NumberReturned were 0, though this seems to have some other semantics perhaps, e.g. if TotalMatched is 0 because the CDS cannot calculate it, and if NumberReturned were 0 because there are no more items to provide at the requested starting index. Given TotalMatched = 0, if NumberReturned = 0 is reserved for error cases and so NumberReturned is set to 1 even if no items are returned, I suppose that is classifiable too.
Back-end in question was tracker, though I don't know yet if it's really a problem in there or in core.
(In reply to comment #0) > With the following search action from tracker-miner-upnp-content-directory.vala > at around line 200, NumberReturned is 1 when the starting index given is what > should be one after the last item. Is this correct? Looking at the Rygel sources, NumberReturned in both Browse and Search action responses is directly taken from the number of objects in the result (src/rygel/rygel-media-query-action.vala:77): this.number_returned = results.size; Are you sure this is not on client-side?
Created attachment 191136 [details] Screenshot of gupnp-universal-cp Here is a screenshot of gupnp-universal-cp demonstrating this bug to be invalid, AFAICT. Please do re-open if i misunderstood.
Yes, you misunderstood the bug. In the screenshot, try setting StartingIndex to 1449 (TotalMatch + 1). Then NumberReturned == 1 and indeed there's one container in the result
Created attachment 191138 [details] Screenshot of the issue
Can you retest with latest master? I fixed a similar issue recently, maybe we got this one as well.
Or current stable (0.12.1)
Still there...
I spotted the issue when using Mex [1] I think and I don't have that running right now so haven't got to testing it yet. Apologies, I will try to do so sometime soon. [1] http://media-explorer.github.com/
Still there.. meant "I can still reproduce it on master". Sorry :)
Seems a problem in SimpleSearch. MediaExport which does its own SQL searching is not affected, but Mediathek is.
Created attachment 206328 [details] [review] core: Return proper search result if Offset > All On a search request where Offset was larger than the totel number of matching items the search previously returned one item found and doesn't know how many there are. Now we correctly? return "no item found" + total matches.
Review of attachment 206328 [details] [review]: totel → total ::: src/rygel/rygel-searchable-container.vala @@ +111,3 @@ } + if (offset > result.size) { Probably needs >=, need to think about that.
Actually the combination offset > 0 && max_count == 0 seems to be broken. It always returns "1" then.
Created attachment 206338 [details] [review] core: Fix simple search for offset > 0 On a search request where offset was > 0 and limit was 0 due to limiting the result set to offset the result was always a set of one. Also total_matches was set to 0 in this case although we know the number of total matches since using a start offset doesn't limit the results.
Created attachment 206339 [details] [review] tests: Add test for simple_search
Created attachment 206340 [details] [review] core: Fix simple search for offset > 0 On a search request where offset was > 0 and limit was 0 due to limiting the result set to offset the result was always a set of one. Also total_matches was set to 0 in this case although we know the number of total matches since using a start offset doesn't limit the results.
Attachment 206339 [details] pushed as 8cbc983 - tests: Add test for simple_search Attachment 206340 [details] pushed as e8cdb95 - core: Fix simple search for offset > 0