Locast buffering issues

Maybe you’re being throttled? Try vpn’ing out to a server in your locast location.

if that were the case though, wouldn't it be happening on roku and every other device using the locast apps? they all also are hitting hls.locastnet.org and aren't having any issues. somehow it's only the third party apps that are lagging.

at the risk of jinxing this again, just did another experiment...

it definitely seems to be an issue with the LA locals. i VPN'd to another market and it hasn't buffered once. hasn't timed out a single time either while watching those locals. only been a few minutes but the LA locals definitely would have timed out by now.

turned off the VPN to switch back to LA locals, and it's buffering again.

the one thing i noticed: the address formats on the HLS URLs are different. the SWB locals that i VPN'd to (connected to my mom's house in NEPA) were using:

https://phi.locastnet.org/proxy/phi/wolf_src271355767.ts

vs LA

https://hls.locastnet.org/proxy/lax/knbc_src271355985.ts

is it possible the URL is wrong, somehow? lax.locastnet.org does seem to exist and would make sense...is there a way to force it to that data center rather than this random hls subdomain?

expanding upon my last message: if i use the hls logs and change hls.locastnet to lax.locastnet, i can load the master playlist and the variant in chrome. they both should work via channels too, if the lax subdomain were forced.

Does channels require donor creditials of locast to work? From what I read if you are on free version it will randomly have a pop up to donate and kick back to the guide. How does channels handle this kick out? Is it possible your donation this month didn’t get applied and you are getting kicked. Is it possible the roku has different kick rules and the new VPN market changed the algorithm of sending the donate now pop up and kick. Just throwing that out there

nope, my donation is active or i'd be seeing the donate messages when using the other apps. AFAIK locast will work with the donation messages, it just kicks you out of the stream every 15 mins.

Most unscientifically (SWAG) I would write this off as L.A. being a large enough area and the Olympics going on that your Locast CDN is having issues. I have no issue watching the Olympics in my area with Locast unsubbed.

Unless they're giving preference to those unsubbed (like me) to draw them in.

yes, but the CDN is fine if you use lax.locastnet rather than hls.locastnet.

i have the nbc stream up right now in VLC on my computer, but using lax.locastnet (i took the exact hls.locastnet URL from the channels logs and just changed it to lax), and it hasn't skipped once in almost 20 minutes.

I think you answered your question then.

huh? i'm saying channels is loading the wrong URL...

I meant this

1 Like

that doesn't really help me though, i need the devs to make a change to make this work then.

i have the lax.locastnet version running via channels right now, we'll see how long it goes before having issues. i created a new custom playlist with that URL and have it running on my chromecast right now.

1 Like

Looking at the DNS, it's a totally different CDN (hls. vs. lax.):

$ host lax.locastnet.org
lax.locastnet.org is an alias for fp2752.wpc.9891c.alphacdn.net.
fp2752.wpc.9891c.alphacdn.net is an alias for fp2752.wpc.alphacdn.net.
fp2752.wpc.alphacdn.net has address 72.21.81.113

yes, i've seen that also. that being said, running the same exact URL but with lax instead of hls works, and hasn't stopped to buffer a single time yet. i've had it running for about 15 minutes so far without a single hiccup.

OK, didn't read every post and thought your recordings were good and you only had issues with live viewing.
When I have issues with Live viewing I check the website channels uses to see if it has issues.
I guess you and the devs are on a different wavelength than us normal users.
And if you're going to talk abous nslookup results it would be nice if you mention the authoratative server that responded, if not recursive to the root domain.

that is the case, but that makes sense when you think about it...when recording, the timeout issues don't really matter because the dvr has time to recover from it and keep the recording intact. when you're watching live, the timeouts screw everything up because the server literally does not have the data to present to you without stopping to buffer...

been running using the lax.locastnet CDN for more than 30 minutes now without a single buffer, hiccup, or timeout failure. i'm going to say this is more than likely the issue.

@tmm1 @eric how can we resolve this?

The url comes from api.locastnet.org.

Sounds to me like something they are deliberately doing on their api. Maybe they are testing a new CDN in the LA market?

I am not a network engineer, so I can't explain why only some devices on your network have issues talking to the Amazon CDN.

Have you emailed their support about the domain discrepancy?

i have, but they haven't responded yet. they take forever.

is there any way we can put in some sort of override, like an env var or something that i can pass into the container? i understand that it's coming from the API, but it's literally the difference between me being able to use channels to watch locast and not being able to use channels to watch locast....