tellytv / telly

An IPTV proxy
MIT License
770 stars 107 forks source link

Unable to tune channel (Timed out) #77

Closed theflu closed 6 years ago

theflu commented 6 years ago

The problem I am having is that plex adds "?transcode=none" to the end of TS URL. My providers TS URL already has get variables in so by adding that is breaks the URL because it has 2 question marks in it.

tombowditch commented 6 years ago

This is a new one. Will investigate!

theflu commented 6 years ago

I created a custom solution with nginx and python. A python script changes the URLs in M3U to point to nginx, then nginx redirects to the correctly formatted providors URL.

IllMethods commented 6 years ago

I keep getting this issue too, not sure if it is the same exact problem, but my channels are all working fine if I try to play them through the iptv plugin.

It can see that the channels are there, but when I click on play it just says that it is unable to tune them.

haxcop commented 6 years ago

Same here

Latiron commented 6 years ago

I grabbed an older version of Plex and after I uninstalled the latest version that was installed, I installed it. It's Version 1.10.1.4602. When I went to add the Telly Tuner, it did teh same thing as the newest version. It see's the SiliconeDust Tuner for a moment, and then after a few seconds, it disappears. I can still click on continue, and it will finish the rest of the setup, It see channels and starts loading the EPG. However, when I click on a channel, I get the same unable to tune channel message.

EnorMOZ commented 6 years ago

I have a Plex forum thread opened up regarding this. Lets see if it gets any movement. https://forums.plex.tv/discussion/315238/plex-is-appending-transcode-to-transcoder-url#latest

tombowditch commented 6 years ago

Who are peoples IPTV providers? Is this just vaders?

@theflu could you share your nginx config?

theflu commented 6 years ago

My m3u import script changes the URL to something like this: (the number is the ID of the channel)

http://localhost:8080/1234

This is my nginx config: ($1 is the channel ID)

server {
    listen    8080;

    rewrite ^/(.*)$ http://providor.tv/play/$1.ts?token=usertoken
}
cesalo commented 6 years ago

I'm also having issues. Plex is adding a transcode parameter but that works in VLC. In Plex is showing an error and fails.

http://xxxxx.tv/live/xxxxxx/xxxxx/2442.ts?transcode=none

Mar 27, 2018 16:29:43.774 [0x7f2ad13fe700] DEBUG - Completed: [172.17.0.5:59626] 200 GET /status/sessions (11 live) 3ms 8874 bytes (pipelined: 1) Mar 27, 2018 16:29:44.509 [0x7f2a387ff700] DEBUG - Activity: updated activity 725cf4a4-9085-46ec-acf6-e53920ff082f - completed 10% - Recording Mar 27, 2018 16:29:44.540 [0x7f2a407fb700] DEBUG - Using default transcode duration of 120 minutes Mar 27, 2018 16:29:44.540 [0x7f2a407fb700] DEBUG - Started session successfully: 7aaec506-87f9-40a6-9783-97448b594cec Mar 27, 2018 16:29:44.541 [0x7f2a407fb700] DEBUG - DVR:Recorder: It took 30.0 sec to start the session for http://xxxxx.tv/live/xxxxxx/xxxxx/2442.ts?transcode=none Mar 27, 2018 16:29:44.541 [0x7f2ac33ff700] DEBUG - Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 10342 is 1 Mar 27, 2018 16:29:44.541 [0x7f2a407fb700] DEBUG - DVR:Grabber: Merging EPG item with live item. Mar 27, 2018 16:29:44.541 [0x7f2a407fb700] ERROR - DVR:Recorder: No part because session isn't reporting one. Mar 27, 2018 16:29:44.542 [0x7f2ac33ff700] DEBUG - Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 10342 is 1 Mar 27, 2018 16:29:44.542 [0x7f2a407fb700] DEBUG - DVR:Grabber: Operation for Live TV - Session completed with status error (Could not start recording) Mar 27, 2018 16:29:44.542 [0x7f2a407fb700] DEBUG - Activity: Ended activity 725cf4a4-9085-46ec-acf6-e53920ff082f. Mar 27, 2018 16:29:44.543 [0x7f2a407fb700] DEBUG - DVR:Grabber: Cleaning up rolling grab for channel 1202. Mar 27, 2018 16:29:44.543 [0x7f2a407fb700] DEBUG - DVR:Recorder: Asked to stop recording 'Live TV - Session'. Mar 27, 2018 16:29:44.543 [0x7f2a407fb700] DEBUG - DVR:Recorder: Stopping transcode session.

