1.99.12.18980 M3U Stream sync connection errors

[JamminR]

For all WACUP can and tries to do, I really use it 90% of the time to stream the music from pulsradio.com while i'm doing other things on PC or in my office. Though i have several playlists from the site, I've attached the one I use most and am experiencing the below issue with.

Today, when starting WACUP_Preview_v1_0_21_7236 that I've used for many years, I was notified of the update to 1.99.12.18980.
I allowed an in-place upgrade. I then went back to my folder with my m3u files, double-clicked as i always do, and... no music ever played.
The new version opened. It showed the (new to me) Thinger. It opened the main deck, which, stayed at 00:00 play time.
I opened the playlist, and saw that several errors had occurred regarding the words 'connection sync error'.
I tries several of the items in the playlist.

I immediately re-installed WACUP_Preview_v1_0_21_723 from an old copy i had and am now streaming the music while typing this post.
(I tried finding a previous to the current preview on your site but i can't seem to find an archive release area)

How can I help fix this issue?

Thanks,
JamminR


EDIT - Just tried installing into separate folders instead of the 'update installation' option - same error occurs.
Exact terminology = "Error Syncing to Stream"
(a few in the list might have 'time outs', but, at least one or two in the list should work and not give time out or error syncing

[dro]

The older preview builds are still referenced on the site by following the prior / last preview build link from near the top of the initial text on the site's main preview build page.

I've tried to play all of the links in the example playlist & as-is none of them are working for me either in the current preview or the very old one (which ended up hanging whilst trying to do anything but that might be to do with whatever I'd last done to that test install a few years ago) nor in other players / browsers.

However the problem seems to be because the old preview build would try to force streams to use http:// when https:// was found as that's what was needed to allow the re-used in_mp3 plug-in dll from 5.666 to be more likely to play things.

The newer build has long since resolved that problem & that re-used in_mp3 is now able to try to play the stream urls as-is which is a problem here because what you've provided doesn't respond on the https:// urls from the server side (ideally there should be an attempt to drop back to http but the connection is also taking an age to timeout it seems).

If you edit the stream urls to use http:// then just the sc1 & sc2 server urls don't seem to be responding from my testing.

-dro

[JamminR]

Pardon my lack of full understanding - from the context, you're acknowledging this is a bug? (non-SSL not recognized?)
It will be added to an issue list, and some time corrected?
Even if my playlist has incorrect http vs https entries (i've obtained it from directory.shoutcast.com some years ago), it seems 'wrong' to me that the old version still plays it and the new does not without editing.

I went to directory.shoutcast.com and searched for some pulsradio stations - couldn't find this particular 'station, but dragging/dropping the PLS and M3U download links into the new preview seemed to work.

[dro]

The problem is that whatever provided you with https urls for the streams shouldn't have done that (if it was from shoutcast then that's one more complaint to leverage against them) & it should've only given you http urls as that's only what the provided streams are using.

It worked in the old WACUP preview because I was having to force https -> http to avoid issues with the re-used plug-in that handles such streaming & that masked the playback problem but it then broke legitimate https playback. In hindsight I should never have done that action.

The current build allows both https & http to work but it's now "broken" things for you because it's honouring what the url type is & as those don't support https (again those provided urls should never have been https ones from whatever service was providing them) then until I make my own plug-in for streaming which might attempt to re-try failed https as http it requires you to 'fix' the urls which'll work on both builds.

-dro

[JamminR]

Fixing the playlist files was a simple edit of removing :80 at end of URL - had no need to switch https to http.
Doing this has at least caused me to also remove the servers that would not respond no matter the player (due to age of the list)

I guess the 'old' version was a bug since it played 'https://blah:80"

This issue is resolved as far as i'm concerned.

I would suggest looking into determining if you could cause "connecting" attempts to fail sooner to move onto next item in list after a fallback.
I've not tested (yet - may forget, currently in a mid quick break of other work) to see what would happen if I just fed a playlist raw URLs with no http or https in front of the address.

Thanks for the assistance.
Keep up the great work.

[dro]

I'd completely missed the port 80 in the urls. For http, port 80 is typically assumed if not specified whereas for https it's 443. So removing the :80 or changing https to http has the same effect to 'fix' things in that it's allowing the wanted default connection behaviour to work.

So trying to do an https assumed connection against the typical http port would mean there's a connection being established but in_mp3 doesn't know how to cope with the data its getting back since it's very likely expecting an encrypted stream but since it's an http connection it just keeps going until it &/or the connection times out hence the "Error Syncing to Stream" message.

That'd be why the old preview worked as the 'https://blah:80" was force changed to 'http://blah:80" which would work. Streams on other ports don't necessarily seem to be hitting these base http vs https assumptions (not sure if that's within in_mp3 or the networking service it uses which I've got some control over) & is something I can look into improving.

The other aspects need a whole new input plug-in (not only for mp3 / aac streaming but all of WACUP's streaming support overall) & is something I'll keep in mind for when that work is begun as I don't want to do more against the networking service in_mp3 is using as I really don't plan on keeping it around when my replacement is done.

-dro

[dro]

That'd be why the old preview worked as the 'https://blah:80" was force changed to 'http://blah:80" which would work. Streams on other ports don't necessarily seem to be hitting these base http vs https assumptions (not sure if that's within in_mp3 or the networking service it uses which I've got some control over) & is something I can look into improving.

I've now had a look from a code view point & it appears to be down to in_mp3 doing the url processing before it calls things in the networking service which is then just trying to process the connection against what it's been instructed to use which is what it should be doing but also isn't necessarily ideal when the default http / https port url is trying to be used.

For the next build I've modified the networking service so it'll check what the connection type is vs the port trying to be used. If it's https & port 80 then it'll change it to port 443 & if it's http & port 443 then it'll change it to port 80 which seems reasonable & looks to be something browsers seem to be doing. Doing that allows the provided example playlist to work as-is.

-dro

[JamminR]

Thanks - that's great for 'bad' links.
I'd say a majority of 'commercial' services (shoutcast/icecast/...) would use proper http 80 vs https 443 ports, however, I hate to be a pain, would it still allow for custom https though?

Though I don't run any streaming audio servers myself, I do occasionally host SSL web sites on my home lab using non standard ports
https://blah:8080 or any other number of port numbers.
I could imagine a person using different ports for different streams.

I know, devils advocate here, but don't over-fix the code, considering the old version seemed more a bug handling broken files vs new one doing proper.
I was just hoping it could be made to fail faster.

[dro]

I'm only looking at ports 80 / 443 in comparison to whether https or http is specified & if they match as expected.

Everything else will be processed as provided by the caller to the networking service & assumes that whatever is providing the stream urls is doing it correctly otherwise I'd have broken the majority of shoutcast/icecast/equivalent based streaming urls (which for shoutcast defaulted to 8000 if memory serves me right from what I vaguely still remember from when I worked on that).

There'll also be a new prefs option (general -> internet) that allows for the new behaviour to be disabled.

-dro

[JamminR]

Great options. Thanks for the continued excellence in keeping the app alive.