On Fr, 2013-08-16 at 09:32 +0200, Juan A. Suarez Romero wrote: > On Thu, 2013-08-15 at 17:43 +0200, Jens Georg wrote: > > Hi, > > > > on servers that support "Search" the UPnP plugin uses it to do the > > browsing instead of doing "Browse". This is completely legitimate, > > however I spotted an "issue": > > > > The search uses "@parentID = someId" and then the search is executed on > > that container "someId" so this is a bit redundant - is this > > intentional? > > > > I think so. > > When you perform a search in a container, are all the subcontainers also > searched? Because we want to restrict the search only to one specific > container, and not for the children. That's why we added the @parentID > filter.
Ah yes, you're right of course. > > > BTW, the plug-in does not check whether the container is actually > > searchable and has matching <searchClass> entries; DLNA for example only > > requires the top-level container to be searchable if "Search" is > > supported. > > > > I think it is done in function gupnp_search_caps_cb. Though maybe it is > incorrect. No, that's just checking which attributes you can search for. In theory you have to check each container you want to search in whether it has "item@searchable=1" and check the item's <upnp:serarchClass> nodes. You can somewhat shortcut this on "real" DLNA servers and always search on "0" because if the server supports search "0" has to be searchable, the result should be the same. Though if you switch to dLeyna, I think it should take care of this _______________________________________________ grilo-list mailing list grilo-list@gnome.org https://mail.gnome.org/mailman/listinfo/grilo-list