EnorMOZ commented 6 years ago

@cesalo, It might be related in the sense that Plex is appending that parameter but the main issue here is the double ? parameter which will break things for sure.

cesalo commented 6 years ago

@EnorMOZ yeah, thanks but thought about posting it here in case other people is having the same issue.

north3221 commented 6 years ago

First off, kudos to the devs on this. Awesome work guys!

I have the same issue with the extra query param for ?transcode=. I was thinking about something similar to @theflu for a workaround. However it would be better for the fix to be in either Plex or Telly.

Having looked at the plex thread, they have basically said no, we don't support IPTV for the DVR. Not ideal, but leaves Telly being the best place.

I don't have time to look at a PR now, nor to learn Golang right now. I'll take a look in a couple of weeks if no-one else gets chance.

My theory here is just have telly remove all query params when sending to Plex and add back in on way back. Assume this means a change to the way Telly current works as looks like it just servers up the url and Plex is hitting the stream directly. So would need some local caching to replace the url with the local Telly one, could add a custom cache id at that point, plus remove the query params.

Then when plex calls back with that url, redirect to correct url, adding in the query params from cache, obviously checking for existence of query param from Plex and using & instead of ? for ours to add back on if needed.

Could one of the devs at least come back as say if this is something you would consider? Clearly if you don't want to change the engine like this, there is no point in a PR coming and we need to go for a separate solution like theflu came up with.

hazcod commented 6 years ago

@tombowditch perhaps we can encode our stream URLs to base64 and point them to telly? So streaming a file will return to /stream/<base64> and then we return a redirect to the decoded URL?

I did it this way in muxy.

haxcop commented 6 years ago

@HazCod Using http://vaders.tv/get.php?username=xxxx&password=xxxx&type=m3u_plus&output=ts will be a workaround - Just need to then remove the :80 from the m3u streams - This could be archived with a rewrite rule as @theflu did with the Token with the request http://api.vaders.tv/vget?username=r&password=xxxx&format=ts

north3221 commented 6 years ago

I just thought I'd give myself a little time to try with ngnix as per @theflu to see if I could get it up and running. Never used it before, but as theflu already have the regex server setup it was pretty easy. Only having to debug the redirect going to the wrong url.

