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

As far as I know the hdhomerun has two ways to control the device. The http API or the UDP api over port 65001. Which one is used for the Apple TV app? Is the UDP API only used for discovery and http API for the other stuff?

Depends on the hdhomerun model and operation. The app uses both depending on what it’s doing.

Ok, I was considering to extend the https://github.com/jkaberg/tvhProxy code with a simple udp server that only responds to the libhdhomerun discovery request. In that way I hope to be able to use TVHeadend as a HDHomerun. So if I emulate the HDHomeRun EXPAND (HDHR3-4DC), do I only need the udp discovery api? Or do I need more of the libhdhomerun api’s? Some more extensive emulating has been done with https://github.com/dsaupf/HDHRProxyIPTV. But I hope to keep it to a minimum.

If you implement the UDP discovery protocol, and identify yourself as a US model it should work. For DVB models the app will try to use the UDP protocol for tuning so that it can get EIT information in the stream.

Thanks, when I’ve got some results I will post them on the forum

Did you get anywhere with this?

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.