[jingai]

In those cases when she plays bonnie tyler instead of boney m. the app also tells me bonnie tyler. That's what I meant. She "decides" herself.
When using play she (in this case) can't match anything and gives the heard string to the skill. And then the skill tries to match the right thing. And in these cases one can also see that Alexa actually understood me right. The app history tells boney m. (even with the dot after the m) and the skill log does, too.
But going through the cards is a good advice. I'm gonna do that more often now.

There are many layers involved here, and maybe it'd be easiest if I tried to explain the path:

1) Transcription. Alexa first tries to transcribe what you said, just outputting a text string. When we (the devs) ask you, "What did Alexa hear?" this is what we're referring to. You can see how she transcribed it by going to the Alexa App > Settings > History. If at this point, she heard "bonnie tyler," then she simply misunderstood you, but there is nothing we (the skill developers) can do about it. From our skill's perspective, playing "bonnie tyler" would be the correct thing to do because that's what it was instructed (by Alexa, not you) to do.

2) Action mapping. Alexa then tries to determine where to send your phrase for further processing. In our case, she sees a fragment that looks something like, "tell kodi to". She then knows to send the phrase to our skill's interaction model . Note the important distinction here -- we are not yet at the skill's main code, which resides on the skill server.

3) Utterance/Intent mapping. Within the interaction model, she tries to determine what your 'Intent' was by matching against the example Utterances in the skill's model. Note that this is not just a direct, 1:1 match -- she simply treats the phrases in the model as examples and picks the Intent that most closely matches.

4) Slot matching. If the example utterance she chose contains one or more Slot references, she tries to replace them with strings from items within the referenced Slots. If the referenced Slot contains too few items to be considered "generic," she will simply look for the best match and pass it along to the skill server, but if nothing matches at all, she passes None. If the Slot is "generic," she will do the above, but instead of passing None, she will pass the original transcribed text instead. Note: I don't have proof of this, but in my experience, the requirement for the first kind of match is more lenient than the second. Meaning, she is more likely to pop out "something" from the first, even if it's not very close at all, rather than just failing (outputting None).

5) Processing the Intent. Alexa sends a JSON object to the skill server that instructs us how to handle the request. We are now in the main skill code. First, the skill matches the Intent and extracts the Slot references, and passes these to the appropriate Intent handler. If your request is to play media, it requests the list of media of that type(s) from Kodi, and tries first to do a direct comparison of the transcribed text against the list from the library. If this fails, we do a second pass with a fuzzy match, succeeding if the match is >= 75% 'alike'.

The important takeaway here is that up until step 5, we're not yet even in the skill's code. It's true that the interaction model is "part" of our code, and there are ways that we can break this part, but in your case, this isn't likely what is happening.

To diagnose problems with matching, you need to look in different places depending on where the failure occurred:

1) Transcription. Look in the Alexa App under Settings > History and see what she actually heard you say. If it is nothing like what you asked for, there is nothing we (the skill developers) can do in the skill to correct this. The best you can do is try to speak more clearly; use the voice training function in the Alexa App; or provide feedback on the Card that was produced ("No, she did not hear me correctly"). On that last point, it additionally helps to "reward" her with a "Yes, she heard me correctly" when she does do the right thing.

2) Action mapping. If she decides to send your request to something other than the Kodi-Alexa interaction model, there is again nothing we can do about this.

3) Utterance/Intent mapping. If this goes wrong, she will instruct our skill to do something other than what you intended. To check this, you can look at the logs on the skill server -- we print a bit about the incoming request there. As for correcting the problem, it's probable that you just tried to request an Intent in such a way that we didn't consider. This can possibly be fixed by adding more example utterances to catch the way that you said it, but it should be noted that we have to take great care here to not introduce conflicts with other requests. A lot of our requests are very, very similar, so this is delicate to balance.

4) Slot matching. You can see this in the skill server's logs. There are some limitations here that we can't really overcome. First, we depend on the transcription to be reasonably close to the title of the library item in Kodi (e.g., "bat out of hell 2" vs "bat out of hell 2 back into hell"). Second, if she simply heard the wrong thing entirely, the skill will still (correctly) try to do what it was told. And finally, our fuzzy matcher is not content-aware; that is, it's only trying match the two strings together. This could be better if we had access to a database that could give us alternative strings to match with, but we don't have that (yet, hopefully). For example, the skill has know way of knowing that, "tupac" or "too pack," as Alexa might hear it, can also be "2pac".

5) Processing the Intent. Any errors that occur here will be visible in the skill's server logs, and your best bet is to post them here or PM us.

@jingai, so is there no way to do anything about it? Perhaps by adding more samples to the slots or something else? Just want to know if I can do something to help (I guess others are going to run into this problem, too).

At this point, we pretty much depend on the slots being 'generic,' so they should have >= ~200 items. The exact number is not disclosed by Amazon, unfortunately. We chose 300 in the slot generator to provide some pad.

But, if you don't have enough in your library to populate a slot to the point where it becomes 'generic,' it means we really purely on the direct matching in the interaction model against the slot items provided there. No fuzzy matching (by our skill code) will occur.

In order for us to (potentially) provide help, we (the skill devs) would need to first see the exact, transcribed text that Alexa heard. Second, we'd need to know what Alexa passed to the skill server (in the skill server logs, you'll see something like, "Trying to match: foo"). Finally, we'd need to see what the skill chose to play instead -- if anything.

This boils down to:

1) Send us the transcribed text from the Alexa App,
2) Send us the skill server's log from the time pertaining to this request.

But just to show how far this goes. The problem seems to exist for all slots. That's why I actually can't use something like "play album from artist". Some example: "Alexa, ask kodi to play album dopamin by böhse onkelz". An error occurs because she matches böhse onkelz but not an album called "do or die" by böhse onkelz. When trying to play the album "Schwarz" she tries "Schlachtenlärm" by another artist. And so on. She'd rather take something from the samples even if it's not even close to similar to what I said than passing the string to the skill. That happens for movies, too.

If the slot isn't 'generic,' she's more lenient with the choice. She "tries harder" to match with one of the slot items she already knows about.

If the skill could fuzzy match, you'd get better results. But as I described above, it still isn't perfect and won't be unless we get access to a database that can provide us with a list of alternate titles.

If I only say "spiel das album schwarz" without an artist, she chooses the album swagger. If I try the same sentence on the testing platform it succeeds but the log say "searching for album schwartz" with a "t" so the fuzzy matching is needed. Schwarz without the "t" as written in the test would be a simple match.
Although theres this different behavior between the written test and my spoken words it can't be about my pronounciation or something because if I just say "Alexa was ist schwarz" (what is black) she gives me an answer and the app tells me that she understood "was ist schwarz".

It still can be about your pronunciation (computers don't 'hear' like we do), but also about context. The interaction model for the skill provides her with more context, so she weighs what you said with schwartz more heavily here due to it.

The bottom-line is.. all of this is a lot more complex than people think. There's a lot that goes on before she answers your request

And one more thing The umlaut problem is solved. But we do have another special character in german, the "ß". And I do again get the UnicodeEncodeError in the log when trying to call something including a "ß". And this can happen pretty often because the character is used in words like weiß (white) or daß (that).

Thanks for bringing that to my attention. I'm working right now on cleaning up the unicode handling in the skill. I'll make sure to test this.

edit: It would help if you could post the exact phrase you used so I can try something similar here. A log showing the error would also be very helpful.