Locast buffering issues

Channels DVR Server
#131

@crackers8199 So I saw this thread show up in my email Summary and it piqued my interest. I'm definitely not an expert in this specific field, however given the fact you're at your wits end (and I also greatly appreciate your work on the MLB.tv docker image), thought I'd throw another idea in the ring.

Instead of hardcoding the HLS/LAX IP, since that breaks CDN functionality, have you tried a CNAME? I cannot test it here as I'm outside your market, and typically CNAME's only work if the server supports it, however I checked the TLS certs and lax.locastnet.org IS using a *.locastnet.org wildcard cert (HLS.locastnet.org is not, but that shouldn't matter if you're CNAME'ing "HLS" to "LAX".

You'd definitely need a DNS server you control to make this config and test it out.

No promises or guarantees, just another idea!

1 Like
#132

Good catch. Unless providing a DNS CNAME alias is trivial for the OP, suggest he try an HTTPS download from lax.locastnet.org with the Host header changed to hls.locastnet.org. Given the wildcard cert, possible the lax CDN will not care about the hostname mismatch, but potentially easier to test in advance.

1 Like
#133

I tried that and couldn't get it to work, but it's possible I set it up wrong...if you're willing to help me make sure I have it set up correctly I'm willing to try anything at this point! I have Adguard home running as my DNS server and tried a DNS rewrite which is supposed to do exactly what you said, but it didn't work. the streams wouldn't load with that in place...

#134

I emailed Locast engineering about this and am waiting to hear back.

2 Likes
#135

i appreciate that. thank you.

that being said, if their engineering team takes as long as their tech support you're going to be waiting a while. i emailed them the other day as soon as i figured out what was going on and i still haven't heard anything. when my account kept getting screwed up with the too many streams message it took them two full weeks to respond.

#136

CNAME doesn't work, unless i have something set up wrong. this looks correct...

$ dig hls.locastnet.org

; <<>> DiG 9.8.3-P1 <<>> hls.locastnet.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61260
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hls.locastnet.org.		IN	A

;; ANSWER SECTION:
hls.locastnet.org.	10	IN	CNAME	lax.locastnet.org.
lax.locastnet.org.	287	IN	CNAME	fp2752.wpc.9891c.alphacdn.net.
fp2752.wpc.9891c.alphacdn.net. 287 IN	CNAME	fp2752.wpc.alphacdn.net.
fp2752.wpc.alphacdn.net. 287	IN	A	72.21.81.113

;; Query time: 2 msec
;; SERVER: 192.168.88.230#53(192.168.88.230)
;; WHEN: Sat Aug  7 15:16:47 2021
;; MSG SIZE  rcvd: 137

however, when i try to load the streams in channels, i get immediate "playback failed" and this shows up in the logs (full URL snipped for brevity):

at=2021-08-07T15:17:00.890233688-07:00 tag="KCBSDT" action="parseMasterPlaylist" url="https://hls.locastnet.org/proxy/lax/master/xxx.m3u8" status="404 Not Found" err="get https://hls.locastnet.org/proxy/lax/master/xxx.m3u8: 404 Not Found" time="381.860909ms"

if i take that URL and put it into my browser, i also get 404 not found there. however, if i then use the exact same URL but replace hls with lax...it downloads the playlist just fine. which is why i was just wanting to do a simple string replace on the URL. which is what i did with fHDHR, but as i've said a few times although the streams from there play fine in VLC i can't for the life of me get them to work in channels. i've tried both as a fake HDHR (which i know isn't supported, but i'm literally open to trying anything at this point) as well as just custom M3U, neither one has worked.

#137

does not work. sends back a 404, same as the result i get with the CNAME in place...which makes sense.

#138

A reverse proxy would do what you want. Nginx or maybe caddy

#139

i've got a DO server already running with traefik on it...how would i configure it to handle that?

#140

i have the http redirect working, but getting this on https (which means it isn't working completely, obviously)...

This site can’t provide a secure connection
hls.locastnet.org sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
#141

doesn't look like a reverse proxy is going to work either, unless someone can help me resolve the SSL issues that go along with that...

err="Get \"https://hls.locastnet.org/proxy/lax/master/xxx.m3u8\": x509: certificate is valid for xxx.traefik.default, not hls.locastnet.org\nCould not fetch playlist: https://hls.locastnet.org/proxy/lax/master/xxx.m3u8
#142

Are you sure that would work? In the absence of application URL rewrite, the OP effectively needs to perform a man-in-the-middle attack on HTTPS. Locast using a wildcard cert on lax.locastnet.org gets him half there, but the Host: issue cannot be overcome if enforced by the lax CDN.

The crazy approach is redirecting all *.locastnet.org traffic to your own web server/proxy/etc and doing a 302 redirect to lax.locastnet.org. That requires having a valid locastnet.org certificate. While mostly impossible in the wild (state-sponsored actors excluded), somebody owning the originating server can self-sign a fake cert and then provide the root-CA to their OS so that applications trust it. Add your self-signed cert to your Linux cert trust repository (and rebuild the links). If you run channels in the provided container, must rebuild the container.

The cleaner method is adding locast as a custom source. This is not trivial, but neither is the prior method. The main challenge is channels effectively wants static M3U playlist references. Because locast enforces concurrent limits, you must resolve the channel to M3U playback URL in real-time to avoid hitting the limit. There are a number of github projects converting locast to m3u streams, but the recent login-change has upset the apple cart.

Am guessing that due to the current legal action, locast is working very hard to drastically reduce out-of-region access. That is the winning legal angle for the broadcasters. If locast provides streams to out-of-region folks, they do something that broadcast could not do.

#143

@crackers8199 new locast api uses some new POST json and a client_id parameter. This has been addressed in the new patches to the fhdhr locast plugin.

#144

Ah ha! The plot thickens. There must be more clues here: https://github.com/fHDHR/fHDHR_plugin_origin_locast

I'be been reading this thread and learning a lot. Confident a solution will be found!

#145

@fofer @deathbybandaid the recent login change has nothing to do with this particular issue.

#146

the login change has nothing to do with this. i patched fhdhr myself before @deathbybandaid even got to it...the issue is that i haven't been able to get channels to play the streams. at all. i've tried both as a fake HDHR (which isn't supported but i tried it anyway because i am at my wits end trying to get this to work) and as custom channels m3u. neither one works and actually is less reliable than the current buffering problems...

#147

Agreed. My point was that a number of external locast projects have current issues due to the locast login change. So using them as an alternative at this moment in time can be hit/miss. (Seems likely the channels devs and other major players were aware/prepared for the login change in advance.)

1 Like
#148

update: i was able to modify locast2tuner to make this work, even though i don't know rust and am still not sure how this code works overall...i found the stream url and was able to set it to replace hls.locastnet with lax.locastnet, and was able to get channels to play these streams as a custom source.

assuming this doesn't blow up, this'll work as a temp solution until locast fixes whatever the hell is wrong with their CDNs. i'll fork the code on github and push my fix for anyone else who wants to use it.

thanks everyone for your help...

4 Likes
#149

Oh my gosh, I wish I could offer something more to help but this has gone so far beyond my abilities and understandings. This is the most frustrating thread I have ever read and it is obvious you have far more technical skills than the average bear.

Question for you: is your fork of locast2tuner providing the EPG or are you manually mapping the stations in Channels? EDIT: NM, I read through the GitHub documentation is see it is proving the EPG. I get it now!

#150

yep, locast2tuner provides the EPG. i actually made a small change to my fork for that as well because their EPG doesn't include sub-title, which channels uses to show the episode title in the UI. i'm going to make a PR to get that change (hopefully) into the master branch there...

here's my fork, in case anyone is interested:

if you look at the most recent two commits you can see where i did the string replace. the EPG stuff is in the episode-sub-title branch.