[to-do] have a look at the new Built-in Intent Library

[digiltd]

I know not technically an issue but might be worth sticking on the todo list.

Not sure if you have seen the new Built-in Intent Library that is in development, but it looks like it could drastically affect things (for the better). Have a look, it might be worth holding off the global search features for a little while.

https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/built-in-intent-ref/built-in-intent-library#music

It's more than a little annoying they are only available to US developers at the moment so i can't have a play.

On the surface they look very impressive and the days of creating custom slot data could be behind us.

[jingai]

Definitely will keep an eye on it.

[m0ngr31]

That's a good find. It's too bad they limit it to US for now though.

[jingai]

I've pretty much got generic/global playback done actually. The only real problem I've run into is it seems there's some other limit to the number of cumulative entries across slots used in one Intent. That is, the limit for any single slot appears to be 50,000 as Amazon states, but if you spread it out across multiple slots, it seems to be some number less than that. I haven't identified the actual cap, but I think it may be a bug in Amazon's UI. It seems to save the model just fine, but when I go to use it in this case, it says, "There is no Intent model for this skill."

I'm still debugging it, but with the holidays in the way, it's slowed my progress a little. I've trimmed the slots to get it to work for my own testing and it's working as intended for me, though. I'll push it to a branch soon for others to play with. I just would prefer not to release with caveats like, "If you have a huge library, cut some slots down until they all add up to less than N."

Two other things I can see people complaining about:

1. It's a bit slower if you don't specify the media type, and it seems for a lot of people the skill is already in general a lot slower round-trip than in my own set up,
2. Because it's searching literally everything without any context, people are going to complain that "Alexa's not hearing me right." In reality, Alexa does this even with the built-in music services for instance, but the issue is amplified when you throw movies, tv shows, etc into the mix.

Neither of the above is an actual "bug" though, as the answer is "specify the media type then." I figured I'd bring it up so we all know what's going on though.

But I do want to push ahead with it despite what Amazon might be working on here with the built-in Intent Library, and then just transition to this new stuff whenever it's ready (e.g., available at least in UK and US). Laying the foundation for how the requests should work is still a good thing to do now.

[digiltd]

Given the slot content lists are not a definitive list of potential matches, could we limit the amount of generated slot content so the examples it outputs are more representative of the users content? Perhaps start with a song title with the lowest word count and end with a song title with the highest word count?

Note that a custom slot type is not the equivalent of an enumeration. Values outside the list are still returned if recognized by the spoken language understanding system. Although input to a custom slot type is weighted towards the values in the list, it is not constrained to just the items on the list. Your code still needs to include validation and error checking when using slot values.

It appears to me that Song/Movie/Artist titles are so open ended and the unique methods used to spell (EMINƎM, Tinie Tempah (Tiny Temper), Tinchy Stryder, Will.I.Am, M!ssundaztood, Deadmau5) plus the existing issues caused by how numbers are used (UB40, U2, One Republic, Jackson 5, Soul II Soul) make this a very difficult task.

This is more or a question than a statement, but even if there was a slot generated from the Kodi library wouldn't there be a high chance it wouldn't be matched correctly? So is it easier on you and the skill to get it to filtering the Kodi Audio and Video libraries as soon as possible rather than starting with searching the 50,000 slots each time? (assuming if a slot doesn't match it would fall back to a Kodi search anyway)

Good luck.

[jingai]

It appears to me that Song/Movie/Artist titles are so open ended and the unique methods used to spell (EMINƎM, Tinie Tempah (Tiny Temper), Tinchy Stryder, Will.I.Am, M!ssundaztood, Deadmau5) plus the existing issues caused by how numbers are used (UB40, U2, One Republic, Jackson 5, Soul II Soul) make this a very difficult task.

Honestly, the fuzzy matching works pretty well even for the difficult artist/album/song titles in my own library. This isn't the big problem. The bigger "issue" (in quotes because it's just not really an "issue" even though users will perceive it as such) is that, without context, it's doing the fuzzy matching on the whole library. The likelihood it will match e.g., a movie, when you were trying to get a song -- especially for really short titles -- is relatively high.

