Step 4, adding Alexa pause: It looks like the debugger doesn’t support that. It might be good to explicitly say so, and tell folks to test on the real hardware.
At some time I may need to take a look at the debugger source and see whether some of these features can be added…
Step 4, continued: After pasting in the app.js changes from the document, “Alexa, open my podcast player” replies "There was a problem with the requested skill's response." Console shows "Validation exception in class: Stream field cannot be null at field url". Best initial guess I’ve got is that the this.$user.isNew() test is failing because I’ve used previous versions of the Alexa app, and that I’d need to completely delete and recreate that to make this work.
Simpler solution might be to reorganize the test to explicitly check for the null:
episode = this.$user.$data.currentEpisode;
if (episode==null || !episode.startsWith("https:")) {
episode = 'https://traffic.libsyn.com/voicebot/Jan_Konig_on_the_Jovo_Open_Source_Framework_for_Voice_App_Development_-_Voicebot_Podcast_Ep_56.mp3';
this.$user.$data.currentEpisode = episode;
}
Note that I also changed the URI from http: as shown in the document to https:, since the Amazon APIs require that. That required adding a sanity-check test since a previous run had stored the “http:” URI; I could have manually reset that but this seemed a more robust fix.)
That’s bringing the system up OK. But testing on my Echo, if I try to either pause or stop and then resume or play, it is complaining "SpeechletResponse was null", and if I just re-Open the Alexa app it’s starting from offset zero again. So something about the offset store and recover in the document’s version of the code still isn’t right.
Trying to decide whether it’s worth my chasing down the error, or if I should just move on to the next section of the course.
One of the challenges of writing tutorials is always keeping them synchronized with working code as the latter continues to evolve…
=======================================================
Testing resume with the “production” (checked in) code, I’m still finding that the resume operation (play with offset) takes a surprisingly long time to get back to the offset point and start producing audio again. If I pause at offset 1104351 (1104 seconds, 18.4 minutes), then after saying “resume” and hearing the Echo acknowledge the request I get no audio for about 112 seconds (1.8 minutes). Admittedly that’s 10 times faster than listening through what I’ve already heard… but it’s MUCH slower than most other Alexa audio players. This strongly suggests that we’re failing to take advantage of APIs/caches/something which would allow better responsiveness. I haven’t worked directly with the Alexa yet (I was hoping Jovo would be a shortcut into that), so I don’t have any insights yet into exactly which of those is our mistake… but clearly we’re missing a bet. “If it happens, it must be possible.”
Another glitch: Having resumed, When I got to the end of an episode and it auto-advanced to the next, the checked in code started that at offset 1116811, and did so without a delay.
Yet when I paused and resumed, we hit the delay again.
So in addition to our apparently not clearing the offset when we change episodes, there seems to be some bit of state being stored somewhere that our resume didn’t handle but that advancing to the next episode did.
Very strange. And again: If it happens, it must be possible, and we’re doing something wrong in the example.
(A product tester walks into a bar and orders a beer. Orders one beer. Orders zero beers. Orders -1 beers. Orders an ostrich. Orders ostrich beer. Orders beer ostrich. Orders beer one. Orders a refill on the beer. Orders a refill on the ostrich. Orders a beer for the ostrich. Orders a beer for tomorrow. Orders a beer for yesterday. Orders low-cal beer. Orders low-cal whiskey. Orders beer, no, whiskey. Orders beer, no whiskey. Orders a boar, a bear, a bar, a bier, a peer, a peel, and a whisk broom. …)
========================================================
Sorry about the edits, but this system doesn’t permit more than three posts from one person in a row, no matter how far apart they are in time…
For what it’s worth: I’ve been making progress adapting this player to my needs:
All my episodes are datestamped. So for prototyping, rather than use an episodes.json file, I instead use earliest-episode’s date and current date, and navigate between episodes with some date math. A “does this URL actually exist” probe is called in a loop incrementing or decrementing the date (as appropriate) to skip missing episodes. I’ll be modifying the spoken dialog to select by date rather than select by episode number. Note that this approach avoids needing to update the episode list every time a new edition is released.
Eventually I will want selection by episode numbers or content too, and since those aren’t in synch with dates I’ll need to recreate a lookup table. But that’s being deferred to the second pass; right now I just want something that lets me navigate through history of the radio show this is supporting.
