Non-Docker source for PlutoTV m3u playlists and EPG

I was assuming it meant the robbiet480 stirr-for-channels GO program, same as used in his container

which fails to generate a channel lineup playlist

Then the difference in our assumptions is another good reason for it to have been removed. :slightly_smiling_face:

For if it's useful... I'm using the m3u playlist via Tivimate... for the Close Caption (or subtitles), there are three options:

  • Off
  • Closed Captions 1
  • English.

Choosing English used to be the only way to have them, and it worked flawlessly until a few days ago,

Now, every time English is selected, it brings an error message (“An error occurred: IllegalStateException”)

If I go back to off or Closed Captions 1, the audio and video come back normal, unfortunately without subtitles.

Unsure if this is something that can (or will) be corrected, but mentioning for if it's possible...

Could be the source. You didn't mention what "the m3u playlist" is.
Try using one of the channels urls from the playlist in VLC and see if there are still closed captions.

Are you sure your using nocords.xyz for your Pluto with CC? I've used it since he posted this thread and have never seen any except once or twice on an oddball channel I usually never watch. Here's what I see tonight, no •English selection:

VLC shows a WEBVTT stream, but there are no subtitles/captions displayed when selecting it.
Capture2
Capture1
Another Pluto channels has closed captions and it displays


Capture4

Later: Now the same channel that wasn't playing WEBVTT subs is working. May have been the movie that was playing earlier didn't have them.

If you use the nocords playlist directly you will get subtitles and closed captions.
If you use the Channels DVR playlist from your DVR that sources it from nocords, you will not get subtitles, but will get closed captions. Channels DVR does not pass the WEBVTT subtitle stream through.

After I snapped that Gunsmoke screenie above (Tivimate) I left CC on and prowled around. I ended up on one of the Star Trek channels and no CC. Then, oddly, it started to run a commercial and one of the 3-4 commercials had CC, and after it switched back to programming that didn't have CC the old text from 3 commercials ago still displayed until I switched channels.

I guess it's the price we pay for accessing their intellectual property in unconventional ways.

Off-topic, concerning Tivimate, boy is it cool on College Football Saturday having 4 games playing at once. Shame CHDVR cant do stuff like this.

(one image, since new users can only post one)

left: just to show that I'm not confused and that indeed are using the nocords Pluto playlist (I assure that I wouldn't be confused and wouldn't come to a nocords section for plutotv if I were using anything else)

right: what it appears when going to the Closed Captions section... it was like that since I started to use the nocords link, months ago. At first, selecting ENGLISH didn't give any problem and worked flawlessly... the IllegalStateException error appeared a few days ago. Haven't checked in anything else...

2 Likes

I never thought of switching my user agent in Tivimate to VLC, I bet that's why you were getting subtitles. I'm going to have to try that, even though my main use is for live sports, and only recently discovered Tivimate for just that purpose. Shame the recording in Tivimate is mostly unusable, not having a client/server setup precludes that I guess.

No idea why subtitles quit working suddenly, although Tivimate did just upgrade from 5.0.4 to 5.1.0 within the last 5 days. Could be a bug in the new version?

There is a difference between WEBVTT subtitles and EIA-608/EIA-708 closed captions.
Although they may look the same to you on the screen, they are generated(encoded), transmitted and decoded differently.

There may be examples of each one being used on the same channel, so unless you know what a show/movie is using, it's impossible to compare using just a channel or source.

This is getting off-track from Channels DVR and going into TiviMate and VLC instead.
I PM'd the OP asking if he wants this conversation split off.

What do you see on a Channels client device? We know it can't currently handle WEBVTT subtitles.

Have you brought this up to TiviMate support?

I will leave this up to the OP and @maddox if they want this conversation to continue about tivimate

Your previous post about that and VLC made me dig deeper in to why I never have had subs or CC in ChannelsDVR, but he did in Tivimate. I did change the user agent in Tivimate, and most channels do work. FWIW, I'm on an Nvidia Shield Pro, evidently he's on another device, judging by his added "ENGLISH" selection in the CC dialogue he posted a pic of.

Long story short, it makes me wonder if a feature request is in order, or even possible, for CHDVR? It seems to be as simple as making your user agent "VLC" to make CC and subs work for Pluto when using Tivimate.

Also, apologies for veering off-topic here, I just happened to recall past Pluto/CC/subtitle posts and also have an oddball limited use for Tivimate, so I decided to investigate.

I get this both with my U.S. VPN server connected and with my non-U.S. local ISP connection.

I have access to various kinds of connections and servers. Is there any way to solve this problem?

When I click your link above in my browser, it successfully downloads the .m3u file. But when I try to set up the corresponding links within Channels DVR, I get the following:

Screenshot_2

Sounds like cloudflare blocked your VPN IP. It is sometimes a risk when using that. Some of these VPNs are honeypots so using it may not work well with Pluto as it uses cloudflare to detect them

1 Like

Got the same failures when I switched off my VPN and connected with my non-U.S. local ISP internet connection.

You might have to do the old router reset trick to get a new IP...and also clear dns cache

If that doesn't work, that means Pluto don't serve your non-US area

Based on the error you posted above, you are still being routed through DigitalOcean, which is a VPN node. You still have something routing you through there, so once you turn that off, it should work. Who is your native ISP?

Specific IP addresses are not blocked. Only suspicious datacenters that host malicious VPN nodes are. So just 'resetting' a router to get a new IP address is not the solution here.

1 Like

I had so many issues in the past with PIA as a VPN that it's usually always off on my server/HTPC unless I happen to be web surfing or such from the couch. Spectrum cable has annoyed me enough in the past that I refuse to let them have any more data on me than is possible.

Emby and Channels reaching out for data are the only exceptions, and only because on occasion it would fail because of the VPN.

1 Like

The image I posted earlier was an error message I got when using the Digital Ocean VPN server. I tried the same with my native non U.S.ISP connection, and got a similar but non-Cloudflare error error message when trying to set up the links in Channels, saying the linked source couldn't be found.

It was this one:

Screenshot_2