Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do I have {title} (artist/album/movie/show)? #65

Closed
jingai opened this issue Nov 16, 2016 · 16 comments
Closed

Do I have {title} (artist/album/movie/show)? #65

jingai opened this issue Nov 16, 2016 · 16 comments

Comments

@jingai
Copy link
Collaborator

jingai commented Nov 16, 2016

Debating if this should be separate from the DoSearch intent or not. I don't really have a preference one way or the other, so I figured I'd make this an Issue for people to discuss it.

My gut is telling me we should have a generic alexa_search() method that searches all content in some reasonable order (e.g., Artists -> Albums -> Songs -> Movies -> Shows -> Episodes).

It would then be nice if everything just pointed to alexa_search(), but that would obviously slow things down, so we need to think this through.

I suggest that this particular Issue be the fulcrum for that change.

@jingai
Copy link
Collaborator Author

jingai commented Nov 16, 2016

The most obvious optimization would be if we get a slot match, we prioritize that media type first.

@digiltd
Copy link
Contributor

digiltd commented Nov 16, 2016

I think some separation is needed, or at least is thought about when adding intents.

For example I don't use Kodi for music at all but I do use video playlists (smart playlists to play random episodes of cartoons/sitcoms etc). The current intents related to playlists only handle music playlists. I have added a WatchVideoPlaylist to my Skill install and a new slot to the slot generator which works fine, but haven't submitted a PR yet as I was also thinking about requiring specification for any playlist related intent.

Here are the current utterances for playlists

ListenToPlaylist listen to playlist {Playlist}
ListenToPlaylist listen to {Playlist} playlist
ListenToPlaylist play playlist {Playlist}
ListenToPlaylist play {Playlist} playlist
ListenToPlaylist shuffle playlist {Playlist}
ListenToPlaylist shuffle {Playlist} playlist

"listen to" works fine as would "watch" be for video playlists, but "play" and "shuffle" are too ambiguous.

I would rather we required the user to clarify the type rather than use global search.

@jingai
Copy link
Collaborator Author

jingai commented Nov 16, 2016

I'm not saying I want to (at least now -- I just wanted to experiment with it later) remove the separation. I'm saying if it's specified in a generic way (play and shuffle), it could perform a global search to try to do the right thing. Like Alexa does for built-in stuff.

My question in this Issue is: should "Do I have X?" be part of the DoSearch intent, or should it be a separate intent where Alexa just responds with "yes" or "no"?

If you've never tried it, do, "Alexa, ask Kodi to search for [movie/whatever]". It pops up the global search script with the media that matches what it heard. To me, this suffices as the response for, "Alexa, ask Kodi if I have [movie]", but others might want a simple yes/no response.. not sure.

For a yes/no response, there would be a bit more logic involved since it can match more than one. We can base it on the first result, but probably should speak the media title back so the user can confirm if that's what they asked for.

@jingai
Copy link
Collaborator Author

jingai commented Nov 17, 2016

If I go the route of letting the current DoSearch intent handle this functionality, I'll likely want to also fix it so it searches all media instead of just searching on the slot values as it is currently.

This means implementing the foundation for a global search that would pave the way for generic "play foo" and "shuffle foo" commands.

@digiltd, since it would be pretty easy at that point to extend it, would you be entirely opposed to "play" and "shuffle" commands that lack qualifiers behaving this way?

That is to say.. I wouldn't remove the current "play the movie X" etc, but "play X" would now work and would do a global search, since the skill doesn't know what kind of media the user is requesting.

This seems the right thing to do in the end anyway, since almost everyone I introduce to this skill in our home always tries stuff like "alexa, tell Kodi to play [myfavoritemovie]," like it works with Prime music, etc. This is actually why the defaults are currently for music. I'd rather that not be the case, so I think this is the way to go without flat-out removing that capability for music.

@digiltd
Copy link
Contributor

digiltd commented Nov 22, 2016

Sorry been a bit out of the loop recently. I worry a bit about performance when searching all media with fuzzy searching. Looping through every episode of every tv show starting from S01E01 each time could take quite a while.

But happy to see how it goes and tackle that issue if it becomes a problem.

Is it an option to have Alexa ask for clarification? e.g. "alexa, tell Kodi to play My Fare Lady" could mean the Simpsons episode, the movie, or one of many albums. Before she discovers this for herself she asks "shall I search in your movies, tv episodes, albums or everything?"

@m0ngr31
Copy link
Owner

m0ngr31 commented Nov 22, 2016

There is a way to make Alexa ask follow up questions, but it hasn't been implemented in the skill yet.

There is already a search intent that just uses the Kodi search function and displays on your TV. I'm guessing this request is to do a search and then allow them to play whatever was found?

@jingai
Copy link
Collaborator Author

jingai commented Nov 22, 2016

Sorry been a bit out of the loop recently. I worry a bit about performance when searching all media with fuzzy searching. Looping through every episode of every tv show starting from S01E01 each time could take quite a while.

It will only do that if you don't specify the media type in your request. For example, if you say "Alexa, ask Kodi to play the movie The Big Lebowski" it will not search through other media types. But if you just say, "Alexa, ask Kodi to play The Big Lebowski" it will search all media in some determined order.