I'm sure you've probably noticed, but Amazon's built-in stuff and the 'official' 3rd party skills that deal with media all suffer from this issue too. People complain about it there, and they'll complain about it here. But without context, it's just impossible to know. If it gets a match, it technically did the 'right thing'.

The answer of course is to tell users to specify the media type if the skill can't get it right without it, but I did want to comment here just so we're all aware of it.

I've thought pretty hard about how to make it more accurate, and the best way I've come up with is to collect all of the matches and at the end, choose the strongest match. So, if it finds a movie matched at 77%, a show matched at 76%, and a song matched at 80%, it'd pick the song. The problem with this is it means searching the entire library for every single request. This is slow, even on my set up where I'm hosting it locally.

Therefore.. I'm inclined to let it break out on the first >= 75% match and just deal with her getting it wrong occasionally. IMHO, it's better to just get the wrong thing, cancel it, and then re-request with the media type specified than to slow down all requests.

Opinions are welcome, though.

[digiltd]

Cool. I admire your determination :)

Has a global search been something that users have requested? I know I would rather add an extra syllable into the request for improved accuracy and potential speed bump.

[jingai]

A few have directly and more indirectly suggested that it'd be nice if it worked rather than failing outright.

But, more than that, it pisses off my wife and kids when it doesn't work ;)

[jingai]

Are these still English (US) only? I see that they're still Developer Preview, but for some reason I can't find the language restriction specifically now..

[digiltd]

Yup. It is pretty piss poor. Over five months since it was launched as a "developer preview". But looking at the docs, and Amazon's own tutorials, they talk about them as if they are production ready (I don't think they have changed/worked on them since the launch either).

Just one of several things that only the US is allowed to. Sigh

I started a post about it when it was first announced, adding to it as and when they anounce new features. https://forums.developer.amazon.com/questions/50740/there-is-a-growing-gap-between-what-a-us-dev-can-d.html

[jingai]

Honestly, I really do understand the difficulties between different languages.. but, English US can't be that different from English UK..

[digiltd]

I am beginning to think language has less to do with it and there is some other mysterious reason. The Thermostat Query for Smart Home Skills being US only has nothing to do with language.

(lifted from the linked post)

I always assumed it was to do with language and accent differences, and these differences required work to be done on the "core" voice recognition processing.

Currently the US, UK and DE can all use the Smart Home Skill Kit to set room/device temperatures directly and also increase/decrease room/device temperatures with the following two intents

SetTargetTemperatureRequest

“Alexa, set the room name to number degrees”
“Alexa, stelle Raumname auf Anzahl Grad”

DecrementTargetTemperatureRequest

“Alexa, decrease device name by number degrees”
“Alexa, reduziere Gerätename um Anzahl Grad”

Only US customers can query the current temperature and what it is currently set to:

GetTemperatureReadingRequest

“Alexa, what is the temperature of device name?”

GetTargetTemperatureRequest

“Alexa, what is the device name set to?"

Given words like "temperature" and "degrees" are already recognised correctly to set the temperature, there shouldn't be any additional recognition/language work required for the same words to be used to get the temperature.

Bizzare

[jingai]

One thought there is that they're depending on the manufacturer to implement it.

Honestly there's always something.. it'd be nice if they communicated with us about it.

[digiltd]

It could be something to do with the manufacturer... but thinking about it, I don't think so. Just like Custom Skills, anyone can make a Smart Home Skill whether it works or not. They are just being mean :) but yes, a little bit of communication would be nice. Sigh.

[digiltd]

hark!

Two years and three months after they were released to US developers (2016 ffs, just saying it makes it sound far in the past), the rest of the world can finally play with some of the intents from the Built-in Library. Not all, no that would be ridiculous, but at least the selection includes the music, TV and movie related ones.

https://developer.amazon.com/blogs/alexa/post/9714e051-689f-4caf-8b66-98451ecdcaaa/what-s-new-in-the-alexa-skills-kit-february-2019-release-roundup

Not sure if it is worth it, I am not even sure what benefits it actually brings, I know the skill works fine for me as I expect it does for others (and I never update my slot lists). But there it is. Enjoy 🎉