Jump to content

Pluto TV xml guide resource


EZEd

Recommended Posts

Sorted it now, Subscribed to Emby to test LiveTV and works great with Pluto TV with the m3u and xml EPG linked above.

Was hoping to get some more IPTV channels with a working EPG, pointless having loads of channels without an EPG, anyone got any links for some (legal ones of course).

One issue and it's not a big issue, but looks nicer if I can, but anyone know how to get the thumbnails showing what is meant to playing or at least a channel logo? Hate the look of coloured thumbs and not the actual cover.

Emby.png

  • Like 1
Link to comment
Share on other sites

mysterio21
On 10/30/2020 at 2:56 AM, sfatula said:

That's what it does without the patch. I suspect you are missing something with the patched version. Why are you messing with segment threads, curious?

I have tried it compiled from couple of repositories:

https://github.com/jjustman/ffmpeg-hls-pts-discontinuity-reclock (This results in AVERROR being thrown "Cannot reuse HTTP connection for different host", tried removing the throw error and just log a warning and still same result)
https://github.com/glenskie16/ffmpeg/commits/master (This still suffers from the buffering between ads etc)

With the segment threads, I saw a post to increase that so it will limit the chance of a buffer (didn't work).

Oddly enough I tried with TVirl with the Live Channels app on an Android TV device and works flawlessly.. (Again this is live viewing, haven't tried recording)

Link to comment
Share on other sites

sfatula

I didn't use any pre-compiled versions, I compiled my own, and as mentioned I think earlier, it was somewhat painful. It was a lot of work, for me at least.

Link to comment
Share on other sites

  • 3 weeks later...
garyan2
On 10/31/2020 at 2:04 PM, GiGo said:

Sorted it now, Subscribed to Emby to test LiveTV and works great with Pluto TV with the m3u and xml EPG linked above.

Was hoping to get some more IPTV channels with a working EPG, pointless having loads of channels without an EPG, anyone got any links for some (legal ones of course).

One issue and it's not a big issue, but looks nicer if I can, but anyone know how to get the thumbnails showing what is meant to playing or at least a channel logo? Hate the look of coloured thumbs and not the actual cover.

Emby.png

You need a better source for your xmltv. Here is what you can get from PlutoTV.

image.thumb.png.c104ef931b087c5aa5df81d918f46f03.png

The movies almost always have coverart. Series images are probably 80% with the plutotv image filling the rest.

Edited by garyan2
Link to comment
Share on other sites

8 hours ago, garyan2 said:

You need a better source for your xmltv. Here is what you can get from PlutoTV.

image.thumb.png.c104ef931b087c5aa5df81d918f46f03.png

The movies almost always have coverart. Series images are probably 80% with the plutotv image filling the rest.

 

That looks great! Can you share the xml you are using for Pluto please?

Link to comment
Share on other sites

garyan2

No, I'm not going to host the m3u and xmltv files. PlutoTV only provides 12 hours of guide data at a time so it would have to be updated continuously. The m3u has a geo tag in it and I would rather not find myself in a position that I am bypassing a company's geographic licenses/lockouts and provide that to the world.

Unfortunately, the xmltv file in the link provided earlier in this thread is rubbish. The xmltv file I create from Pluto that covers 12 hours is 3.4MB with accurate information; the file downloaded in the link is currently 24.2MB. That is because it is filled with bogus programs from I don't know where. It may look like it fills the guide, but only the first 12 hours from its' creation time is accurate. Also, as you can see, there is missing information like images.

The program I developed to create the m3u and xmltv files preserves the geo tag functionality (the geo long/lat coordinates will reflect the location where the program was executed), but I'm not clear if I am violating any terms of service so haven't shared it out.

If you want a better xmltv file from techzyon, then you can contact them and request they improve their software.

  • Like 1
Link to comment
Share on other sites

9 hours ago, garyan2 said:

No, I'm not going to host the m3u and xmltv files. PlutoTV only provides 12 hours of guide data at a time so it would have to be updated continuously. The m3u has a geo tag in it and I would rather not find myself in a position that I am bypassing a company's geographic licenses/lockouts and provide that to the world.

Unfortunately, the xmltv file in the link provided earlier in this thread is rubbish. The xmltv file I create from Pluto that covers 12 hours is 3.4MB with accurate information; the file downloaded in the link is currently 24.2MB. That is because it is filled with bogus programs from I don't know where. It may look like it fills the guide, but only the first 12 hours from its' creation time is accurate. Also, as you can see, there is missing information like images.

The program I developed to create the m3u and xmltv files preserves the geo tag functionality (the geo long/lat coordinates will reflect the location where the program was executed), but I'm not clear if I am violating any terms of service so haven't shared it out.

If you want a better xmltv file from techzyon, then you can contact them and request they improve their software.

Fair play mate. I'll have a poke around and see what I can find.

Link to comment
Share on other sites

  • 4 weeks later...

Hello guys, 

I also love to watch pluto tv and due to the reported issues I patched the latest ffmpeg version and replaced the emby version with this patched one. Well pluto tv works nicely now, but the only thing is that emby is not able to choose the highest stream bitrate. it just uses the first stream from the playlist file. also no transcoding throttle is possible after the patch. So are there any work arounds to let emby choose the highest bitrate from the offered HLS streams from pluto tv?

I would also appreciate when emby is going to patch this force_dts_monotonicity into the emby-ffmpeg-version. I also do not understand why ffmpeg is skipping these EXT-discontinuity tags, but this is the wrong place here to discuss ;o)

Link to comment
Share on other sites

Not possible in the current Live TV implementation. The new version of Live TV in development will have features to allow for this.

 

Link to comment
Share on other sites

However,  the current versions of Channels DVR supports M3U playlists and handles HLS streams and the discontinuity there perfectly.  Works GREAT with Pluto - plays and records perfectly.

Then i use channels DVR as a source to serve up Pluto and everything else to Emby because I like the Interface of Emby so much better.

 

Check out these posts

https://getchannels.com/docs/channels-dvr-server/how-to/custom-channels/
or
https://community.getchannels.com/t/beta-custom-channels-via-m3u-playlists/24545
or
https://community.getchannels.com/t/pluto-tv-and-stirr/24875
and
https://community.getchannels.com/t/add-pluto-with-custom-channels/24870

Finally, one of the developers over there as created a docker image  that will got out an scrape Pluto for the channels and guide data  and serve them up via http  as a m3u and XML files.   THey work well with ChannelsDVR  and worked fine with Emby.
https://hub.docker.com/r/jonmaddox/pluto-for-channels
I am running the docker container on the same Win10 system as my Emby server with Docker Desktop.  I have considered moving it over to a Raspberry Pi  because I have not been able to get it to autostart the docker container  on WIn10 Docker Desktop.
 

As far as ffmpeg and discontinuity  and hls streams  I wonder if the  ffmpeg included with ChannelsDVR might help?

Regards,

Scott

  • Like 1
Link to comment
Share on other sites

I doubt it. The current version of Emby has all streams going through ffmpeg on the front side where Channels DVR does not.  The new version of Live TV will be similar in that ffmpeg isn't used on the front side.  ffmpeg will basically only be used on the backside when sending to clients that need remuxing or transcoding.

Link to comment
Share on other sites

  • 4 months later...
Jimmy1964

Hello All, I just joined Emby, I have Channels-DVR and would like to use that as a live tv source, is there a guide available on how to set that up? I appreciate any help, Thank you 

Link to comment
Share on other sites

Hi, Follow this thread which lays it pretty clearly.

 

Edited by cayars
Link to comment
Share on other sites

emveepee

If you use the NextPVR Extra for PlutoTV most of the discontinuity errors are fixed because it goes

PlutoTV -> streamlink -> NextPVR You could then use the NextPVR addon to get these  into Emby.

This Extra can also do XMLTV update on a scheduled basis since user may want to do it more than once a day.  This is a special update that doesn't impact all tuners, so in NextPVR it is pretty quick, unfortunately Emby will only do a full update so it could end up being slow and obtrusive.

Martin

 

 

Edited by emveepee
Link to comment
Share on other sites

  • 1 year later...

I'm not sure there is anything Emby can do about this as it has to do with the format of the streams themselves and the way they just arbitrarily cut in with commercials.

Link to comment
Share on other sites

sfatula
17 minutes ago, cayars said:

I'm not sure there is anything Emby can do about this as it has to do with the format of the streams themselves and the way they just arbitrarily cut in with commercials.

Why? As posted long while back in this thread, Kodi patched discontinuity flag into ffmpeg long ago and it works fine. I had compiled ffmpeg myself with the discontinuity patch and it also had worked fine. So, why do you imply there is nothing Emby can do?

Link to comment
Share on other sites

It's been a long time since I tested this, but I seem to recall adding the discontinuity patch fixed this but caused other problems. Based on the fact the path has been available for 4 years yet still not part of ffmpeg likely means others found issues caused by this as well.

I personally don't think it would be a good idea for Emby to include this patch when it's been available for 4 years and still not part of ffmpeg.  Something not right about that.  If we were to include the patch, we would need to basically test all functionality of ffmpeg which isn't an easy thing to do with so many possible ways it could interfere or cause problem.

Thats what I meant by, "I'm not sure there is anything Emby can do about this".

Getting this path included in ffmpeg itself would be the way to go as there is a huge userbase of testing.

What follows is my personal opinion and not anything official.

To the best of my knowledge the only streams having this issue are the Pluto streams. These streams aren't endorsed by Pluto for use outside their platform and have been hijacked using different techniques which are likely violations of their TOS. Given that and how complex the ffmpeg pipeline already is, plus our existing modifications, the risk/reward for adding a patch like this doesn't seem like a good idea, especially if it could break many other things. Maybe we could build an experimental build that could be used as a ffmpeg replacement for those willing to test.  Then we could take it from there based on how smooth testing goes.

Perhaps the best thing overall is to run a docker setup that could be used with a patched ffmpeg only being used for this purpose, then feeding that to Emby. I believe this already exists.

 

  • Agree 1
Link to comment
Share on other sites

sfatula
3 hours ago, cayars said:

To the best of my knowledge the only streams having this issue are the Pluto streams. .

 

I could recall wrong, but, I thought Stirr also had issues. I do know Streamlink was super reliable for this purpose. I was just objecting to "anything". All Emby users certainly would not need this. I believe it is RFC-8216.

Link to comment
Share on other sites

I don't have ChannelsDVR, and can't see paying $8/month ($80/year) just to get Pluto with Emby...

But I did get Pluto to work correctly with Emby, using xTeVe as an intermediary -- with a couple minor issues.

Your mileage may vary with this, as I've found it requires a very specific setup to get it to work properly.

 

  • Set up a virtual machine, running Fedora 37, with 1(!) virtual CPU (with one core).
    • Multiple cores result in video/audio sync issues, that the system never corrects on its own, after Pluto "commercial breaks".
  • Set up a docker container running Pluto-for-channels
    • (optional) In order for xTeVe to use this, and automatically link the epg to channels, you need to edit the index.js inside the docker.
      • Change "channel-id" to "tvg-id" in the section that creates the m3u8 file.
    • (optional) For whatever reason, even though episode identifies are in the resulting epg from xTeVe, Emby can't figure out the correct episode numbers of programs.  So I also edited the index.js file to add the episode to the program name (after this change, Emby will figure out the episode data)
    • (optional) Also in the index.js file, changed `.replace(""", "")` to `.replace(.replace(/(")/g, "")` in parsing the channel.summary.  Otherwise there can be instances of `"` getting into the resulting guide descriptions that confuse xTeVe.
    • (optional) Edit the cron inside the docker to run every 1.5 hours (defaults to 3 hours)
  • Set up another docker container of the dnsforge/xTeVe image.  None of the others appear to work correctly for Pluto with Emby.
    • Direct it to get all your m3u and epg, for Pluto, from the Pluto-for-channels docker instance.
    • Number of tuners probably doesn't matter, but I set it up for 10 tuners, with 6 coming from Pluto.
    • Set it to use the VLC stream buffer.
      • set the buffer size to .5MB
    • Set updating schedule to every 4 hours.
    • (optional) Turn off automatic update of xteve (probably doesn't matter)
    • (optional) Edit the /bin/xteve_starter.pl file inside the docker to delete both the /xteve/conf/urls.json and /xteve/conf/xepg.json files on startup.
      • This, however, does create an issue with Emby in that the channel numbering may change.  So, you may not want to do this.
  • Set up a tuner and epg source in Emby, using the xTeVe docker as the sources.
  • Change the Refresh Guide Emby task to run every hour.


The caveats

  • xTeVe channel list grows every time it updates the channels/epg -- duplicating channels each time.
    • First run puts it at about 350 channels.  After a couple days, it's up to just over 1000 channels (After a couple days, it doesn't grow much anymore).  This also causes Emby to add channels each time -- if anyone finds a solution for this, please let me know.
      • The optional additions to the xteve_starter.pl file bring it back down to the original 350 channels on a restart...  But that requires restarting that docker container periodically, which can cause other issues (it'll stop any livetv or recording)
    • Audio/video sync can still, on occasion, be slightly off after a commercial break.  But it's negligible, and always (so far) corrects itself after a few moments.

 

EDIT:  I haven't tested it well yet, but it may work better, overall, if you do NOT do the optional changes to the /bin/xteve_starter.pl file, and if you do NOT change "channel-id" to "tvg-id" in the index.js file (and initially manually map the channels in xTeVe, or change "tvg-id" back to "channel-id" after the first run of xTeVe).  This MIGHT eliminate the duplicate active channels in xTeVe/Emby without any long-term issues.  But I haven't done any long term testing that way yet.

Edited by UCM_1
Link to comment
Share on other sites

I think you're going to find it really doesn't fix the problem, but you've been getting lucky with your testing.

What you describe has been done many times before by others who at first think they solved the issue.

What I'd suggest if you want to be sure you solved the issue is to find a problematic channel. Rename the station in one m3u file so you have an original version and the version setup like you describe.  You can skip loading guide info and just setup some manual recordings to cover 24 to 48 hours recording from both channels at the same time.  You'll be able to quickly compare the two channels at the file system level.

Many of the Pluto channels are available from other sources which allows you to access those from alternate sources that don't have the issue.

Link to comment
Share on other sites

  • 1 month later...
daethlor

Your mileage may vary, but here is an edited script I did just because I was curious if it would work.

https://github.com/daethlor/PlutoTVforEmby

I am able to stream PlutoTV through Emby directly and even schedule recordings.  Since Pluto does a stitched together stream with ads interspersed it doesn't flow from one stream to the next.

In the end, it's better to use the PlutoTV app and website.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...