Has anyone successfully hacked EyeTV to support HDHR Prime?

I'm curious to know if anyone has been able to successfully hack EyeTV to see and HDHR-Prime as an HDHomerun?

To a purely novice programmer, but heavy tech head this seems feasible esp since the HDHomerun and Prime share the same command line routines with the hdhomerun_config.

Officially speaking its a licensing and cablecard issue, I get that. But from a tech stack standpoint, and with Elgato responsible for the HDHomerun iOS app that works with the prime (Albeit it only with SD channels for any HDHR, which is the dumbest thing ever because iOS can't support the transport stream yet you put out an HD app, I lulz... anyway.)

It would seem to me that if you could either hardcode the detection of a Prime as an HDHR you would presumably be able to access any channel the Prime could access because all the commands the EyeTV would use for control presumably should be the same as the HDHR.

Updates as of 1.9.2012

• HDHR-Prime tuning does work in EyeTV 3.4.3 and 3.5.4 (3.4.3 is recommended, your results may vary)
• EyeTV uses its own compiled version of libhdhomerun, 3.5.4 appears more modified than 3.4.3
• Make sure EyeTV can communicate to UDP port 65001 to 127.255.255.255 if you have a strict NAT or firewall config.
• EyeTV auto-scanning appears to be functional reading from all QAM frequencies, I havent hacked it to read a cablecard xml file channel list which would make this process certainly faster.
• EyeTV appears to check encryption of a channel on tuning, not displaying anything if its encrypted (regardless of whether there's an actual picture.) Originally I thought this information may be stored in the channel info it captures but it appears to be tied to the device configuration info stored in EyeTV.
• Not yet known: the location of the device configs, or alternatively any interception of the checking for encryption.

Bummer, I had forgotten about the fact that the prime uses vchannel now, but I had thought it also supported the original method through some legacy mode.

Ok next question, looking at EyeTV it seems to use libhdhomerun to its dirty work, does anyone know if SD has updated libhdhomerun api to work with the HDHR Prime?

I couldnt tell at a glance tonight but wondering if someone had looked at it yet?

It would appear EyeTV does all its communication through what appears to be an unaltered older version of libhdhomerun under hdhomerun.framework.

Thanks, rpineau I guess I'll look elsewhere for my needs than trying to get something to work without the necessary programming chops. I've been using a couple other ways to get casual HDHR Prime viewing to my Mac while working and just really liked the simplicity of EyeTV as the optimal setup.

Seeing as they haven't put out a major release in a long time, closed their own forums, I guess TV on the Mac isn't what it used to be.

Back to streaming from VLC I guess, but that really takes the fun out of flipping through channels trying to find something to watch, unless anyone has any better alternatives. Hacking together MythTV for OSX is not something of huge interest to me from a casual / windowed viewing experience.

Ted I haven't but I can certainly share my current setup and the options I've been playing around with:

I have a 2009 Mac Pro with 2 HDHR-Primes...

Using hdhomerun_config, more info is available from SiliconDust here http://www.silicondust.com/hdhomerun...evelopment.pdf

Quick Example:
You can setup a UDP stream which you can pickup in VLC, after setting a vchannel (virtual channel).. from the command line you can then stream to an ip and a udp port.

While its easy enough, I've found I prefer the ease of applications such as SinCast which supports HDHomerun and is a ridiculously powerful IP streaming app, it costs a few bucks but having talked to the developer dealing with a couple issues he's on the ball, friendly and very active.
http://www.sinderon.com/software.htm

(I have absolutely nothing to do with Sinderon beyond finding mention of them in a forum post on SiliconDust.)

I'll often just setup a stream to VLC through SinCast because its just a simplier way to accomplish the same task, and handles locking/unlocking of the tuner without you having to worry about setting the vchannel to 'none' when you're done so you don't lock the tuner out for your other apps.

I've used it either through a Windows 7 server I have setup, or a VMWare Windows 7 VM with no problem at all.

And while this solution works its hardly a 'flipping' through the channels experience like EyeTV, as each time you want to change the channel you have to stop the stream, change the channel and start a new stream.

I'll often watch TV, and have since the early days with an old STB TV Tuner card 15 years ago in a windowed environment while I work. While I enjoy the full screen media experience, its not as conducive to productivity as you'd think

It amazes me that in the age of hacking hardware to the nines that there isnt a great 'windowed' environment solution for the HDHomeRun Prime on OSX yet. Everyone rightfully so is working out home theater solutions, which is great, but that's a 30% use case for me, maybe 20%, most of my time I'd like to just have a TV window in the corner of my desktop streaming its entertainment goodness while I'm multitasking.

So its interesting that the tuning logic comes up again. According to those on the SD forums the Prime should be capable of tuning based on channel and program as well as vchannel.

Thread here where I ask about modifying a CLI script that originally started this train of thought, causing me to post here first, it would seem vchannel is preferred but channel/program is at least possible. http://www.silicondust.com/forum/viewtopic.php?t=11994

I looked into recompiling libhdhomerun on my mac last night but was getting a few errors so I haven't investigated that fully but the newest version of libhdhomerun from everything I've seen should be able to handle the prime and again based on the SiliconDust boards, also allow channel/program based tuning.

Looking at the currently compiled version of libhdhomerun in EyeTV, shown as 'hdhomerun' it does have a few @executable-path calls that would be different from a newly compiled version so I don't know how EyeTV would deal with that.

It's beginning to make me wonder if hdhomerun_config supposedly can handle a Prime like an HDHR, with the added methods supported by the Prime maybe their is a change to the discover api that I haven't noticed yet thats just not allowing the EyeTV to detect the Prime and that given its ability to see it like an HDHR and the Primes ability to handle encrypted channels you might be able to hack something together.

Or at least that was the original thought behind this thread, and seeing if anyone else more skilled was equally as interested in such an experiment.

Update: Adding a newer compiled version and headers definitely breaks EyeTV with an 'unknown file type' error (which is odd because its a compiled .SO just like the one in EyeTV. Replacing the broken new one with the original but keeping the new header files actually produces an interesting result... Detection of a Prime as an HDHR, complete with seeing both tuners, and both Primes I have (only selecting one of course to test).

However, upon a full extensive Clear QAM scan that took about an hour, it appears the EyeTV is unable to pull any channels, which isnt all that surprising. I do however find it interesting that updating the headers allows for detection, its one step closer.

Good point, Rodolphe however compiling it at 32-bit still produces the same crash at start and same generic error message.

I just realized that my TV guide subscription has expired, not sure if that would fix the auto-tune? Not sure I want to drop money on renewing it if people don't think it's related.

The EyeTVAutoScan.log seems to pick up the Prime but doesnt seem to pull any channel data down despite running through 812 QAM Cable channels earlier, it just shows blank. Curious.

Yeah good point I hadn't really thought about that.

I dug into it more last night and came across a few things first the location of what appears to be EyeTV's Channel Listing XML is in

Along with the EyeTVEPG.db which of course is useless without a set of channels

Attempts to inject dummy channels just to see if they would show up in EyeTV didn't seem to work which leads me to believe something has to kick off parsing that xml file and it may not always be read at launch.

So the 2 current issues still seem to be seeing if we can inject a new/custom compile of libhdhomerun into EyeTV as I still think we'll need it for tuning logic. And second some way to inject that channel information into EyeTV not through 'auto-tune'.

EyeTV does have a 'Channel Set Import' but without having a way to map say CableCard.xml to the EyeTV XML format I don't think thats of much help right now.

Potentially if someone had an HDHR that could run a QAM scan and export the EyeTV channel list we may be able to create a map for the Prime.

Thanks Joseph this gives me some more to dig through tomorrow. Looking at it briefly its package contents contain a channellist.plist which seems like a bundled up version of ChannelList.xml, which makes sense.

Just so I have something to map against, would you mind telling me your zip code?

p.s. - I thought I was aggressive with 2 3-CCs (on sale when I got them so ended up cheaper than 1 6-CC), what do you use 12 cable card tuners for if you dont mind me asking?

Both your setups trump mine.

Digging into this further it seems like EyeTV just marks encrypted channels as "Pay TV" and locks it because it doesn't believe they're viewable, a fair assumption given its official support.

Manipulating the key value for the 'logical channel number' in ChannelList.xml which it seems to set to '0' in this case to the actual vchannel value doesnt seem to want to stay on relaunch. Thus resetting to 0, keeping it 'locked' and doesnt appear when I poll the tuner to send a channel change request.
Correction: ChannelList.xml appears to be a passive xml file that gets loaded/re-loaded when a channel lineup is selected using data from:

Joseph did you say that your Primes are detected by EyeTV out of the box? or just the HDHRs? (Because I had to hack EyeTV to even get the primes detected.)

Other World Computing is having a sale on HDHRs so I figured I'd pick one up which should be here Tuesday. At that point I should be able to do some more testing and try to setup some event listeners with EyeTV.

More info for people following along. I'll probably start updating the first post in the thread with this info as its figured out.

1. EyeTV 3.4.3 seems to provide a better out-of-box experience than 3.5.4 (the former is still available through EyeTV's support site).

2. Unmodified EyeTV 3.4.3 and 3.5.4 must allow connections on UDP port 65001 to 127.255.255.255 (which seems to be communicating with EyeTV Helper or something else.) I have a pretty strict firewall setup and didn't think of this until today.

Doing so allows EyeTV to actually pull QAM channels from auto-tune from the Prime. However, 3.5.4 will not properly allow tuning to several Clear QAM unencrypted channels that I am easily able to access through 3.4.3

3. EyeTV 3.5.4 did away with the libhdhomerun header files, or they're buried somewhere else leading me to believe that either my modification of 3.4.3's header files changed how it communicated with the Prime so that my firewall wasnt blocking it?

4. In 3.4.3 and sometimes in 3.5.4 I'm able to access premium channels which appear as Clear QAM but I'm 99% sure are encrypted copy-freely? Where other channels show 'encrypted', which I still believe is a flag set in the channellist.plist upon auto-tuning, and that if we can identify the values marking it as encrypted we may be able to allow tuning to it.

4. Yes, tuning works, the Prime is happily accepting 'channel : program' information from EyeTV by unblocking that port.

Edited first post with general summary of updates and progress I've made from this investigation.