I've sort of worked around the channel lineup issue by changing the channel numbers in tvh/telly so they don't match the Freeview channel numbers; 001 becomes 1001 and so on. It's still buggy with the American channels loading and lineups disappearing, but the manually mapped channels remain after closing the mapping screen.
Was there anyone the ever got it working smooth with Xteve. I was able to add Xteve as a source, and also use the pencil button to manually setup the guide/epg. Everything looks beautiful except the streams will not load. I get the same error in my log the others have mentioned "pipe:: could not find codec parameters"
I have gotten Telly to work with plex in the past but I am having no luck configuring it with Channels DVR today, the telly window will open for a split second and close out, which i know usually happens when it can't find the config file, but I swear i have done everything right. So i got fed up with telly and and now trying to go back to xteve. Any advice would be great.
Disregard my issue for the moment. I think I was using the wrong version of telly. I didn't notice it was mentioned to use v1.1
1 Like
I was able to get everything setup with telly and the web browser version works, but when i try to streaming something from my apple TV i get the "Tuner Not Available" message. Would this have anything to do with the config.toml file settings, or is this just an Apple TV issue?
1 Like
Make sure when you add the tuner in channels you use the ip address and not localhost or 127.0.0.1. Otherwise the client will not be able to find it.
xteve... how did you set it up? Is it working on Channels? I am able to add the home run but it will not pull streams. I do see them in channels but get playback failed.
I am still looking for help...
1 Like
Post the command line arguments you are using.
The config file?
nevermind, I have not used Telly.
Thanks for trying!
what OS? if you have access to a linux box, try running it in docker. i was literally up and running in a docker container in less than 10 minutes...all the docs are there:
https://hub.docker.com/r/tellytv/telly
just use those instructions combined with the telly config file you can find earlier in this thread. should have no issues...at least on linux (and likely mac as well). i can't speak for whether the process is as easy as this on windows, because nothing ever is easy on windows.
also, you will need to add a section to your config file (again, you can find it earlier in this thread) that tells telly where your streams are. in my case, i'm using it for my own 247 channels, so i added this section at the end of the config file...
[[Source]]
Name = "" # Name is optional and is used mostly for logging purposes
Provider = "Custom" # DO NOT CHANGE THIS IF YOU ARE ENTERING URLS OR FILE PATHS
# "Custom" is telly's internal identifier for this 'Provider'
# If you change it to "NAMEOFPROVIDER" telly's reaction will be
# "I don't recognize a provider called 'NAMEOFPROVIDER'."
M3U = "http://192.168.88.232/master.m3u" # These can be either URLs or fully-qualified paths.
1 Like
Yes WIndows 10...
you can try the docker for windows instructions, but like i said i have no idea how easy it is on windows (i'm guessing it's not, because windows). worth a shot, though...if you can get docker running getting the telly container running is cake.
You are guessing right...
1 Like
the biggest problem for majority of people on Earth is that TVE for some unknown reason is only US thing.
Is your script on github or somewhere? I'd like to try getting rid of telly/ffmpeg, if possible 
I was having an issue where the stream would start, then stall 6-10 seconds in, then recover/rebuffer a second or so later. After the rebuffer, it seemed to play without an issue.
Telly logs were showing the below:
Jan 11 17:22:28 media telly[25195]: time="2020-01-11T17:22:28Z" level=info msg="[mpegts @ 0x55b6f36fb940] PES packet size mismatch"
Checking the ffmpeg command that Telly starts, it shows 'ffmpeg -re', however when checking the ffmpeg docs it states:
-re (input)
Read input at native frame rate. Mainly used to simulate a grab device, or live input stream (e.g. when reading from a file). Should not be used with actual grab devices or live input streams (where it can cause packet loss).
As this is a live input stream (TVHeadend in my case), presumably, telly should not be passing -re to ffmpeg.
So I rebuilt telly 1.1 (dev branch), minus '-re' for the ffmpeg command and it seems to have (so far) resolved my issue.
A lot of the documentation for using ffmpeg with IPTV streams to feed into different DVR apps have used the -re flag for inputs incorrectly; I never understood this.
If you are already feeding a live stream to ffmpeg, do not use -re; its primary purpose is to essentially slow down reading the input to real-time. ffmpeg normally reads inputs as quickly as possible; for files stored on disk this is fine. But if you are going to stream those stored files to a DVR, then -re makes sense.
But in the case where you input stream is already set to essentially real-time, then -re at best does nothing, and at worst can totally mess up the stream.
(This was a problem with Tvheadend's pipe type input stream, too. All of their contributed documentation said to use -re ... but if you actually read ffmpeg's docs, you'd know not to use it. This is why "cut-and-paste" solutions aren't great ... you need to read and understand what you're doing, so you can solve problems like this.)
Is there anyway to set a buffer size for IPTV?