For clarity, the example I pasted was just showing that the stream I tested was indeed passing along Closed Captions in the stream. Nothing you need to do.
I'm really not sure what would caused closed captioning to not work-- please try it on a few devices to isolate if it's the client, or something more I need to look into.
Pluto uses WebVTT for subtitles and Channels does not provide a way to use them. As far as I remember, Pluto has never had working Closed Caption through Channels
maybe i was crazy and looked at the wrong source when I was checking earlier, but I swear I saw Captions... i stand corrected!
Some sources may be different. Im pretty sure I was checking that out a few months ago and could not get them to work.
I have been randomly checking the Pluto channels. I have found a limited number that do show captions, most do not. This is on an Apple TV. Same results on an iPad, iPhone, and laptop computer. So it appears that closed caption availability is inconsistent; most likely an issue from Pluto; not from Channels or your docker program. Thanks again for your help.
Check these posts
good stuff thanks.
I suppose it'd be technically possible to remux the WEBVTT subtitles and proxy it back to CDVR, but I don't think the juice would be worth the squeeze.
can you add a -e START=N argument like maddox version? so N is added to the pluto channel number.
actually here's a pull request.
Disregard --- just updated and now I see the new version 1.24 --
Looking to see which is the correct/current version...
Here is the one I'm tagging: image: kineticman/pluto-for-channels:main
Here is the local container's web page:
Here is the Readme:
Just wanted to make sure I have the latest...
You have the most current version either 1.22 or 1.23. It is a typo probably in the Readme.
easy to add.. one thing i noticed - the pluto.py applies a country-based offset (CA +6000, UK +7000, FR +8000, DE +9000). channel_start stacks on top of those. I'm guessing original developer had a case for that, so I'll just keep that logic in there.
v1.24 is out!
Two updates in this release:
PLUTO_START — new env var that offsets all channel numbers by a fixed amount. Handy if Pluto conflicts with another source in Channels DVR. Example: -e PLUTO_START=35000
DRM fix — cleared the drmCapabilities flag that was causing false-positive DRM detection on some clients.
Fresh install:
docker run -d --restart unless-stopped \
-p 7777:7777 \
-e PLUTO_USERNAME='[email protected]' \
-e PLUTO_PASSWORD='yourpassword' \
-e PLUTO_START=35000 \
--name pluto-for-channels \
kineticman/pluto-for-channels:main
(Remove or set PLUTO_START=0 if you don't need the offset)
Existing users — update to latest:
docker pull kineticman/pluto-for-channels:main
docker restart pluto-for-channels
Full details in the README.
@KineticMan really appreciate your work on this.
One question, should we be able to specify a different port? I assume changing
ports:
- 7777:7777
to something like
ports:
- 7790:7777
should work?
yep just leave the second one at 7777 (it's just the internal container port) but feel free to change the first to whatever you prefer.
cool, that's what i thought. wasn't working. i'll get it sorted just wanted to make sure that it was capable!
thanks again @KineticMan 
Anyway you can update your date on this. Still shows September.
Looks good thus far, thanks! I'm also adding some more robust DRM detection to PLM just in case something slips through the cracks.
Now, if you really want to take this one to the next level, I'd say it's time to implement the Gracenote/EPG-only breakout...
@Jean0987654321, do you have an even more up-to-date list that you could share?
That would be quite a time consuming task to verify the station Id's
Ehh...its been a while and I usually use SLM to map the gracenote ids for the channels I care about from Pluto nowadays...
I can take a look when I have time but I don't think anything has changed from those ids
