Why is Docker needed? about pluto-for-channels HOT 8 CLOSED

@HankLloydRight Nicely done.
Thanks for doing this!

from pluto-for-channels.

Docker is not needed. Feel free to run this project by hand. You’ll need to ensure you have a proper JavaScript environment on your computer to do so. You’ll also need a way to serve out the files it generates via a web server so you can add the urls to Channels. You’ll also need to rig up a way for it to run every few hours to be up to date.

Docker makes this all way easier as it’s all self contained. Docker isn’t a VM, it’s way lighter than that. People use docker images for software all the time and it’s become a preferred way to run certain software since you aren’t responsible for dependencies to run it.

As for why the project exists at all, it takes the Pluto EPG and makes it work way better with Channels. It’s confirms to expected metadata, and art.

You can use other methods found on the internet, but the experience won’t be as good, especially when recording.

from pluto-for-channels.

I see. Thank you so much for the detailed explanation.
I understand it a lot better now. I'm gonna have to look into Docker.

from pluto-for-channels.

Hello, thanks for your great work on this repo, I have it up and running on an old Dell Notebook.

Would you mind if I forked your javascript code, converted it to PHP and hosted on a public website, so people would be able to access the enhanced Channels tags you've created for this? I would make sure the unique deviceID and sid UUID parameters are generated every time someone pulls the m3u file down, so there are no conflicts like some of the existing static web-hosted m3u files for PlutoTV.

I think this would allow people to gain access to these channels in the way you intended in Channels, and not be subject to the dropouts and disconnects due to the static nature of the other hosted m3u sites. And most of all, people wouldn't have to wrestle with installing and running Docker on different platforms (especially ones that can't run Docker). I envision this as the "best of both worlds." Do you foresee any issues or problems with this plan?

Of course, I would put the PHP code back up on github with proper credit.

Thank you.

from pluto-for-channels.

https://github.com/maddox/pluto-for-channels/blob/main/LICENSE.md

from pluto-for-channels.

Great, thank you.

Do you foresee any issues with implementing this?

from pluto-for-channels.

OK, I've created a repo that can replace the need to have a local Docker instance for PlutoTV.

It's really quite simple. It runs a slightly modified version of the pluto-for-channels index.js script on my server, then my PHP program replaces the deviceID and sid URL parameters with uniquely generated UUIDs upon each page load. So every use/access of the playlist.m3u file is unique. This should prevent any conflicts, dropouts, and disconnects that other online/public m3u files cause that do not have unique parameters in the stream URLs.

https://github.com/HankLloydRight/pluto-for-channels-php

You can access the resulting files here and put these links into the Channels Admin page. They should work exactly the same as the files created by the local Docker instance. The source files are updated on the backend every three hours automatically.
Playlist: https://nocords.xyz/pluto/playlist.m3u
and
EPG: https://nocords.xyz/pluto/epg.xml

Can I share this on the Channels Community site?

from pluto-for-channels.

Thanks and you're welcome.

I'm looking into the Stirr version now, which is quite a bit harder since I don't know GO. I may try the same thing to just run the GO programs on the server and process the output, or possibly rewrite it entirely in PHP.

But I'm not sure even that is needed for Stirr, since there are no unique parameters in the Stirr stream URL links. They're all static. So I'd guess using the static m3u versions at https://i.mjh.nz/Stirr/ wouldn't cause the same dropouts and disconnects that were happening on PlutoTV.

from pluto-for-channels.