Does anybody know which API is used to control the HDHomerun device, udp or http?

Yes, the Channels app now discovers my proxy as a HD Homerun device and I can stream a channel. But after the first stream it crashes. So first I will try to fix that and report back to this topic.

If I can fix it, you can use TVHeadend as a backend. Which is nice if you don’t have a HD Homerun device or if you have to deal with DRM. TVHeadend has options to decode streams with a smartcard, which is why I use it.

1 Like

Fantastic news! Do you have a GitHub for it? I have done a lot of work with tvhproxy in the past, modifying it for my own needs. I could be of use?

Cheers!

Have been working for a few weeks on a UDP discovery in python, but have not gotten it to work. Do you mind sharing your code?

I'm in the progress of creating a github repository for it. I forked the original tvhProxy github project and I'm now merging my code into it. When it's ready it will be available here:
https://github.com/geertbongers/tvhProxy

1 Like

Thanks. Wish Channels had native m3u support.

3 Likes

Brilliant!

I eagerly await this. Currently I have TvHeadend working smoothly, but I would love to use the channels app for its native time shift ability.

Once something is up I will start debugging, unless you’re waiting for it to be fully functional before you post.

Cheers. :slight_smile:

OK, I’ve forked the original tvhProxy repository and added a branch named udp-tcp-control https://github.com/geertbongers/tvhProxy/tree/udp-tcp-control. I’ve also created a docker image https://hub.docker.com/r/geertbongers/tvhproxy/. I haven’t had time to add proper instructions. But if you look at my repo and specifically the serviced.d directory than you can probably figure how to run it.

So now we need test it, work out the quirks and add some good instructions of how to run it. I’ve only build the bare minimum of udp responses to get Channels working. Don’t expect it work with every HDHomeRun client.

2 Likes

Great!

I’ll check this out when I get a moment, hopefully tonight!

Ok, so, I’ve got it running. Brilliant work so far. I’ve had one crash so far, also it seems that channels disregards the direct url to tvheadend and still prefers /auto/v

I’ll keep testing and seeing what I can find.

IDEA
On channels you have the option of holding down on the tuner device and choosing the get the epg data straight from the unit, I think? (DVB). I don’t actually have a hdhr so I can’t test this, do you? Can you get it to request the data from the unit so we can recreate the responses with tvheadend data?

What do you think to creating a gitter.im board to discuss this further or would you prefer to just use GitHub issues?

In fact, it is talked about right here in this thread. So, if we identify as a DVB model then channels will ask for EIT (epg) info and we can provide it from tvheadend? Providing we can figure out the request and required response. Perhaps tmm1 could give us a quick rundown on how channels expects the data to arrive?

EIT is transmitted on PID 0x12. The app does “get /tunerX/filter” to get the pid filter, then does “set /tunerX/filter” to set it to existing value + 0x12

You would also need to implement /tunerX/streaminfo and return correct tsid= and onid= for the stream so that the app can lookup the correct EIT for that channel.

1 Like

Thanks for this! I’ll have to see what Geert says as I basically have zero clue about UDP.

Have you considered adding the ability to use a custom guide based on xmltv? I’ve seen a few people request this on the forums.

@patriot1889 do you use the docker container or run the scripts directly? I did a push yesterday to use the direct stream option as a default. Since then it has been up for three days without crashing. You can turn it in and off with the environment variable TVHPROXY_DIRECT_STREAM and setting it to YES or NO.

And I think I prefer tracking issues in GitHub.

I like the idea of implementing the EIT based EPG stuff. I will look into it, but I’m by no means a UDP expert. I just implemented enough so it would be discovered. And maybe when Channels DVR gains DVB epg we can use it for that too @tmm1 :grin: and thanks @tmm1 for the info.

Hey Geert,

That’s cool, issues seems a good option, however I think they’re currently disabled? I’ve created a gitter.im anyway, you don’t have to use it, but if you change your mind its there.

I ran it all separately rather than using docker, but I have the version that enables the direct stream and it is turned on… it just doesn’t work. I’ll dig in further and see if I can find out why.

Regarding the EIT based stuff, I see that mythtv is able to grab EIT from HDHR devices, so looking at the code from that might be useful? I think it is also in libhdhomerun too (maybe in hdhomerun_channelscan.c based on my quick scan). Might be worth checking both of them out when you get chance.

I think the easiest way would be to sniff the packets from a genuine hdhr?

All potential avenues to think about.

I’ve enabled the issue tracker.

When I switch to direct stream I first have kill my app on the iPhone or Apple TV before it will use the direct stream. I guess it has to refresh the lineup before it uses the new url.

I will look into mythtv and hdhomerun_channelscan.c.

I didn’t find packet sniffing to be easy because it is udp, and normal proxies don’t seem to work. Maybe something like wireshark, but then you get a lot of information and you need to find you’re specific requests and responses.

I was looking into it and Wireshark allows you to sniff purely for udp, and I think you can filter it to certain IPs too :slight_smile:

I am working on a modification and have taken TV headend out of the loop putting my video stream URL’s directly in place from the HDhomerun proxy. It works great on URLS that are mpegTS but URLS that are m3u8 don’t seem to work. I assume channels is only looking for mpegTS because that is what the HDhomerun serves up???

Log File:

2017/10/04 09:33:02 [TNR] Opened connection to 88888888 for ch1
2017/10/04 09:33:02 [HLS] Starting transcoder for channel 1 (encoder=h264_vaapi, resolution=720, deinterlacer=hardware, bitrate=6000)
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: va_openDriver() returns 0
[file @ 0x258f4c0] Protocol ‘file’ not on whitelist ‘crypto’!
[hls,applehttp @ 0x258a9a0] Failed to open segment of playlist 0
[file @ 0x258fa40] Protocol ‘file’ not on whitelist ‘crypto’!
[hls,applehttp @ 0x258a9a0] Failed to open segment of playlist 0
[file @ 0x258ff80] Protocol ‘file’ not on whitelist ‘crypto’!
[hls,applehttp @ 0x258a9a0] Failed to open segment of playlist 0
[pipe @ 0x25902c0] Protocol ‘pipe’ not on whitelist ‘crypto’!
[hls,applehttp @ 0x258a9a0] Failed to reload playlist 0
[hls,applehttp @ 0x258a9a0] Error when loading first segment ‘video005.ts’
pipe:: Invalid argument
2017/10/04 09:33:18 [HLS] Stopping transcoder session ANY-ch1 @ 0s
2017/10/04 09:33:18 [TNR] Closed connection to 88888888 for ch1

I came here looking at why tvhproxy didn’t work with my channels app, when it does work with Plex DVR. Reading this thread (please confirm) the original tvhproxy won’t work with the channels app and I need to use this one? Which is not yet complete? I’m just running the normal Tvheadend and tvhproxy setup. Plex is painful when it comes to EPG and the like and it’s still a bit buggy for every day use unfortunately. Plus their guide is not good.

Thoughts?

@Geert @patriot1889 @lsawyer Has somebody figured this out? What is the best way to have Channels pick up IPTV playlists? Preferably without an HDHR device. Thank you.

We recommend using Telly for this. See Channels DVR + Xteve / Telly