Detecting stalled audio stream in HtmlViewer

General
1

I’ve written a desktop media player app to play streaming audio from various online sources. Occasionally, the stream gets stalled and has to be restarted. I’ve looked at the various HtmlPlayer events and error codes, but haven’t been able to find anything that will flag a stalled stream. Does anyone know any way to detect when a stream is stalled?

I know that dedicated Internet radios such as those made by Grace, can detect a stalled stream and automatically reconnect. I don’t know how they do it. Maybe they monitor the decoded audio signal. If that’s the only way to detect a failed stream then is there any way to monitor the audio output of the HtmlViewer?

2

Method 1:

Method 2:

1 Like
3

Thanks Mike. Method 1 looks like it will be easiest to implement. However, looking at the HTMLMediaElement.currentTime documentation, I have a problem identifying the document element to apply this to. I don’t have an actual html document. I just load the stream directly into the html viewer like this:

var nextTrack as string = "http://liveradiocanada.cbc.ca/i/CBCR2_VCR@353638/master.m3u8"
htmlViewer1.LoadURL(nextTrack)

If I load the stream URL into Firefox and then try to use the developer tools to view the page source, the page source menu item is greyed out.

Is there a way to apply HTMLMediaElement.currentTime to this as is, or will I have to create a small wrapper html page to embed the stream URL in?

4

Do this - a little more work up front, in return for much more flexibility.

5

Okay, a small wrapper html page should be fairly simple. My next question is how do I get DesktopHTMLViewer.ExecuteJavaScript to return a value to the Xojo application?

I note that in the htmlMediaElement.currentTime docs, they give this example:

var video = document.createElement('video');
console.log(video.currentTime);

But I don’t know how I would retrieve the info from the console log.

6

MBS Blog - HTMLViewer JavaScript communication for Xojo is a good rundown (though not updated for 2021 R3 )

See also https://documentation.xojo.com/api/user_interface/desktop/desktophtmlviewer.html.JavaScriptRequest

7

I created a very simple html page, and while I was at it, I thought that I might as well include some javascript to periodically check the audio stream currentTime property and then set the page title to that value so that I could use the TitleChanged event hack to get the data back. Here is my html code:

<!DOCTYPE html>
<html><head><title>Player</title>
<script>
    function startPeriodic() {
      document.title='0.00000';
      var temp = setInterval(timeUpdate, 2000);
    }
    function timeUpdate(){
      CurTime = document.getElementById('myPlayer').currentTime;
      document.getElementById('playTime').innerHTML = 'Playtime: '+CurTime;
      document.title = CurTime;
    }
</script></head>
<body onload='startPeriodic()'>
  <audio id='myPlayer' controls autoplay
   src='https://ragss.ca:8030/a128'>
   Audio not supported</audio>
  <br><div id='playTime'>0000</div>
</body></html>

If I save this as an .html file and load it into Firefox, it works perfectly, but when I load it into the HtmlViewer, the javascripts won’t run. Am I doing something wrong, or is this standard behaviour for the HtmlViewer?

8

Since the internal javascript didn’t work, I added a Xojo timer as originally suggested, and put this in the timer action event handler:

HTMLViewer1.ExecuteJavaScript("document.title = document.getElementById('myPlayer').currentTime;")

This works fine. I now get the time back in the TitleChanged event. I’d still like to know why the internal Javascript won’t run though.

9

Well, for some reason, the internal javascript does run. I don’t know why it wouldn’t run earlier. I’m thinking maybe it was some difference between running it in the debugger, and as a built app. Anyway, the internal javascript is no longer necessary, and I’ve now stripped it out, leaving a much simpler piece of html.

I’m testing the timeout code now, and it seems to be working.
I’ve set an initial 30 second timeout value for the stream to start. If it doesn’t start in that time, then the page is reloaded. After the stream has started there’s a 10 second timeout. If the stream’s currentTime property fails to update for 10 seconds, then the page is reloaded.

10

What OS and Xojo versions?

11

I’m using Xojo 2018r3 and MacOS Sierra for this project. That’s the latest that I can run on this machine due to other old software that I need to keep running. I do have a license for the current Xojo version, but I have to boot from an external drive with a newer OS version in order to run it, which is a pain. So, I stick with the older Xojo version for my old projects if possible, and for backwards compatibility.

12

Re: TitleChanged - there are some potential bugs that can show up, that depend on the OS version / browser version and Xojo version. I think that it’s OK as long as you are using an older (WebKit 1) version of Xojo HTMLViewer, but can show up if you are using WebKit2 (WKWebView) either from MBS Plugins or the latest Xojo version.

13

Okay thanks. I’ll keep that in mind. The original bit of html that I tested in Firefox used a Javascript SetInterval() timer to regularly fire an update routine entirely in the html that set a text value within the page to the current time, so that it had nothing to do with setting the window title. That had worked in the browser but didn’t seem to work initially in the HTMLviewer control in the Xojo app. As I mentioned it did seem to start working later, for reasons I never figured out. Anyway, the title change hack is working fine for now. If/when I migrate the project to the current release of Xojo, I’ll have a look at using ExecuteJavaScriptSync so that I can get a return value directly.