10-03-2016, 03:06 PM
(This post was last modified: 10-04-2016, 11:59 AM by Dean Roddey.)
For the most part you get to media by browsing for it within CQC. But, sometimes you may want to search for a particular piece of media. As is always the case within CQC, in order to access a given piece of media, you need the appropriate media cookie. That cookie is an id for that piece of media, which is handed out by a media repository. You can pass that cookie to a media renderer, which will use it to go back to the repository and get the information it needs to play the media. And of course you can use that cookie to get metadata info from the repository as well.
All standard CQC media repository drivers support a standard backdoor command that it uses to expose media searching. It uses the standard backdoor method that lets you query a text value from a driver, which looks like:
The parameters are:
The middle two are arbitrary and defined by each driver. For this particular query, the values are:
The search string has this format:
Everything after category name is optional, but you have to pass enough for the type of cookie you indicate you are searching for. So up to cat name if you want a category, up to title name if you want a title, and so forth. The values actually have to be quoted since it's a quoted comma list.
For most purposes you would do something like this:
So you want a movie, you want to get a title cookie, there has to be a category though it's not used if you are not searching for a category, so just use All Movies which is always valid, and then the title to search for. Or of course it could be for music, in which case more like:
If the requested cookie is found, then you can use it anywhere else you would use such a cookie. You can pass it to a renderer to be queued up, or use it in any action command that takes that kind of cookie. If you want a particular collection if a multi-collection title set, just add a 1 based number to it. The cookie is just a string of comma separated values, so add a comma and the collection number you want. So, if you get back a title cookie in LVar:SearchRes, you could do:
LocalVars::Append(LVar:SearchRes, ,1)
There's not an empty parameter there, there are just two parameters, the second of which is ,1. It's awkward showing actions like this if the parameter values have commas in them, since it's ambiguous where each parameter starts. That's why CQC tends to show them split out into separate lines.
Collections are only generally useful for music, but if it's a multi-disc title set (some repos provide that type of title level info), you can get to a specific disc in the same sort of way.
Anyway, give that a try. One way you might want to use it is for voice selection of media. So you can let the user request a title to play, and use the above to try to find it. It can be tricky because it has to be an exact match and the Echo doesn't always get it right, and punctuation could be an issue.
At some point here we'll add a smarter type of search, and add some specific action commands for that sort of thing, which will talk to the local client service instead of the media repository. That would be far more efficient. That's what the search commands on the Cover Art Browser does, for instance.
All standard CQC media repository drivers support a standard backdoor command that it uses to expose media searching. It uses the standard backdoor method that lets you query a text value from a driver, which looks like:
Code:
If Devices::QueryDrvText(mon, qtype, qdata , outputvar)
// A value was returned
EndIfThe parameters are:
- Moniker. The driver to query from
- Type. The type of data you want to get
- Data. The specific value of this type you want to get
- Variable. A variable to put the value into if one is returned
The middle two are arbitrary and defined by each driver. For this particular query, the values are:
- CookieLookup. Indicates you want to do a cookie lookup
- [searchstring] A string that defines what you want to find, the format of which is discussed next.
The search string has this format:
Code:
media type, cookie type, cat name[, title name, collection name, item name]Everything after category name is optional, but you have to pass enough for the type of cookie you indicate you are searching for. So up to cat name if you want a category, up to title name if you want a title, and so forth. The values actually have to be quoted since it's a quoted comma list.
For most purposes you would do something like this:
Code:
"Movie", "Title", "All Movies", "Batman Begins"So you want a movie, you want to get a title cookie, there has to be a category though it's not used if you are not searching for a category, so just use All Movies which is always valid, and then the title to search for. Or of course it could be for music, in which case more like:
Code:
"Music", "Title", "All Music", "Let it Be"If the requested cookie is found, then you can use it anywhere else you would use such a cookie. You can pass it to a renderer to be queued up, or use it in any action command that takes that kind of cookie. If you want a particular collection if a multi-collection title set, just add a 1 based number to it. The cookie is just a string of comma separated values, so add a comma and the collection number you want. So, if you get back a title cookie in LVar:SearchRes, you could do:
LocalVars::Append(LVar:SearchRes, ,1)
There's not an empty parameter there, there are just two parameters, the second of which is ,1. It's awkward showing actions like this if the parameter values have commas in them, since it's ambiguous where each parameter starts. That's why CQC tends to show them split out into separate lines.
Collections are only generally useful for music, but if it's a multi-disc title set (some repos provide that type of title level info), you can get to a specific disc in the same sort of way.
Anyway, give that a try. One way you might want to use it is for voice selection of media. So you can let the user request a title to play, and use the above to try to find it. It can be tricky because it has to be an exact match and the Echo doesn't always get it right, and punctuation could be an issue.
At some point here we'll add a smarter type of search, and add some specific action commands for that sort of thing, which will talk to the local client service instead of the media repository. That would be far more efficient. That's what the search commands on the Cover Art Browser does, for instance.
Dean Roddey
Explorans limites defectum
Explorans limites defectum
