Locast buffering issues

It might be cycling through the various hosts, and one may not be as responsive as the others:

$ host hls.locastnet.org
hls.locastnet.org is an alias for d2d8b1al8lhk8k.cloudfront.net.
d2d8b1al8lhk8k.cloudfront.net has address 13.35.89.84
d2d8b1al8lhk8k.cloudfront.net has address 13.35.89.24
d2d8b1al8lhk8k.cloudfront.net has address 13.35.89.47
d2d8b1al8lhk8k.cloudfront.net has address 13.35.89.97

It might be worth it to try putting something like:

13.35.89.47    hls.locastnet.org

in /etc/hosts to force a single IP address to resolve for your Locast streams. (Of course, you may want to run a long ping test to see which server is the most responsive.)

something strange is definitely going on with the VM that is acting as my channels server. if i run the traceroute and ping on the proxmox box directly, there are no slow pings and the traceroute is almost instantaneous.

from the VM, the traceroute takes somewhere between 45-60 seconds (if not longer) to finish, and the occasional slow pings show up.

That makes it sound like there's a problem with the kernel/virtual network driver of your VM. That would also explain why you don't have the issue with their app/website. Sounds like it's something about the networking driver handling the VM, and it not liking the Locast CDN.

that makes sense. what doesn't make sense is why it just started happening like a week ago all of a sudden...that's what i'm trying to figure out. i don't believe i did any updates around the time this started.

any suggestions on how to resolve this if that's the case? i'm at my wits end, and i'm out of ideas.

I've been seeing the same issues over the past week in the Phoenix Locast market (hour outside of Phoenix), and viewing through the Locast app appears to be mostly unaffected. System is running on a dedicated MacOS server with gigabit connections throughout the entire home network and more upstream bandwidth than I could ever use. I'm viewing on an AppleTV 4K and my recordings are unaffected, I'm only seeing this while watching live TV. I avoid using wifi for anything other than handheld devices at home. I haven't had the time to dig further into the issue, and haven't had a chance to report it, so just adding this for now. If there were a server side problem I'd guess that recordings would be affected too, so I'd say there is something with either the AppleTV in general, or with the client app.

Chief

1 Like

thank god it's not just me. i'm using android though, so it's not likely that the apple tv client is an issue.

random thought: are you using a docker install?

A couple ideas, from easiest to more drastic:

  1. Give your VM a network interface via pass-through, so it is using the device directly, rather than a virtualized device.
  2. Use a containerized install—LXC, OCI/Docker, systemd-nspawn—as the container will use the host's kernel and networking.
  3. Move to a bare metal installation.

Those are in addition to the idea of using a hosts file/DNS override to ensure only a single/specific IP is used in case the issue is with Cloudfront's load balancing.

it is containerized. i have an alpine vm and then the channels docker container on top of that.

bare metal isn't an option, i don't have a machine to run it on at this time. also, doesn't explain why this has only started happening in the past week or so and ran flawlessly forever before that.

I meant in place of the VM. A container in a VM is using the VM's kernel. The idea is to reduce complexity/layers, not increase them.

i understand, but again, the setup i have right now worked perfectly for two years until about a week ago. changing things around now would be adding more complexity for my own personal situation, not making things easier.

plus, with one other person in this thread reporting the same issue, i'm comfortable now that whatever is causing this, it's not an issue with my setup. there's something else in play, here...

this is so incredibly frustrating. i literally can't watch ANYTHING without it stopping to buffer so much that it's literally unwatchable. i pick a channel and within 60 seconds or so it's stopping to buffer for 30+ seconds. plays for a minute or two, repeat the cycle. ugh.

actually, i think this wouldn't necessarily be the case...if it's recording, the server has time to wait for the data to come in because it's not presenting it to you immediately. when watching live, you're seeing the buffering because it literally isn't getting the data fast enough to show it to you as you're watching it.

This is coming from out of far left field, way out there. You could try rolling back your mlb docker to like 1.31. Seems like the timeline of your locast issue started around 1.4. Probably has nothing to do with it but it sounds like nothing else has changed with your system. By the way thanks for your work on the mlb docker. I’m not currently using it but thinking about picking up mlb.tv just because of this docker. Good luck

that's an interesting thought but i don't think there's any way that can have anything to do with it...i have my mlb container on a completely different server.

tried locking hls.locastnet.org to what appears to be the fastest server (based on ping times)...that hasn't worked either. in fact, that made things worse. not sure how that's even possible.

@tmm1 not sure if this is relevant, but it just took 10-15 seconds for the web ui to notice that i had closed my stream. in the past, that has been nearly instantaneous.

Not sure if this is relevant but I had a problem with one locast channel not playing at all and I was told to install the beta version of the server and that fixed my issue. I am currently running version 2021.07.21.1751

i'm actually ahead of you. i'm on 2021.07.29.2129.

Current is 2021.08.04.1909.