In my case I dont need the .ts $1 already has the stream id and .ts (my fault as didn't include it in the find replace on the .msu file.

Works well guys! Great work.

Will remove ngnix if you implement the base64 and redirect solution mentioned

WaechterGit commented 6 years ago

Was wondering if anyone would be willing to explain the workaround with nginx a little more? include the python script if possible.

12nick12 commented 6 years ago

I would also appreciate it if someone could provide more clarification.

theflu commented 6 years ago

Here is the workaround I am using.

Python script to modify the playlist:

#!/usr/bin/python3.5
import os
import requests

m3u_url = 'http://providor.tv/?someother_stuff=here'
save_file = 'playlist.m3u'

req = requests.get(m3u_url)

req_text = req.text

lines = req_text.splitlines()

with open(save_file, 'w') as m3u_file:
  for line in lines:

    if line.startswith('http'):
      split_line = line.split('play/')
      split_line = split_line[1].split('.ts')
      m3u_file.write('http://localhost:8080/'+split_line[0])
      m3u_file.write("\n")
      m3u_file.write("\n")
      match = False
    else:
      m3u_file.write(line)
      m3u_file.write("\n")

Nginx Config

server {
    listen    8080;

    rewrite ^/(.*)$ http://providor.tv/play/$1.ts?token=usertoken
}
theflu commented 6 years ago

I don't think this would be that hard to implement into telly, but I don't know go. This is how I would do it.

  1. add a cli option to enable the feature
  2. parse the playlist (either put the urls in a DB with a id or just add the url one per line to a txt file)
  3. while parsing, after adding the url to DB or txt replace the url in the playlist with telly http://telly-address/id (id would be either the id from the row in the db or the line number in the txt file)
  4. when a request comes in get the and look it up in the DB or grab that line number and redirect to that url
tombowditch commented 6 years ago

@HazCod yep that seems like the best idea, base64 the urls

hazcod commented 6 years ago

I will implement this next week.

Edit: can you guys try out this build ? base64-builds.zip

haxcop commented 6 years ago

what's the change here @HazCod - if you mind to quickly explain and what's the test to get done?

hazcod commented 6 years ago

In this build, the stream URLs given by telly all point to telly itself. e.g. http://telly:6077/stream/yyyy instead of http://iptv.provider.com/xxxxx. And when Plex connects to http://telly:6077/stream/yyyy, it receives a redirect to http://iptv.provider.com/xxxxx. (yyyy is the encoded form of http://iptv.provider.com/xxxx) So it does not matter what arguments Plex inserts to the URL, we will always redirect to the one we specified.

To test, try it out with Plex to see if this works. :-)

IllMethods commented 6 years ago

Sounds like a plan

12nick12 commented 6 years ago

When I try to start a stream with this version I get a "[telly] [error] Invalid base64: aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNzk0NC50cz90b2tlbj1leUoxYzJWeWJtRnRaU0k2SW5WelpYSTBNRFV6TWpVaUxDSndZWE56ZDI5eVpDSTZJazVsTURkelNXUmFjM2dpZlE9PQ==?transcode=none" I decoded this using an online decoder and it didn't resolve into the correct URL. It didn't resolve the double == correct.

hazcod commented 6 years ago

I see the issue, will fix in 1 hour

12nick12 commented 6 years ago

Awesome. Thanks.

hazcod commented 6 years ago

Try again with this one, this emmits the query parameter when parsing; Edit: you will need to add an additional -encode parameter.

base64-builds2.zip

12nick12 commented 6 years ago

That doesn't work either. It doesn't even start the pulling of the channel. Here;s a screenshot. https://up.5link.cc/zzsk8k75.png

hazcod commented 6 years ago

@12nick12 you will need to add a -encode parameter as wel now, sorry.

12nick12 commented 6 years ago

Yup it works with the encode. I still get a little buffer at the beginning, but after that it works just as before. Thank you.

12nick12 commented 6 years ago

Some channels still don't work tho "telly[23324]: [telly] [error] Invalid base64: aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNTc4NDIudHM"

12nick12 commented 6 years ago

I think the above is because they're preforming maintenance.

hazcod commented 6 years ago

What is the original channel url? Try posting your logs as wel.

EnorMOZ commented 6 years ago

@12nick12 please change the password you are using for your provider.

theflu commented 6 years ago

@HazCod This might be what you are looking for.


mux := http.NewServeMux()
mux.HandleFunc("/path", func(w http.ResponseWriter, r *http.Request) {
    // your handler code
})

...

rewrite := func(path string) string {
   // your rewrite code, returns the new path
}

...

