Locast buffering issues

Channels DVR Server
#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.

#151

just as a way of closing the loop here (and additional proof that the locast CDN is the issue), i've had locast channels up using locast2tuner and the modified code (to force the lax subdomain) all afternoon (at least 2 hours or so) and haven't had a single skip or buffer. no timeouts in the logs.

i have no idea what they did, but something is screwed up on the hls subdomain somehow. i'll be interested to hear if they come up with a solution once they get back to you guys @tmm1.

3 Likes
#152

one thing i have noticed in having this up in the background all afternoon, is that there is a little bit of buffering when the locast login token expires (seems to be every 5 hours from the locast2tuner logs). never seen such a thing using the default locast integration, although i guess it's possible i've just gotten lucky / not really been watching for it...