I built a simple streaming music player that uses the HtmlViewer to load the music stream. This has been working just fine for several years. However, a few days ago, one of the streams stopped working. It works fine if I load the stream link in any web browser, but not in the HtmlViewer. I’m trying to figure out what the difference is. I’ve even set the HtmlViewer’s useragent string to the same value as my current Firefox useragent, but it still won’t run. Any ideas why it would work in a browser, but not in HtmlViewer? Has anyone else encountered similar problems?
It’s possible that they’re trying to force users to access their stream through a pay service, but I’d find that surprising because they publish all of their stream links on their website, and seem to encourage direct links. Their website is: https://jazzaliciousradio.radioarcadiagroup.com/Listen.html
Thanks for the test report. Sorry, I forgot to mention I’m using 2018r3 on a Mac. My development machine is stuck in the past because I need to use MacOS Sierra for a lot of my work.
I’ll try rebooting with a newer system and newer Xojo version, and see if that fixes it. It’s weird when the built app has been working for several years and then suddenly stops working with just one site.
Well, that worked fine for about 4 months, and now in the last few days, one by one, several audio streams have gone dead on my player, but still work fine when the stream URL is pasted into a browser. I tried the “dead” streams on both Firefox and Safari, and they worked there. But they don’t work in the HTMLviewer control. Of the various streams that still work on the HTMLviewer, they are a mix of https and http, and a mix of formats mp3 and m3u8. I’ve found no difference between the ones that still work and the dead ones, other than the fact that the dead ones are dead. This is what the HTMLviewer displays when a dead stream is loaded:
Otherwise it displays:
I thought maybe it was another Webkit problem, but since (I assume) Safari is using the same Webkit library, and Safari still works with the streams, then it must be some other problem.
Thanks Ian. That was one of the first things I thought of, and I did set the user agent to the exact same value as the version of Safari that’s running on my computer. The same Safari version that’s able to play the streams. So, the problem appears to be somewhere else.
BTW I’m building the app with Xojo 2022r1.1 which is the latest version that I have a license for. I am still running the app on an older version of MacOS: High Sierra, but since the streams work with both browsers on this OS version, I’m thinking (hoping) that the problem must be something other than the OS version.
Thanks for that link.
Okay, I’ve added this code to enable the developer tools and call it from the main window open event.
Public Sub EnableDevTools()
'Shell code to enable Web Devloper Tools in HTMLViewer
Dim My_Shell As New Shell
Dim theShellCode As String = "defaults write com.robertweaver.MyPlayer WebKitDebugDeveloperExtrasEnabled -bool YES"
dim ercode As Integer = My_Shell.ErrorCode
dim result As String = My_Shell.Result+EndOfLine+str(ercode)
if ercode<>0 then
MsgBox "Failed to Enable Web Devloper Tools. Errcode: "+str(ercode)
MsgBox " Success; Result: "+result
It returns with no error, but after that I don’t know how to access the tools. The HTMLViewer doesn’t look any different.
BTW, since I’m not sure which version of Webkit is running under High Sierra, I tried both WebKitDeveloperExtras and WebKitDebugDeveloperExtrasEnabled. Both return with no error.
Oops, nevermind. I get the tools now if I right click on the viewer. I thought I’d tried that with both WebKitDeveloperExtras and WebKitDebugDeveloperExtrasEnabled, but maybe not. In any event, the tools now come up, and I’ve been able to track down the problem to at least a couple of the streams.
Apparently, over the past couple of weeks, these streaming sites have started rejecting http connections, and now require https. I should have considered that, but since the http URL worked fine when pasted into either Safari or Firefox, I assumed the problem must lie somewhere else. I guess Safari and Firefox both catch that error and automatically rewrite the URL to https and retry.
Anyway, thanks for suggesting the HTMLViewer web developer tools. I had no idea they existed. A new tool for my bag of tricks!