GitHub - kubycsolutions/new-sounds-on-demand, alpha 0.1.0 released

amazon-alexa
#1

If folks want to see the mess I’ve been making for the past few months, I’ve just posted the code onto GitHub. Should be publicly viewable.

NOT the cleanest thing I’ve written by a long shot – “whittled” from the Jovo podcast player example, while learning Alexa, Jovo, and Javascript simultaneously, so I’m sure it’s far from idiomatic for any of them. But it seems to be working, and it illustrates a somewhat richer set of interactions than the basic sample did. And I’ve tried to comment the less obvious parts of the code.

Now I need to get the Google version running, move the back-end off my own machine, do some of the other things enumerated in the app.js comments… and then maybe I’ll be ready to ask Amazon to add it to the skills library.

I haven’t yet opened an issues tracker for it, but comments, suggestions, questions, and (reasonable) complaints are welcome.

#2

I’m trying to get the Google side of this working now. I can get it to play the most recent episode, or the live stream, or a random episode.Sometimes it will accept an episode number But I’m not seeing Jovo display the incoming event JSON for Google events, which makes debugging hard… and it isn’t clear I’m getting events events for commands like next or previous at all, even if I prefix them with “Tell New Sounds On Demand to…”.

The Jovo sample/tutorial didn’t seem to do anything special for these, so I’m a bit confused – I would have expected a sample to show equivalent behavior

Any advice or clarification would be more than welcome!

#3

First off, congrats on shipping. Great to see the project open source.

Unfortunately, Google Assistant doesn’t support events like pause or stop, as far as I can remember. It does pause, but does it without sending a request to the Action.

#4

That does seem to be the case.

One non-obvious bit of behavior: If you want to be notified when the MP3 file ends, you need to use .ask() rather than .tell() in the Google code so the conversation stays active. (You did so in the sample, but I don’t remember this being called out as a potential pitfall. If it isn’t, it might be a good idea to add that. Someday, of course, it would be nice to wrap this all under a Jovo layer so we don’t need to code each platform explicitly.)

So for now, “Hey google, stop” will not set a bookmark but “Hey google, tell (my application) to stop” might…? Not optimal – I really want behavior to be more similar across the platforms – but at least it should run.

#5

In case anyone is interested: The Alexa version of this has been submitted to Amazon for approval as a public Skill. Toes crossed (because I can’t type with crossed fingers).

I’ve started getting active interest from the folks I’m doing this skunkwork project for, which is goodness. Helps that I’m giving them feedback when I find something odd in their database, so even if this fails to gain users they’ll have benefited from my efforts.

My code has evolved a lot since last October. It would benefit from a serious cleanup pass (too much copypasta, leftovers from experiments, placeholders and such) but it’s running pretty darned cleanly as a pair of AWS Lambdas. There are still a fair number of features I’ve deferred, but it’s time to get it out in front of Real Users and let them tell me what changes/improvements are most important to them.

#6

They’ve approved the skill. I need to do a bit more polishing on the cron task that updates my data (unclear if my issue is permissions or handling async javascript in a lambda), but once that’s done…

To clarify: The problem I’m having is that the Lambda is exiting before the got.get() HTTP request that pulls in the data has completed, despite it supposedly waiting on the code which made that call. No exception is seen, but I never see the printout after awaiting the HTTP response; instead I see the one after awaiting several layers of calls up. That would look like an exception thrown by got.get(), but that’s not what try/catch is reporting. My best guess is that there’s a missing await somewhere in the call chain – but then I can’t explain how it runs properly on my own machine. Saturating it with logging printouts hasn’t told me anything useful yet. Very frustrating.

The good news, such as it is, is that this is making me focus on more robust diagnostics (that I hope never to need again, of course)… and pushing me to get rid of the remaining Promise.then.catch instances in favor of async/await/catch (which really is easier to work with).

#7

This could be caused by an empty loop.

Add this to your handler method in index.ts

context.callbackWaitsForEmptyEventLoop = false;

Here’s a thread

#8

Not sure how turning off wait for empty loop would improve a situation of the code apparently not waiting for what should be a non-empty async…?

The problem seems to have been a combination of several. First, I needed more await statements to make sure the lambda’s code didn’t exit until all processing was finished – otherwise, unlike the node command on my own machine, it seemed to shut down when the index function exited. After fixing that so the code actually ran to completion, it exposed some edge cases which I’ve also fixed.

Theoretically, now that the lambdas are happy, I’m ready to publish. Except that as noted in https://stackoverflow.com/questions/71595626/updating-a-certified-but-not-yet-published-alexa-skill, I’m not sure how to either publish the certified version of the skill, or withdraw it and certify a new version. I must be missing something obvious, but I’m not seeing it. Sigh.

“Remember, if it was easy they wouldn’t need us.”