Closed theflu closed 6 years ago
This is a new one. Will investigate!
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.
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.
Same here
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.
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
Who are peoples IPTV providers? Is this just vaders?
@theflu could you share your nginx config?
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
}
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.
@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.
@EnorMOZ yeah, thanks but thought about posting it here in case other people is having the same issue.
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.
@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.
@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
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
Was wondering if anyone would be willing to explain the workaround with nginx a little more? include the python script if possible.
I would also appreciate it if someone could provide more clarification.
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
}
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.
@HazCod yep that seems like the best idea, base64 the urls
I will implement this next week.
Edit: can you guys try out this build ? base64-builds.zip
what's the change here @HazCod - if you mind to quickly explain and what's the test to get done?
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. :-)
Sounds like a plan
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.
I see the issue, will fix in 1 hour
Awesome. Thanks.
Try again with this one, this emmits the query parameter when parsing;
Edit: you will need to add an additional -encode
parameter.
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
@12nick12 you will need to add a -encode
parameter as wel now, sorry.
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.
Some channels still don't work tho "telly[23324]: [telly] [error] Invalid base64: aHR0cDovL3ZhcGkudmFkZXJzLnR2L3BsYXkvNTc4NDIudHM"
I think the above is because they're preforming maintenance.
What is the original channel url? Try posting your logs as wel.
@12nick12 please change the password you are using for your provider.
@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)
})```
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)
}
})
@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
.
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
My mistake, I did not account that base64 could still contain slashes. Can you try this build, @12nick12 ?
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 .
Seems to work like a charm. Time to change my password again lol
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
@haxcop try out the previous build (base64-builds4.zip) as this encodes the whole streaming URL, so should solve that problem as wel.
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.
@tombowditch perhaps we should turn this on by default?
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?
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
.
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!
I'll 🔒 this now so we can keep track of issues.
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.