You entered the epg url incorrectly. There is an extra space at the end
Damn copy and paste.
Thanks
It was for m3u but not xml. The latter is now fixed with the next build.
One last question for anyone related to stirr and/or pluto.
How far in advance does your guide display data?
Funny, that was just asked in the regular Pluto thread. The answer is 12 hours for Pluto. It looks like 24 hours for Stirr.
I've been living under a rock and just discovered this (although our Channels DVR has been in hiatus for a while after a move). I've been using the Docker versions of Pluto and Stirr since they first came out with not much issue. Is there any benefit of shifting to this version other than a lot easier to get setup? Just wondering if "don't mess with it if its working" comes into play here.
Try it yourself. It takes 2 seconds to set up. Why have docker taking resources needlessly? Decide for yourself.
Both are getting the same underlying guide data from the same source. Using the nocords.xyz solution is just a lot easier, quicker to get going, and doesn’t rely on your own local server to do the data massaging. It feels like one less variable to worry about, especially if the Docker Desktop requirements are proving to be problematic on older Macs.
Thanks. The resource drain isn't a big issue because the Mac is solely used for Channels, and this doesn't seem to have a noticeable load. I suppose there is some risk that the central source for the non Docker approach may not always be there, while the Docker approach is self hosted. I was just curious if there was any other benefit to this approach other than if it was the first time setting up, it would be way easier.
Good Point if that web site is not available you are out of luck where running the Docker connects directly to Pluto.
What is it about the Docker source that guarantees it will be around for all of eternity?
The Docker "source" is the actual provider, so if its not around then you can't get any data anyways. The source from docker of the container, I believe is the same source the new provider is using, they are just serving it. The host of it could change jobs or something and / or no longer wish to provide the servers. Its also possible that being so big of a source, they may draw attention resulting in being shut down. Likely none of this is going to happen, but with Docker you are going directly to the source for the data so no middle man per se.
None of this is life altering if it stops, and the non Docker approach if starting from scratch makes total sense as the way to go. But if you are already up and running with Docker, the benefit of easy setup is irrelevant because you've already done it and can't get the time back.
I also used the Docker source for quite some time. (Running Channels and Docker on my Synology NAS.) The STIRR and Pluto images were the only things running under Docker. When I switched to the non-Docker sources, I could eliminate running Docker altogether, plus I could use the Custom/start option to specify channel number ranges for the Pluto and STIRR services.
Not to worry.. first, it's all hosted on AWS, so not dependent on a "job." I'm also self-employed, so I'm not changing jobs any time soon. Finally, I've said earlier in this thread that if for any reason I can't host the nocords.xyz site anymore, I'd find someone else to take it over. It's not a lot of code and would be very easy for anyone with basic web/linux skills to take over.
Also not going to happen. nocords.xyz polls the Pluto and Stirr sources no more frequently than any of the docker sources. So to the upstream providers, it looks no different.
There's also the issue of ongoing maintenance. It's easier for server upgrades and migrations. There's no need to check for updates to the docker file or manually apply them, all of that is now handled by nocords.xyz. And since older Macs are getting more difficult to run Docker Desktop on, as you've experienced, this makes a difference too.
In the end, whatever works best for you, but these differences bring me peace of mind. The easy ability to specify when channel numbering starts for the Pluto and STIRR services is just icing on the cake.
Not meaning to imply anything or suggest you aren't all in on this. You have done an amazing thing here that everyone should be immensely grateful for. But, you are a guy on the internet. I used to run a website forum that had a million unique visitors a month, until I didn't. We all have lives and things sometimes change, by our choice, or for other reasons. Its a risk, however small it may be.
That's good to know... then your doing it is probably less risk it draws notice. This is good for the community to me.
In my case the maintenance had been zero until I tried to upgrade the Mac and it required brute force... format the drive, reinstall the OS, and restore from Time Machine backup. Prior to that I've not really had to do anything. But with Docker for most people, when you do have to do anything, its a lot of google searches to figure out what to do.
Choices are good. My motivation for bringing this up was just to understand better why one option over the other, so hopefully it helps someone. I didn't know about the numbering thing. You guys have convinced me to try this when I get a moment. I'll try to write down my notes from Docker in case I want to go back to it. I think I know now how to remove these containers if I do.
I gave it a try and the Guide now (if I select Pluto as source), has channels start at 0 (TV Land Drama) and go up to 8440. I can't count how many, but there are a ton. Guide for other sources all seem correct (Hulu, your Stirr, and Frndly). As a source in settings it says 353 channels which was the same I was showing my my Docker version. I tried the other php url so start numbering at 5000 and same result. I'm guessing I did something wrong but all I did was copy the 2 urls above into the source.
Under Options did you choose "prefer channel-number from m3u?"
For me switching to the nocords.xyz solution was a no-brainer because it uses virtually no resources while the Docker Desktop carved out around 40% of my 16GB of memory for its container. I'm no expert though, so I may have had it set up wrong.