I love that DVR capabilities are coming to Plex. It’s the feature that pushed me into purchasing a lifetime Plex Pass <3.
I currently have a couple internal Hauppauge cards that I used to use with MythTV. I realize that Plex currently only support HDHomeRun devices at the moment, likely because their server model is agnostic of any specific system. But that got me thinking. Could I make Plex use my Hauppauge card if I wrote a wrapper that implemented HDHomeRun APIs?
If a Plex engineer or anyone has some feedback on the feasibility of this I’d like to hear it before I get into it :). I found a development document here https://www.silicondust.com/hdhomerun/hdhomerun_development.pdf. Might do some more research this weekend.
from my understanding plex uses a different approach based on a restful api, with .json structures involved and then calls a URL to receive a stream (mpegts or h264-mkv). This seems to be the newer models of hdhr only (hence some elder ones are not supported).
This api I have not found any documentation. But @elan posted in another thread that they will post what they did once the flaws are ironed out.
If you know someone with hdhr hardware that is supported, we could some start working on hacking some wrapper code by tracking what are the responses to the calls from plex.
I would love to see a discover.json that the hdhr devices show and the next steps of course as well.
Then we can work on using either a sat->ip implementation or tvheadend, vdr, enigma, etc to achieve the same as what hdhr delivers.
Wouldn’t it be easier if they just implemented TVHeadEnd support, then you could pretty much call it a day, since that’ll cover pretty much everything that the HDHR doesn’t (Including the HDHR)
@karbowiak said:
Wouldn’t it be easier if they just implemented TVHeadEnd support, then you could pretty much call it a day, since that’ll cover pretty much everything that the HDHR doesn’t (Including the HDHR)
from my understanding plex uses a different approach based on a restful api, with .json structures involved and then calls a URL to receive a stream (mpegts or h264-mkv). This seems to be the newer models of hdhr only (hence some elder ones are not supported).
This api I have not found any documentation. But @elan posted in another thread that they will post what they did once the flaws are ironed out.
If you know someone with hdhr hardware that is supported, we could some start working on hacking some wrapper code by tracking what are the responses to the calls from plex.
I would love to see a discover.json that the hdhr devices show and the next steps of course as well.
Then we can work on using either a sat->ip implementation or tvheadend, vdr, enigma, etc to achieve the same as what hdhr delivers.
Cheer
Alex
Thanks for the info. I’ll have to start looking at tvheadend and try to find a specification to work from. I’d prefer to not need to reverse engineer the proxy (if I can avoid it).
@JasonMeudt said:
@karbowiak said:
Wouldn’t it be easier if they just implemented TVHeadEnd support, then you could pretty much call it a day, since that’ll cover pretty much everything that the HDHR doesn’t (Including the HDHR)
…and Win32/64 comes from…?
We only need one protocol. I don’t care what it is as long as it’s well documented. Afterwards we can have separate, decoupled server solutions to wrap a specific implementation. I haven’t had to chase these things in a while since Myth had it all in one box. My biggest complaint with Myth is the server side still practically required a GUI to configure. Anyway, I wonder if Docker could pose a potential solution for a Linux-centric software or if the native drivers would pose too much of a challenge making the translation from a Windows platform to a virtualized Linux one.
Having a server to wrap specific implementations wouldn’t just solve my problem of making my Hauppagge card usable with Plex, but someone could also wrap multiple HDHRs and report it as a single device w/ 4 tuners. Plex could really benefit by having an open protocol here.
Edit: I forgot to mention, I found SiliconDust’s GH repo here Silicondust · GitHub. I can probably start with reverse engineering libhdhomerun and start looking through the documentation.
We’re still looking into how to support additional tuners/hardware. There are a number of options we’re looking into, just figuring which is best. And at some point we’ll definitely have a backend API to plug in something custom.
(And to be clear, we don’t use libhdhomerun, we use the super-simplistic HTTP-based interface which modern HDHR devices support for scanning and recording channels.)
@elan said:
(And to be clear, we don’t use libhdhomerun, we use the super-simplistic HTTP-based interface which modern HDHR devices support for scanning and recording channels.)
I kept on saying that as well … And I agree, a modern Restful API is the way to go. I suggest you guys set up some meta API for yourselves and the various systems can connect to that, rather then building an implementation per provider.
@iPhonedation said:
I suggest you guys set up some meta API for yourselves and the various systems can connect to that, rather then building an implementation per provider.
That’s essentially already what we have But it’ll need to be enhanced for European systems.
@elan said:
(And to be clear, we don’t use libhdhomerun, we use the super-simplistic HTTP-based interface which modern HDHR devices support for scanning and recording channels.)
@elan said:
(And to be clear, we don’t use libhdhomerun, we use the super-simplistic HTTP-based interface which modern HDHR devices support for scanning and recording channels.)
Really? Bad news for me then. I’ve started writing a little proxy that implements the old UDP/TCP protocol with the aim of implementing real-time transcoding on a Pi. Looks like I need to so something different…
what about dvblogic support? - I’ve been using it flawlessly for many years on windows backend with a mix DVBT, DVBS, DVBS2, and even subscription DVBS2 via oscam.
Rather than limiting to tvheadend, you should perhaps rather look at the PVR backends supported natively in Kodi (as there are a few).
Kodi itself has a number off issues around time-shifting in the client which makes it not ideal as a front end client - Plex on the other hand doesn’t need to be like that…
The best way to add sat support is the integration of sat>ip. And not only for dvb-s, also for dvb-t and dvb-c. This will be also a solution to get legal access to crypted content (example: Octopus NET with Common Interface slots).
It’s an open standard and well documented. satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf
