[CDS API] Search

Issue #607 resolved
Will Lunniss created an issue

It would be really good, especially for mobile devices, to be able to search for specific content to let the user home in on what they want.

For a start, maybe just adapt the normal browse request (see example below), something where the client can specify a root container (e.g. A for any audio, or V_M for just movies) and a title and get back a list of matching containers and items (where the containers/items id's of each object would be exactly the same as if the client had requested the contents of their parent container).

E.g. /cds/search/{profile_id}/{object_id}/{search_term}/{filter}/{start_index}/{requested_count}?authToken={token}

Substitute in {object_id} = "A_AA" and {search_term} = "Muse" to match all containers/items that have Muse in their title and are in or below the container A_AA.

The client could then navigate into containers like normal using browse, or initiate playback of items. In the example above, the client would used the returned container id to browse the album artist Muse.

Comments (10)

  1. Petr Nejedly repo owner

    that is interesting and useful. DLNA itself supports search method where you can search based on the item's properties, incl. class. If I implement this it should be share the same core. So we could search for the class (audio,image,video) + other parameters, like artist name, item title, etc.

    The CDS search could be simplified to only search for item title + text (which would look through all item fields). How does that sound?

  2. Will Lunniss reporter

    That sounds good. I suggested adapting the browse request as a way to implement it quickly, but if DLNA support search then yes you might as well implement it for both at the same time.

    I want it to be as simple as posible for the user so that they just type and press enter and any extra infor is obtained from where they are, so if they are sat in the audio view, just list audio related content, etc. Searching by item title (where item is an item or container) would work well. E.g. the user might type in an artist, an album name, a movie name, a tv series, a track or a video and all of these sorts of queries should return sensible results which the client could the group and present.

  3. Petr Nejedly repo owner

    Started looking at this now. It seems to be quite difficult the way you described it, especially two aspects: 1. searching within any arbitrary container (and for items only included in that container and at any depth within it) 2. keeping the IDs the same as when using Browse() - one item is present many times in the library (in different containers), with different IDs

    So my current thinking is to go as simple as possible, but still useful. I suggest it only supports the root containers (A, V, I), and maybe 0. Thus searching for audio, video, image types (and maybe anything). The search would generate a collection of objects (items + containers) with the term in its title, which would belong to a hidden virtual container (like search results), so the search would be like a filtered browse view on this eat-all container.

    So the resource could look like:

    /cds/search/{profile_id}/AUDIO/guns+n+roses/all/{start_index}/{requested_count}?authToken={token}

    Initially this would only work for titles and not all the other metadata fields, like artist, description, genre, etc. Also, currently I'm not sure how to do some sort of relevance ordering, will look into that.

    How does that sound? Will this do or are there some things missing you'll need?

  4. Will Lunniss reporter
    1. searching within any arbitrary container (and for items only included in that container and at any depth within it)

    Would have been nice but is fine not to have, especially for the first few versions. I would personally just use A, V, I and not 0.

    1. keeping the IDs the same as when using Browse() - one item is present many times in the library (in different containers), with different IDs

    I don't mind about the item's IDs, but I was interested in the container IDs for the search results being the same. E.g. search for guns+n+roses and you get three results, guns n roses artists container, guns n roses album artist container and guns n roses folder container, and maybe a stray track with guns n roses in the title. If each of those containers have the same ID as they do in their respective places, then that would be perfect.

    Is it possible to ensure the container IDs will match?

  5. Petr Nejedly repo owner

    It would be quite hard, I think, as the ids are built as you go deeper in the browse hierarchy. My initial thought was to have a new container for each media type with all the searchable items there in a flat hierarchy. Basically a view on list of items and folders. Then search among those and show the results. I would have to decide what metadata to use for searching and displaying these itrms, which will be pain too. Will have to look at the code a bit more.

  6. Petr Nejedly repo owner

    Actually, I might just use Lucene and store the object id's somehow. The search results would then return only stripped down items/containers (eg. no number of items for folders, not much technical metadata), so to get some more details about the items, you'll have to call browse() on that object id.

    In this case we should be able to search through different fields (eg album, artist, producer) and return them sorted by relevance as well.

  7. Will Lunniss reporter

    In terms of containers, that sounds ideal. With items, would there be enough details to initiate playback?

  8. Log in to comment