Non-Docker source for PlutoTV and Stirr m3u playlists and EPG

Got it... Too bad as this is a key feature I'd like to use to record daily news for example...

2 Likes

LOL, I just saw this morning that this reply was from you Matt. Thanks for replying!
I'm been meaning to reach out to see if I was missing anything in your Docker/Python code.
I don't know Python, so I wanted to be sure I got it right.
-Hank

2 Likes

Its interesting note here that the SamsungTV Plus has more complete data (tags/images/etc) than PlutoTV has

Please don't clutter up this Custom Channels topic with discussions related to the sources (Pluto/Stirr/Samsung/etc.) EPG data.

If you want to discuss this, feel free to create a topic in
Custom Channels - Channels Community or TV Talk - Channels Community or Advanced Passes - Channels Community

Users come to this topic to learn about and discuss the topic title. They don't want to have to scroll through unrelated/off-topic posts. See Forum FAQ - Keep It Tidy

Thanks

6 Likes

Any instructions available for those who don't know what to do with the files on git?

1 Like

Unless you want to clone the functionality of the website, you don't need to do anything with github. Just follow the directions in the first post or here: https://nocords.xyz/

2 Likes

Wow, I was expecting it to be WAY more complicated. :joy:

Thank You!!

1 Like

Hello Folks,

Turns out this project is more popular than I expected and I'm seeing connections from many countries.

But there are a few people who are downloading the Pluto EPG every hour on multiple devices. This is a very large file - about 6MB each time it's accessed. In just the few days this has been up, the Pluto EPG has consumed over 6GB of bandwidth.

Since the underlying Pluto epg.xml file is only refreshed every three hours, it makes no sense to pull this file every hour.

Please review and update your Channels admin settings and make sure you are pulling the Pluto EPG no more than every three hours. It's just a waste of bandwidth.

I will continue to offer this service totally for free as long as people don't abuse it.

Thanks.

2 Likes

You’re probably already aware but I think Channels can also handle a compressed (gz) version of the file. I know that’s a bit more work for you but I would think it would save a significant amount of bandwidth.

2 Likes

I was not aware of that, but pretty much all web servers and browsers these days automatically compress /decompress content on the fly, so we we're already getting those bandwidth savings.

Browsers that support compression send this header: accept-encoding: gzip, deflate, br and most web servers respond with a compressed file with this header (for my web server): content-encoding: br

'br' in this case is Brotli compression. See: Brotli - Wikipedia

Thanks for the suggestion though!

2 Likes

Ahh ok. I guess you could verify if the requests you’re getting from the server have the compression headers. But maybe you already have. Oh well.

I have not.. I assumed the web client libraries the apps use are contemporary and support compressed transfers (it's been pretty standard for decades). But I'll certainly check that out tomorrow.

1 Like

I just did a quick check, and at least the Channels DVR server is using gzip compression. But there are dozens of other IPTV clients people are using with these links, so I'll have to wait and see what encoding those apps request.

2 Likes

It's been an hour and all accesses from all clients are gzip compressed.

2 Likes

This was working flawlessly until yesterday. Last update was at 10m (forced) woke up this morning and it had not updated so (forced) updated to get a fresh guide at 7am

The only thing I did on my end was after reading the message (Non-Docker source for PlutoTV and Stirr m3u playlists and EPG - #50 by HankLloydRight) I changed from 1 hour refresh rate to 3 hour.

Note: My computer resources used diminished by 30% and the CPU load reduced to 8% average, way down from what it had been (somewhere around 50%) after suspending Docker and WSL2. Making channels quite responsive again, so to me, the the benefits of this to channels is remarkable and I very much thank the author for the nocords.xyz contribution.

What Channels app/server/client are you using? In my ChannelsDVR settings, I only see refreshing the EPG at most every three hours and the M3U daily. Where had you set it to refresh every hour? Also just make sure you're using the links in the first post and that they are HTTPS and not HTTP.

The only thing I changed yesterday was the way the file was downloaded (changed the content-type) to make sure the content was always transmitted in a compressed format, it shouldn't have had any effect on the results at the client apps.

Please DM me your IP address and I can look at the logs and see if your requests even made it to the web server. I checked the background jobs for Pluto and Stirr and they're both working normally.

Great! And you're welcome.

always the latest
Server Version 2021.10.17.0416
Client (2021) 10.17.2000

That's what I had figured, besides if it were indeed anything to do with compression the forced updates wouldn't have completed the refresh so I doubt its this. I've have my suspicions (not always initiating) about the 3 hour refresh rate for awhile

just double-checked it is set to https:
https://nocords.xyz/pluto/playlist.m3u

Ok, I see. I recently moved my DVR server to a different machine and forgot to update to the pre-release version. Now I see the 1-hour update option for EPG. The links are definitely working on my DVR server. Let us know if you figure out what the issue is.

Awesome. Thanks for checking.

I'll not touch my settings (set for 3 hr refresh at the moment) for a few hours to see if things act normally.
Then I'll try the 1 hour settings again and see what differences, if any, I experience and let you know.

1 Like

What are the symptoms you're noticing? That the guide isn't being updated (i.e. the refresh isn't triggering) or that the guide data isn't changing (the refresh is triggered, but there are no changes to the guide data)?

If it's the former, that sounds like it could be ChannelsDVR not triggering correctly or something else beyond my control.

If it's the latter, we'll need to check if your requests are making it to my server. I have all caching turned off at Cloudflare, so every request should be a hard request to the server. It's possible that something else in-between is caching the results, causing the data that the ChannelsDVR server sees, not to change.

1 Like