View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0010420 | MMA | UPnP / Casting | public | 2013-01-16 17:07 | 2015-02-09 20:27 |
Reporter | rusty | Assigned To | |||
Priority | urgent | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.0.1 | ||||
Target Version | 1.1.1 | Fixed in Version | 1.1.0 | ||
Summary | 0010420: If DLNA server is in view, 'Search' doesn't search it | ||||
Description | If the user is using the DLNA function, and clicks 'Search' to search the server, MM searches the local library instead. Note: The implementation could be limited to searching whatever content is currently in view. i.e. when UPnP view is active, then MMA should show Search in current view instead of Search in library. | ||||
Tags | No tags attached. | ||||
Fixed in build | 387 | ||||
related to | 0010645 | closed | martin | MMA | If UPnP Server is being browsed 'shuffle all' doesn't work |
related to | 0012563 | closed | Ludek | MMW v4 | UPnP Search returns partial results |
related to | 0011737 | closed | martin | MMA | Search: DLNA Search do not work |
related to | 0012562 | resolved | marek | MMA | UPnP Search yields partial results |
child of | 0010228 | resolved | jiri | MMA | No search Indicator |
|
Currently Search in MMA works on the whole local Library, regardless of the view - this could be discussed, but it makes sense to me. As for usage in UPnP - since search is rather limited, it would have to be used for the current view only (as suggested), but I'm not sure whether it's really useful. For that reason, I'd defer this one until we have a better UPnP scanning implemented and so we could offer an instant search of a remote server (MMW). |
|
It could work similarly to Bubble UPnP, which caches the UPnP server metadata locally. Setting target post 1.0.1. |
|
Bubble UPnP uses UPnP search capability. i.e. it sends search action to server and server returns requested files. The server needs to be search capable. MMW 4.1 supports search, but MMW 4.0 doesn't. |
|
So how about: - If MMA detects that the UPnP server supports search --> it searches the server (e.g. 'Search server' instead of 'Search library') |
|
Ok, let's try this. |
|
Increasing priority, since it probably is rather easy to implement. |
|
This should be fixed in MMA since UPnP Search was implemented in MMW 4.1.5. |
|
Fixed in build 387 |
|
Tested 387 and this is partially working except that: 1) Videos/Movies aren't found 2) The search functionality doesn't always yield expected results in the same manner as described at 0009779 |
|
2) I know, I have implemented just basic search functionality for now (because it uses completely different UI than the library search) |
|
I have tested it only with MediaMonkey server but it looks like it doesn't support more complex queries. I.e. I am not able to request music and video at once. For the same reason, search is done only on titles. I will try other server and contact Ludek. In build 388: - artowrks of albums is shown in Albums tab - music track overlaying icon is shown in Tracks tab - two clicks on same tab caused disappearing of content |
|
Verified current functionality in build 390. btw, if videos can't be found, why bother with the music icon overlay? Or is that in preparation for a fix to return videos on the server side? |
|
Following queries fails with MMW upnp server: 1. (upnp:class derivedfrom "object.item.audioItem") and (dc:title contains "foo" or dc:creator contains "foo") It returns only items that contain foo in title. It doesn't return items with foo in creator field. 2. (upnp:class derivedfrom "object.item.audioItem") and (dc:title contains "foo" or dc:creator contains "foo" or upnp:artist contains "foo") It returns only items that contain foo in artist field. Items with foo in title are ignored. 3. (upnp:class derivedfrom "object.item.videoItem" or upnp:class derivedfrom "object.item.audioItem") and (dc:title contains "foo" or dc:creator contains "foo") No items are returned. It should return both audio and video items. |
|
Icon overlay was temporarily removed in build 392. |
|
Tagging this as resolved in 1.1.0. Remaining issues are tracked at: 0012562 (MMA) 0012563 (MMW) |
|
Verified 392. |