There is no hesitation, and we're not purposefully holding back features. There are simply bugs which make it not work as expected, and its not worth our time to try to track them down in this part of the code.
The new system will make this all a lot simpler and you can set up whatever guide source you want with it.
It's very, very difficult to defensively program against data you have no control over. I don't know the developers but I do have a rather popular open source program. Some of the biggest headaches come from having to sanitize others data, to think like an adversary to anticipate how others may act badly to intentionally cause systems to crash. Any time you open to outside input you're adding a lot more work to make it "just work".
You may be of the best intentions and have data that is in the exact format that the API consumer can use, but you can't depend that everyone will be the same.
Remember little Bobby Tables.
Seconded. I've been working on a tool for my own use to munge M3U files from providers into something more sensible - automatically, since I've become tired of the constant maintenance required when using iptveditor or 'EPG for IPTV'. M3U files are anything but static.
Both M3U and XMLTV are interpreted somewhat 'loosely' by some providers, and it's hard to code something that 'just works' without user intervention when fed with some of the 'creative' interpretations you're presented with. Some of the metadata I want to extract (e.g. country of origin, resolution) are often only found in the group title or channel title, and not always strictly correct (SD/HD/FHD in a channel title vs. the group title it's in, US channels appearing in Canadian groups, etc.) Then there's the fun and games of trying to make sense of the same stream appearing under different channel names in different groups, fun stuff like making sure that 'BBC 1' and 'BBC One' are seen to be the same, but different from 'BBC 1 Scotland' etc.
None of these particular examples are that difficult to solve individually, but the sheer number of them, and the possibility of the solutions to one problem interacting with another, make the goal of it just doing 'the right thing' every time surprisingly difficult. And I haven't even gotten to the issues with how many different ways are used to identify local channels. I'm still pondering if there's an automatic way I can reliably map M3U streams to EPG listings - it's not looking that promising, even after I've canonicalized the station name to something somewhat consistent.
LOL. I hear you. I finally arrived at a standard m3u format that gets me 100% EPG match on locals and about 95% on network/cable stations. This entire space is a mess. Targeting Emby only reduced the complexity but supporting any and everything would require and ISO standard. 
fair enough. looking forward to it!
This is awesome! Thanks.
What would be even better if we could use the custom url for guide data as we can with a normal HDHR device:
However it's not there right now:
You're looking at screenshots of two different places. The option is available in the same place as the first screenshot.
I know this how it looks at the homescreen:
Notice with the real hdhomerun device I have a button "Pick Guide Provider", that is not available with the M3U provider
Aaah I figured it out. I first had to delete the current (automatically?) mapped guide data.
Thanks for the quick reply.
Trying to get fHDHR running in Channel but no luck (works fine in Plex)
Get traceback error
AttributeError: 'NoneType' object has no attribute 'lower'
which fhdhr?
fHDHR for Locast in Ubuntu 20.04
within Channels DVR, I can receive the channel listings but it will say "Tuner not available" with the traceback error
Issue appears to be only in Channels, no issue with receiving the stream in Plex
I bet AI could do it...maybe some one can make a Little program and plug it in to the online Quantum computer, You guys know they are letting people tinker with them right? Since the cooling it takes is far to expensive for consumer use. Unless you are Lockhead Martin , Google, Amazon, etc. you werent getting near one og those suckers. Now, Any one can mess around with them. Pretty cool in my book, and something so mundane and irratating as telling the differences and similarities between BBC one, BBC 1, BBC one America, BBC one Scotland x's ad nearly infinum..... well that sounds like an excellent task for a computer build for determining a multitude of possibilitiies all at one. Not to mention grat practice for it before it goes on to solve more trivial human problems, like death and why is there Whoopi Goldberg? Its like what is the point of...that? Ps this community is awesome. Thanks to all for the great contributions. Its been a marvel to watch this thing grow. I became a paying sub before I even used it because I had hoped it would grow into something great,. Now its my dai;y driver, not quite yet where Id like it nut getting closer all the time. iN LARGE PART BECAUSE OF THE OPEN SOURCE SPIRIT AND FREEDOM OF TINKERING! oops sorry for the caps.
Hi @imx Would you know is it possible to remove the -re from a Windows install of Telly?
Everything works great for me but just the slow tuning times on Sat>ip to telly. Thanks.
This change/fix was merged into the dev branch and under release telly v1.1.0-Beta7, latest being Beta8,
Thank you @imx
I do have the latest version so it seems like that’s not my problem after all.
Maybe this would solve it:
Not sure how I can get that option before the release though?
Or I might just have to go down the TVH route or wait for native sat>ip support to improve.
I went back to using TVHeadend, then exporting the M3u from TVH to Channels - it has a number of benefits for my setup, channel tuning speed being one of them. TVH has a LOT of tweaks and various enhancements for Sat>IP generally, as I seem to recall a lot of devs used it.
Whilst I know a few people have put out M3Us to be used directly with a Sat>IP box, it's just a bit of a faff to manage - at least with TVH I can rescan, move channels around (as I just had to do with the removal of ITVBe+1), then click 'reload M3U' in Channels.
Yes you are probably right. I don’t mind editing the m3u with the channel changes. Don’t have to do it too often but I can see the benefits of TVH. I was thinking of adding it as a source with an old Pi I had and the it could fall back to the old method if there was any trouble with it. I probably would have to run 2 instances of telly then maybe.
I’m lucky it’s only a minor annoyance of waiting an extra couple of seconds for channel changes. Thanks again.
You don’t have to run any Telly instances with TVH? I just add the TVH m3u export direct to channels.
http://tvheadend-server:9981/playlist/channels.m3u
… reading your posts above you mention you’re using an m3u direct from your sat>Ip, to telly. But Channels can read an m3u natively these days? So there should be no need for telly in this situation? 
