Bug 17837 - Browse Music folder fails if a file of unwanted/invalid type is in a folder
: Browse Music folder fails if a file of unwanted/invalid type is in a folder
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: CLI
: 7.7.1
: PC Other
: P2 normal (vote)
: 7.7.2
Assigned To: Michael Herger
: onebrowser
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-23 07:22 UTC by Michael Herger
Modified: 2012-02-17 11:57 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
Do not only process items $start..$end, but all of them, in case we have to skip one of them (1007 bytes, patch)
2011-12-23 07:46 UTC, Michael Herger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Herger 2011-12-23 07:22:44 UTC
If there's an invalid file (eg. a Windows shortcut to an unreachable target) or a file of unwanted type (eg. image instead of music) in a music folder, subsequent files and folders are not handled correctly. This probably only happens to BrowseLibrary, as it uses the menu item's index ("0.3.1") to build the range parameters for the mediafolder query. 

The mediafolder query's result would only return a filtered list of items. But BrowseLibrary would request 1 item only to browse a sub-folder. If eg. the first item in the list had been skipped (wrong file type), then the first item returned would effectively be the second item in that folder. But as BrowseLibrary would request 

musicfolder 0 1 folder_id:99

...and that first item is being skipped, the result might be empty or unexpected.

We need to fix the mediafolder query to take skipped items into account.
Comment 1 Michael Herger 2011-12-23 07:46:39 UTC
Created attachment 7590 [details]
Do not only process items $start..$end, but all of them, in case we have to skip one of them

This seems rather inefficient, in particular for long lists where chunks $start >> 0. But I don't see a way to make sure our offset is correct if we have to skip an item.
Comment 2 Alan Young 2012-01-01 23:50:23 UTC
I agree that it is a little inefficient but probably not too bad, given that support for BMF is second-order in any case. Also the actual scan will likely be cached between calls.

It is essential that the 'count' result from the query is correct and consistent. That is not the case with the current code (before your patch). Other, downstream code relies on this consistency.

A second option would be to just let the code return type=unknown results rather than skipping unwanted entries. Otherwise you patch would be fine.
Comment 3 Michael Herger 2012-01-30 01:42:30 UTC
Fixed in r33774
Comment 4 Michael Herger 2012-01-30 05:06:43 UTC
just testing...
Comment 5 SVN Bot 2012-01-30 05:07:02 UTC
 == Auto-comment from SVN commit #33775 to the slim repo by mherger ==
 == http://svn.slimdevices.com/slim?view=revision&revision=33775 ==

Fixed Bug: 17837
Description: test check in
Comment 6 SVN Bot 2012-02-03 01:05:22 UTC
 == Auto-comment from SVN commit #33808 to the slim repo by mherger ==
 == http://svn.slimdevices.com/slim?view=revision&revision=33808 ==

Bug: 17837
Description: fix object assignment
Comment 7 Mike Walsh 2012-02-17 11:57:30 UTC
how was it possible to fix this bug without fixing this one too:

bug 17881

?