Section Not Available, Server not found on first attempt

Ok I’ll try it when I get back home

1 Like

Still fails at cold start even after disabling Tailscale inside app debug

New diagnostic log submitted under 0946e17a-01ce-40d6-bc1f-4c61303b8d35

FWIW 25000+ channels are espn plus channels that it’s failing to fetch in the logs. It’s failing on the channels with no content currently playing.

My logs are getting smashed with

Failed to fetch station

When the iOS app is running

I see something funny going on with it trying to connect remotely, partially succeeding, then timing out.

Does this happen every time or did it just happen this first time? Could you try opening it a couple more times and sending me the logs again after?

Sounds like you have an m3u that has an XMLTV guide that isn't including any entries for those channels. Is that correct?

My router doesn’t support hairpin nat so not sure how it could succeed at all using remote on LAN.

Seems like first time every time but with some length of time passing after closing the app. If I close it out and try again after it connects it will usually connect right away even after closing the app all the way and relaunch.

Here is a video of what happens:

I guess. It’s the Eplus espn plus container that many on here run. Surely their logs aren’t getting slammed like this or I’d assume there would be reports.

14:53:35.823394 New diagnostic log submitted under 171a8f70-409e-4232-ae09-a39e2f085c7a

This doesn't solve the original issue in this topic, but I noticed that alert that was showing as fall out as being incorrect. It certainly makes the situation more confusing, so it's resolved now in the latest TestFlight beta:

I’m assuming you’re talking about the failed to fetch.
It doesn’t seem to have helped. FWIW only my iOS makes it trigger on any activity from within the app. Switching from guide to library to on now ect.

My shield tv does not trigger any failed to fetch or have any problems launching the app at any time.
New diagnostic log submitted under 6d080329-7f50-4f60-a52a-f715198ee19a

I meant the “section not available” alert in the Ui.

Just now on cold start

What is your start up section? library?

Is this happening while you’re having a latent connection?

I’m have trouble keeping track of the issue in this topic.

Don’t think it’s a latency issue

I assumed they were all related to each other and causing the app to not find the server on a cold app launch. They all three showed up at the same time, app not launching correctly, logs bombarded with fetch espn plus channels that are not broadcasting at the time, and the section not available pop up.

Huh ok, I’ll check this in the morning.

Please submit diagnostics from your Channels app after you experience this error alert again. Right after you dismiss it, please go to Settings > Support and use Submit Diagnostics.

I see this all the time on my tvOS beta client, section not available and my default is recordings. Pretty much happens every time I wake up the ATV but only when channels was the last app in use. Tailscale is off in debug.

Not a big deal because hitting the back button gets you where you want but it is an annoyance.

This time it did not eventually find the server(normally it finds the server after about 8sec). I had to manually connect by choosing my local LAN server ip.
New diagnostic log submitted under ec1ecbd9-5d7a-4668-88a2-38101d5c34c7

@GTFan Do you have multiple servers running and available to choose to connect to? Trying to find a common thread here.

Here is another diagnostics when it did find the server after about 8sec
New diagnostic log submitted under 2d189a34-e1bc-409f-9fd1-e940bdf19cf5

for the record, I would count 8 seconds for just finding the server, as latent.

Only one server, both client and server are hardwired. Absolutely no other issues with the network, it's some sort of channels bug on wakeup from what I can see.

1 Like

@Rice: Yeah, you really do have something weird going on with the discovery process on your device. I'll have to continue to read through your logs in more detail to get to the bottom of why it's behaving differently than expected.

If you try logging out of your remote session that may clear things up, but I definitely would like to understand what's going wrong.