I have all my channels in Xteve changed to mimic the DirecTV channels that we are used to. Problem is I can't use xteve with channels dvr
that's literally the exact reason i wanted the ability to change channel numbers from within channels. my current plan (and this is at least a month out probably, depending how much time i have to work on it)...
- implement the ability to change channel numbers in fHDHR
- fork fHDHR and allow it to use channels as an input
- run a second channels server with the fHDHR from channels feeding it with the updated channel numbers
step 1 i hope to be able to do this weekend, steps 2 and 3 are a little bit more involved i think.
Can you use fHDHR with any source? Fubo, Philo, Hulu etc?
as of now, no...could you implement it yourself? i suppose, but that would be a ton of work. hence why i wanted to just do one additional implementation (allow it to use channels as a source), and then use the fake HDHR created by that to feed a second channels instance. theoretically that would allow us to modify the channel numbers on the back end before they're fed into that second channels instance. the first channels instance would be there only to supply all the TVE channels to fHDHR, nothing else really...
I'll ask the author.
@crackers8199 made an account to reply, channel number swapping via the webUI is already on my todo list!
Mythtv and channels as inputs are also on the backburner list.
@shdwkeeper if there is an API for a service that is semi-usable without resorting to weird methods, it can be an input. I spent a good amount of time making it easy to swap the 'origin' channels source. I even built a wrapper around the channels infrastructure to create a channel number for 'origin' sources that don't have things like channel numbers.
One of the repos is written for my wife, and scrapes the guide information from a PDF file!
I also have a semi-working version for youtube that needs some attention, it's very feasible to take playlist ID's and create a program guide.
1 Like
Additionally, since these use ssdp for service discovery, I created a system to 'cluster' fHDHR instances together for easy management.
i planned to try to work on it this weekend, but you'd probably be able to get it done quicker than me. either way i'll see what i can get done and go from there...
@crackers8199 the hard part that I have to figure out is an internal ID system. For instance with the NextPVR version, I use the alternative zap2it epg method, which has it's own ID system. The Locast repo also includes zap2it as a method, and I need to make it so rmapping works for everything fluidly
i think i'm gonna leave this to you lol...i've taken a cursory look at it and i'm not sure i'll be able to make this work without completely mangling it. like i said, python isn't my language of choice...so i'm trying to figure it all out and work my way through python at the same time.
If telly stops running because server maintenance whatever, I have to readd it as a source. is this normal behaviour
I would love a way to get this working in channels. Any thoughts?
FYI: we will be deprecating there Telly integration in the future. It has never worked reliably and been a source of constant headaches.
Unfortunately the emulated HDHR approach is simply not technically sustainable. Our DVR server has very strict assumptions about how HDHRs behave, based on five years of code written and tested against real HDHR devices. Instead of fighting the code at every step and risking breaking actual HDHR support in the process, we have decided to go in a different direction. We will be providing an alternative interface for integration and will have more to share about it soon.
6 Likes
so now that i finally have a way to get locast OTA channel numbers into the app you're telling me it's not going to work anymore?
that's incredibly frustrating.
maybe it's just me, but i don't think anyone was asking you to change your HDHR implementation to try to support emulated devices...all the majority of us want is a way to get our own guide into the DVR if we provide one via XML. granted i don't know the inner workings of the DVR, but it seems that you clearly have the ability to allow us to enter our own guide, based on the beta program that has been in place for almost a year. it's just not turned on for everyone.
i don't understand how just allowing everyone to use that would break anything involving the HDHR implementation...
We don't intend to break anyone's setup. What you have will continue working, but deprecated means we're not able to improve it or provide support.
1 Like
fair enough, but can i ask what the hesitation is in just allowing everyone to import or provide their own guide data? there are a ton of valid use cases for that at this point, from someone running their own channels with their own media to something like using fHDHR to get pluto or other streams into the DVR.
in the week or so i've been using fHDHR, it honest to god just works. it is nothing like the sh*t show that was telly and xteve, which i literally messed with for months and never got to work well enough to use it...fHDHR was literally five minutes to get up and running, and then use the HD homerun option in channels to add the source. done. the dev has stated his goal is to make sure that what it outputs is as close as possible to what the actual HDHR outputs, so in theory it should just work as is with no need for you guys to change anything (aside from the aforementioned potential guide data issue).
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.
5 Likes
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.
1 Like
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.
1 Like
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. 