Is it an option to have Alexa ask for clarification? e.g. "alexa, tell Kodi to play My Fare Lady" could mean the Simpsons episode, the movie, or one of many albums. Before she discovers this for herself she asks "shall I search in your movies, tv episodes, albums or everything?"

Yes, if we keep the session open. I intend to add support for sessions, but haven't gotten there yet.

@jingai
Copy link
Collaborator Author

jingai commented Nov 22, 2016

There is already a search intent that just uses the Kodi search function and displays on your TV. I'm guessing this request is to do a search and then allow them to play whatever was found?

If by "this request" you're referring to the original Issue here, then no, this is just to answer the question, "Alexa, ask Kodi if I have X?" The question was whether or not people felt that the current DoSearch intent satisfied this command, or if a "yes/no" response would be preferable.

The other part of this was talking about making the generic "play" and "shuffle" commands (without media type qualifiers) use the search function to find the media to play. It's only somewhat related to this Issue, though. I had intended to open another Issue (and begin work on it) after we decided what we wanted to do here.

@m0ngr31
Copy link
Owner

m0ngr31 commented Nov 22, 2016

Ahh okay, I see now. I think having a voice confirmation that something exists would be great. You might not have your TV on at the time or something. And being able to play something that you searched for without getting your remote is another win.

Going forward, we'll need to add the functionality to keep the session open and ask clarifying questions. For example, if you are searching for Frequency and it doesn't know whether to play the Movie, or the newest episode of the TV show

@jingai
Copy link
Collaborator Author

jingai commented Nov 23, 2016

Ahh okay, I see now. I think having a voice confirmation that something exists would be great. You might not have your TV on at the time or something.

Ok, good, that at least gives me some direction on how to implement this particular feature. I'll go for a 'yes/no' voice response.

And being able to play something that you searched for without getting your remote is another win.

Yep, and I aim to get there. Just doing this in small steps to get the design ironed out first.

Going forward, we'll need to add the functionality to keep the session open and ask clarifying questions. For example, if you are searching for Frequency and it doesn't know whether to play the Movie, or the newest episode of the TV show

Agreed. That's kind of why it came up, as I'd start there if we decided to go that route. If no one was interested in generic searches and a simple 'yes/no' response for this question, I was going to just push this feature out first by using the existing DoSearch intent.

But if we're in agreement that we want global search for all media if no type specified, and voice response with confirmation of media found, then I will proceed in this order:

  1. Implement generic search method,
  2. add session support to the skill,
  3. add confirmation of media found in search via voice response.

For 1, I haven't looked at the Global Search script enough yet to know how much I can interface with it via JSON. If it turns out I need to do fuzzy matches across the whole library (like what we're doing now, but for everything), I'll need a priority order. Is this reasonable: Artists -> Albums -> Songs -> Movies -> Shows -> Episodes ?

For 3, I'll have her respond with something like, "I've found the following shows: ..., and the movies ...., and the ...." If only 1 solid match is found, she will respond with "yes/no" if the user just asked if it exists, or play it if they asked for that.

If the user specifies the media type in their request, it will all work exactly as it does now.

We can extend this further after the first 3 goals, but we need a foundation first.

Sound reasonable?

@m0ngr31
Copy link
Owner

m0ngr31 commented Dec 22, 2016

Sounds perfect.

@jingai jingai self-assigned this Mar 28, 2017
@jingai
Copy link
Collaborator Author

jingai commented Apr 14, 2017

First crack at a generic play/deep search functionality is over at https://github.com/jingai/kodi-alexa/tree/deep_search

@jingai
Copy link
Collaborator Author

jingai commented Apr 15, 2017

I'm inclined to say the deep search code handles this. It's just as many steps to just try to play the media and say "stop" as it is to say, "do I have this thing?" and then "play".

So unless there are objections, I'll close this after #146 is merged.

@jingai
Copy link
Collaborator Author

jingai commented Apr 27, 2017

What I've essentially decided on (and implemented) is three basic layers:

  1. "play foo" -- searches through the entire library for the item requested,
  2. "watch foo" -- searches the entire video library,
    2a. "listen to foo" -- searches the entire audio library,
  3. "play movie/season/episode/artist/song/album/etc foo" -- searches the specified library section.

The idea is that most of the time, the user would be able to generically say just, "play foo," but if that fails, they could progressively drill deeper. For example,

"Alexa, ask Kodi to play DifficultMovieTitle" -- "Could not find"
"Alexa, ask Kodi to watch DifficultMovieTitle" -- "Could not find"
"Alexa, ask Kodi to play/watch the movie DifficultMovieTitle" -- "Playing movie DifficultMovieTitle"

@jingai
Copy link
Collaborator Author

jingai commented Apr 30, 2017

It would be nice if the generic play intent did report all of the matched media (if it found more than one) and ask for which to play, but this would require searching the entire library every time. At the moment, this is simply too slow.

If we ever speed up library searches, we can revisit this issue and continue it.

My initial thoughts for speeding up library searches would be either through caching the library skill-side, or moving the fuzzy matching code entirely to a Kodi addon.

If we go the addon route, we could probably satisfy #104 and/or #117 with it, too.

@jingai jingai removed their assignment May 26, 2017
@jingai
Copy link
Collaborator Author

jingai commented May 27, 2017

I honestly think 'drilling down by trying to play in progressively more specific ways' is the way to go here.

Going to close this for now.

@jingai jingai closed this as completed May 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants