So here is the solution, https://github.com/jkaberg/tvhProxy (yes recording is working)
One small note: the current Plex implementation is hardcoded to use port 5004 when recording from HDHR (it will append 5004 to any url), so an current workaround is to create an virtual web host, proxy it to tvhProxy (on port 80). Add the virtualhost to your host’s file, then setup Plex DVR to use the virtual host.
I hope the Plex engineers see’s this post and alters the behaviour.
@jkaberg said:
So here is the solution, GitHub - jkaberg/tvhProxy: An small flask app to help Plex DVR connect with Tvheadend (yes recording is working)One small note: the current Plex implementation is hardcoded to use port 5004 when recording from HDHR (it will append 5004 to any url), so an current workaround is to create an virtual web host, proxy it to tvhProxy (on port 80). Add the virtualhost to your host’s file, then setup Plex DVR to use the virtual host.
I hope the Plex engineers see’s this post and alters the behaviour.
First of all jkaberg, WOW! nice work and really fats … on the Ports, I copy that!
@elan actually I figured now, as I recorded a movie with the rewrite hack from @bcyrill, that there seems to be different behavior in how you treat series/episodes vs. movies.
A series timer stops after the duration by itself and plex terminated the connection to my TVH server. But not for movies. I recorded 7 hrs (haha) and when I stopped the http connection manually from the TVH backend, then it got added to the media section in Plex and tagged, meta data, etc .
So in general this works really nicely, but could you for Beta3 please, please, please make the Plex instance stop the stream on its end? At least optional 
Cheers
J*
@jkaberg I am trying it right now remote. What makes me wonder is the call to the api/channels/grid that you use … This one does not provide all my channels. Strange…
Other but that it works! Great 
@iPhonedation said:
@jkaberg I am trying it right now remote. What makes me wonder is the call to the api/channels/grid that you use … This one does not provide all my channels. Strange…Other but that it works! Great
Do you have all channels mapped to an channel number (in TVH)? Anyhow I’ll look into this later today
So there is a few odd things about the plex HDHR implementation
Now Plex probably have a reason for doing what they did, but in my world PMS would just swallow whatever was feeded to it. I know the HDHR implementation was never meant for this kind of usage, and Plex team will probably implement support for Tvheadend at some point. It’s just that this solution works now (instead of next year or longer?), and if only the HDHR api spec was honoured this wouldn’t be an issue.
I’ve just commited an fix I hope solves the duration thing, take it for a spin and let me know how it goes
I will give it a try when I am back home tomorrow
There’s currently an limitation to one concurrent stream, I’ll look into working around that sometime
@iPhonedation said:
actually I figured now, as I recorded a movie with the rewrite hack from @bcyrill, that there seems to be different behavior in how you treat series/episodes vs. movies.A series timer stops after the duration by itself and plex terminated the connection to my TVH server. But not for movies. I recorded 7 hrs (haha) and when I stopped the http connection manually from the TVH backend, then it got added to the media section in Plex and tagged, meta data, etc .
So in general this works really nicely, but could you for Beta3 please, please, please make the Plex instance stop the stream on its end? At least optional
Very clever hacking in this thread
There shouldn’t be any difference in behavior between movies and shows, we specify the duration so that the recording isn’t truncated abnormally.
It’s conceivable we could add some sort of failsafe whereby the stream is terminated some time after it was supposed to end naturally. I’ll note it internally.
@elan said:
@iPhonedation said:
actually I figured now, as I recorded a movie with the rewrite hack from @bcyrill, that there seems to be different behavior in how you treat series/episodes vs. movies.A series timer stops after the duration by itself and plex terminated the connection to my TVH server. But not for movies. I recorded 7 hrs (haha) and when I stopped the http connection manually from the TVH backend, then it got added to the media section in Plex and tagged, meta data, etc .
So in general this works really nicely, but could you for Beta3 please, please, please make the Plex instance stop the stream on its end? At least optional
Very clever hacking in this thread
There shouldn’t be any difference in behavior between movies and shows, we specify the duration so that the recording isn’t truncated abnormally.
It’s conceivable we could add some sort of failsafe whereby the stream is terminated some time after it was supposed to end naturally. I’ll note it internally.
Hey @elan, would you please consider actully using the values in discover.json and lineup.json? I’m referring to key BaseURL and LineupURL in discover.json, and key URL in lineup.json. These currently seems hardcoded from PMS side? If you can fix/add this then my proxy implementation is complete. See this post
I really like to read about your progress of TVH integration, keep up the good work
Probably not the right thread though 
@lauridsd Ok, I just renamed the thread 
@jkaberg I just deleted all icons references and now the list is complete (nearly).
Thank a lot for the proxy, I will create an upstart (running a 14.10.3 ubuntu) script later. Do you want that one for your git?
@iPhonedation said:
@jkaberg I just deleted all icons references and now the list is complete (nearly).Thank a lot for the proxy, I will create an upstart (running a 14.10.3 ubuntu) script later. Do you want that one for your git?
Sure, submit an PR
Crossing my fingers @elan comes through on my request, at which point the Tvheadend proxy solution should be feature complete (in terms on what PMS needs to have in order for the DVR to work), just need to do a minor tweak in the lineup.json generation once Plex fixes it on their end
Hi @jkaberg, I am playing with it now … no recording (ad hoc, on air right now) seems to start for things already on air … I can however call a URL directly via browser.
Just to let you know. I will try with some series and movies later tonight.
@iPhonedation said:
Hi @jkaberg, I am playing with it now … no recording (ad hoc, on air right now) seems to start for things already on air … I can however call a URL directly via browser.Just to let you know. I will try with some series and movies later tonight.
Thats strange, works perfectly fine on my end (except only one concurrent stream at a time, due to the synchronous nature of the web framework I use). Did you try and remove the DVR, and readd? Did you pull latest git changes? Enable debug and check the output, you should see “GET /auto/v184?duration=814&transcode=heavy” or smiliar, if you didnt means PMS is setup wrong.
Once PMS parses lineup.json correctly, I can remove the “stream” proxy (=why theres a concurrent stream limit) and offload all streams directly to Tvheadend
EDIT: Just tried an ad hoc recording now, works fine.
Just recorded a show succesfully. Currently trying with a movie as well.
Here is the upstart configuration that I am using (using pyenv):
author "bcyrill"
description "Upstart Script to run tvhProxy as a service on Ubuntu/Debian based systems, as well as others"
#Set username / group for the process.
setuid tvh
setgid nogroup
start on runlevel [2345]
stop on runlevel [016]
respawn
exec /home/tvh/.pyenv/versions/tvhproxy/bin/python2.7 /home/tvh/tvhProxy/tvhProxy.py
Edit: Recorded the movie succesfully as well.
Is anybody using TVHeadend with a HDHomerun? I can see it in TVHeadend but can’t find muxes.
Edit: Nevermind, got it working
I found some reason why recordings did not start (besides me being stupid with the port in the inital URL setup, but that I figured myself).
@elan Plex is calling the Stream URL with the channel number from gracenote, not the one in the list coming from HDHR. Is this behaviour “planned”? I could change all my channelnumbers in TVH to match what Gracenote expects, but in fact also other systems use the TVH server in my household, and there is some logic that we applied to the numbers so my son and wife can also easily use this.
Example:
SKY CINEMA HITS HD is channel number 705 in Gracenotes “Telekom Deutschland GmbH (Telco - Premium)” but 601 in my Channellist in TVH. The call Plex does goes to /auto/v705?..
@jkaberg I do not think we can work around this one with the automated approach. Calling the URL provided in the lineup will solve it, I know.
Cheers
Alex
@iPhonedation said:
I found some reason why recordings did not start (besides me being stupid with the port in the inital URL setup, but that I figured myself).@elan Plex is calling the Stream URL with the channel number from gracenote, not the one in the list coming from HDHR. Is this behaviour “planned”? I could change all my channelnumbers in TVH to match what Gracenote expects, but in fact also other systems use the TVH server in my household, and there is some logic that we applied to the numbers so my son and wife can also easily use this.
Example:
SKY CINEMA HITS HD is channel number 705 in Gracenotes “Telekom Deutschland GmbH (Telco - Premium)” but 601 in my Channellist in TVH. The call Plex does goes to /auto/v705?..
@jkaberg I do not think we can work around this one with the automated approach. Calling the URL provided in the lineup will solve it, I know.
Cheers
Alex
Yes, if only Plex used the lineup.json properly
This would obviously be a problem for anyone using an TV provider not listed with Gracenote, and not just this proxy solution (I for one use the provider Get in Norway and AFAIK Gracenote doesn’t list that one for my post number).
So one could say this is a bug @elan, as people who don’t see their TV provider in the DVR setup guide will obviously use another provider and just map the channels manually (like me) which will break your HDHR implementation, simple fix: parse lineup.json properly and use the values.
Thanks, we’ll look into this!