// rewrite URL.Path in here before calling mux.ServeHTTP
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    r.URL.Path = rewrite(r.URL.Path) 
    mux.ServeHTTP(w,r)
})```
theflu commented 6 years ago

I don't know go but I took a stab at it.

main.go @152

func base64StreamHandler(base64StreamUrl string) {
    log("debug", "Stream base64: " + base64StreamUrl)

    decodedStreamURI, err := base64.StdEncoding.DecodeString(base64StreamUrl)
    if err != nil {
        log("error", "Invalid base64: " + base64StreamUrl)
        return false
    }

    log("debug", "Redirecting to: " + string(decodedStreamURI))
    return decodedStreamURI
}

main.go @ 334

    h.HandleFunc("/stream/", func(w http.ResponseWriter, r *http.Request) {
        u, _ := url.Parse(r.RequestURI)
        uriPart := strings.Split(u.Path, "/")[2]
        decodedUrl := = base64StreamHandler(uriPart)

        if decodedUrl == false {
            w.WriteHeader(400)
        } else {
            r.URL.Path = decodedUrl
            h.ServeHTTP(w,r)
        }
    })
hazcod commented 6 years ago

@12nick12 can you try this build (more logging) and give me the full log when the channel isn't working? Also, change your provider password afterwards. (again) Specifically, I'm looking for the log line saying Parsing URI x to y.

base64-builds3.zip

12nick12 commented 6 years ago

Apr 10 10:59:37 Plex telly[12170]: [telly] [debug] Parsing URI /stream/aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNDA4NzgudHM/dG9rZW49ZXlKMWMyVnlibUZ0WlNJNkluVnpaWEkwTURVek1qVWlMQ0p3WVhOemQyOXlaQ0k2SW1jd1oyTjFOemxtTWxocWRITjNVSGQ0UldVMFRXbEJTa2haUVdSelZsbFBSVVJpSW4wPQ==?transcode=none to aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNDA4NzgudHM Apr 10 10:59:37 Plex telly[12170]: [telly] [debug] Stream base64: aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNDA4NzgudHM Apr 10 10:59:37 Plex telly[12170]: [telly] [error] Invalid base64: aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNDA4NzgudHM: illegal base64 data at input byte 44

hazcod commented 6 years ago

My mistake, I did not account that base64 could still contain slashes. Can you try this build, @12nick12 ?

base64-builds4.zip

12nick12 commented 6 years ago

I will once I get home.

On Tue, Apr 10, 2018, 4:57 PM HazCod notifications@github.com wrote:

My mistake, I did not account that base64 could still contain slashes. Can you try this build, @12nick12 https://github.com/12nick12 ?

base64-builds4.zip https://github.com/tombowditch/telly/files/1896397/base64-builds4.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tombowditch/telly/issues/77#issuecomment-380244067, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ-gRUx25cLGZmqnn0-aXa93rIsobZLkks5tnRywgaJpZM4S2KyI .

12nick12 commented 6 years ago

Seems to work like a charm. Time to change my password again lol

haxcop commented 6 years ago

O right then, so this will help to solve the token issue on Vader’s any other provider that does the same with the streams, now... Vader’s VOD dile adds no token but it adds ‘:80’ which it also gives the same bug, and the solution is to eliminate that string from it. Could this also be implemented in this build? I’ll be happy to test out if you need me :) @hazcod

hazcod commented 6 years ago

@haxcop try out the previous build (base64-builds4.zip) as this encodes the whole streaming URL, so should solve that problem as wel.

12nick12 commented 6 years ago

This new encoded version of telly seems to fix the buffering I was having. Originally Telly would buffer for the first couple minutes then it would start playing nice. Now it just starts with no problem.

hazcod commented 6 years ago

@tombowditch perhaps we should turn this on by default?

tombowditch commented 6 years ago

Great work, @HazCod - yes, I believe we should make it by default. Maybe it's worth having an -originalurl option to not use the base64 URLs and instead the URLs provided via the m3u?

hazcod commented 6 years ago

Just for your information guys, next release will have this turned on by default, so no changes required on your end! You can disable this behaviour by specifying -direct.

tombowditch commented 6 years ago

All released on Docker & GH @ https://github.com/tombowditch/telly/releases/tag/v0.5

@theflu @IllMethods @Latiron @cesalo @WaechterGit @north3221 @EnorMOZ - please try it ;-) Report back in a new issue if you have any issues please!

tombowditch commented 6 years ago

I'll 🔒 this now so we can keep track of issues.