Tvheadend

I don't understand.
TVheadend already supports HDHomeRun.
Just connect Plex to TVheadend server and it should work fine.

Andreas Fornberg wrote:

I don't understand.
TVheadend already supports HDHomeRun.
Just connect Plex to TVheadend server and it should work fine.

I'm just about to try the tvhProxy script, which I believe emulates a HDHomerun to plex whilst connecting to TvH? I think the OP is requesting this proxy / API calls are integrated into TvHeahend to allow Plex users to use any tuner supported by Plex as opposed to the slightly limited initial hardware. And also requiring a third party tool ( TvHProxy)

Alex

Yes this is correct if TVHeaded has an option to turn on HDHOMERUN emulation then plex would see it as a device this would allow all tuners, IPTV, CAMS, SAT and all to be passed into plex as live tv which would be a great ability. The TvHproxy is limited in that i will only do one channel at a time where as if this was built into TVHeadend it could allow multiple streams at ones from many devices.

Plex also will grab XMLTV for an EPG from a URL so if TVHeadend could offer this that would be great too, i know you can create a XMLTV file but if this could be via a URL then plex can just grab it from there too.

Hope that explains it all well but i think you follow what im asking now.

Any more questions please ask and thanks!!!

This is another emulator project that does slimier i believe https://github.com/TheJF/antennas so there is a lot of demand for this type of functionality.

Shane

Shane Kuzmanic wrote:

Yes this is correct if TVHeaded has an option to turn on HDHOMERUN emulation then plex would see it as a device this would allow all tuners, IPTV, CAMS, SAT and all to be passed into plex as live tv which would be a great ability. The TvHproxy is limited in that i will only do one channel at a time where as if this was built into TVHeadend it could allow multiple st/home/leatherface/Compile/xbmc/tools/depends/target/reams at ones from many devices.

Plex also will grab XMLTV for an EPG from a URL so if TVHeadend could offer this that would be great too, i know you can create a XMLTV file but if this could be via a URL then plex can just grab it from there too.

Hope that explains it all well but i think you follow what im asking now.

Any more questions please ask and thanks!!!

I still don't get it i use HDHomeRun device with 4 tuners and i can use all tuners with Kodi any software or device i am using.

And you can grab EPG with

http://localhost:9981/xmltv # short alias for http://localhost:9981/xmltv/channels
http://localhost:9981/xmltv/channelname/*channelname*
http://localhost:9981/xmltv/channelnumber/*channelnumber*
http://localhost:9981/xmltv/tagname/*tagname*

Change localhost to your IP to TVheadend.

Plex will connect to a HDHomeRun device to play live tv and to record live tv. I dont have a HDHomeRun but i do have TVHeadend with multiple tuners. If TVHeadend can emulate a HDHomeRun device then plex will find it and use its tuners.

the TVHProxy project sits on a machine and advertises as a HDHomeRun device and then simply converts the requests to TVHeadend requests and then returns them as HDHomerun requests. Its a simple conversion process and could be built into TVHeadend.

TVheadend already supports HDHomeRun and find all 4 tuners for me.
There is no need for emulation or anything like that it works like a normal DVB card.
If PLEX connects to TVheadend it should not be a problem to fins HDHomeRun tuners.

Andreas Fornberg wrote:

TVheadend already supports HDHomeRun and find all 4 tuners for me.
There is no need for emulation or anything like that it works like a normal DVB card.
If PLEX connects to TVheadend it should not be a problem to fins HDHomeRun tuners.

I believe he's asking if Tvheadend can pretend to be a HDHomerun device so that it can be easily detected by PLEX. :p

Hmm ok but that whouls be done with a proper addon for PLEX if it doesn't work.
But i can't see why it wouldn't already today with already existing TVheadend bundle.

https://github.com/pgaubatz/TvplexendChannel.bundle

Here is another one

https://github.com/realriot/tvheadend-ng.bundle

Mark Clarkstone wrote:

Andreas Fornberg wrote:

TVheadend already supports HDHomeRun and find all 4 tuners for me.
There is no need for emulation or anything like that it works like a normal DVB card.
If PLEX connects to TVheadend it should not be a problem to fins HDHomeRun tuners.

I believe he's asking if Tvheadend can pretend to be a HDHomerun device so that it can be easily detected by PLEX. :p

Yes, this is what Andreas is asking and I am interested too! Would this trick work with Eyetv also? I mean: will Eyetv recognize tvheadend as an hdhomerun device?

Shane Kuzmanic wrote:

Could HDHomerun emulation be added please,

Hi,

The only one true HDHomeRUN emulator is this: http://github.com/dsaupf/HDHRProxyIPTV

This really emulates one HDHR with full HDHR API. All others only translate the HTTP API of the recent HDHomeRUNs. So, they are unuseful for impersonate a true HDHR tuner.

I'm using this pice of emulator running in Linux with Wine (yes, it's only for Windows). It works with any SAT>IP server with HTTP interface (RTSP is the default interface for SAT>IP). In my environment the server is minisatip and the client is WMC.

I recommend this emulator. ;)

Andreas Fornberg wrote:

Hmm ok but that whouls be done with a proper addon for PLEX if it doesn't work.
But i can't see why it wouldn't already today with already existing TVheadend bundle.

https://github.com/pgaubatz/TvplexendChannel.bundle

Because the TVHeadend bundle is for viewing TVHeadend, If the new Plex DRV saw this as a HDHomerun plex can set recordings, pause live tv watch recordings etc all from the main plex front end not though channels.

Ok men shouldn't this request go to the writer of that plugin to support recordings etc instead.
TVheadend also supports SAT-IP that is a standard for network tuners.

When i look here it seems to support TVheadend recordings

https://github.com/pgaubatz/TvplexendAgent.bundle

This is different again, its easy to SMB share out TVHeadends recordings folder and mount from plex, but this feature request will allow plex to use TVHeadend as a tuner source.

Shane Kuzmanic wrote:

This is different again...

Yes, one functionality is the NETWORK TUNER, and another different is a NETWORK PVR BACKEND.

For the Network Tuner, only two "standard" protocols exist: SAT>IP and HDHR (this is propietary, but good known).

For a Network PVR Backend, a lot exists: MythTV is one of the most ancient. And TVHE is one of the best.

So, if you need to "tune" signals, then use SAT>IP or HDHR. And if you need to schedule recordings in the network, then use MythTV or TVHE.

Mono Polimorph wrote:

Shane Kuzmanic wrote:

This is different again...

Yes, one functionality is the NETWORK TUNER, and another different is a NETWORK PVR BACKEND.

For the Network Tuner, only two "standard" protocols exist: SAT>IP and HDHR (this is propietary, but good known).

For a Network PVR Backend, a lot exists: MythTV is one of the most ancient. And TVHE is one of the best.

So, if you need to "tune" signals, then use SAT>IP or HDHR. And if you need to schedule recordings in the network, then use MythTV or TVHE.

It would be great having the possibility to get tvheadend recognized as a NETWORK TUNER like HDHR!! :)

I won't work on this, but if someone come with a complete patch / code, I'll include it.

Thanks, i think to many comments have muddied the simplicity of the original request here.

Its simply to add network tuner support to Plex via HDHomerun emulation. I know there are plex bundles etc and other ways to do some parts but network tuner emulation would supply a far richer experience in plex.

I hope someone with the ability can supply this to the project.

Thanks

Shane

Look for SAT-IP that is a standard for network tuners.

Shane Kuzmanic wrote:

Thanks, i think to many comments have muddied the simplicity of the original request here.

Hi, Implementing HDHR server support isn't "simple"!!
The discovery part is trivial. And the transport plane are plain UDP (RTP as option). However, for the control plane plane you need some development (one library exists). You can check the referenced project to see the complexity.

Andreas Fornberg wrote:

Look for SAT-IP that is a standard for network tuners.

Yes. However, HDHR has (good) BDA drivers, and SAT>IP doesn't!

Hey, author of tvhProxy here.

tvhProxy is just that, an proxy. It proxy requests between Plex DVR (https://www.plex.tv/features/live-tv-dvr/) and Tvheadend by emulating an offically supported (by Plex) HDHR device.

I believe tvhProxy still works (?), however I was in touch with Elan (CTO @ Plex) a while back who told me that an official API is underway which will let tuners act as an source for Plex DVR (I don't know if the API spec is finalized yet).

So my 2 cent is to sit tight, and wait for the API before moving forward.

Thanks Joel thats great news.

Joel Kåberg wrote:

Hey, author of tvhProxy here.

tvhProxy is just that, an proxy. It proxy requests between Plex DVR (https://www.plex.tv/features/live-tv-dvr/) and Tvheadend by emulating an offically supported (by Plex) HDHR device.

I believe tvhProxy still works (?), however I was in touch with Elan (CTO @ Plex) a while back who told me that an official API is underway which will let tuners act as an source for Plex DVR (I don't know if the API spec is finalized yet).

So my 2 cent is to sit tight, and wait for the API before moving forward.

Hi Joel,

Thank you for your news! Great!

However, please, for not confusing the people: The HDHomeRuns has two APIs. The "new" HTTP API, only supported by new products. And the "old" API, supported by all models and more powerfull. Futhermore the "tvhProxy" implements only the HTTP API. This it's relevant because a lot of HDHR clients (for example TVH or the BDA drivers) only support the "old" API.

Regards.

Andreas Fornberg wrote:

And you can grab EPG with

http://localhost:9981/xmltv # short alias for http://localhost:9981/xmltv/channels
http://localhost:9981/xmltv/channelname/*channelname*
http://localhost:9981/xmltv/channelnumber/*channelnumber*
http://localhost:9981/xmltv/tagname/*tagname*

Change localhost to your IP to TVheadend.

Thank you very much for this detail. I have had trouble finding documentation about it. It looks like it was implemented a couple years ago. Now my only issue is it does not supply the <category> info in the XMLTV output: https://tvheadend.org/issues/2527#note-8.

There is a new PLEX addon for TVheadend.

https://forums.plex.tv/discussion/271068/livetvh-live-tv-streaming-with-tvheadend

Mono Polimorph wrote:

Shane Kuzmanic wrote:

Could HDHomerun emulation be added please,

Hi,

The only one true HDHomeRUN emulator is this: http://github.com/dsaupf/HDHRProxyIPTV

This really emulates one HDHR with full HDHR API. All others only translate the HTTP API of the recent HDHomeRUNs. So, they are unuseful for impersonate a true HDHR tuner.

I'm using this piece of emulator running in Linux with Wine (yes, it's only for Windows). It works with any SAT>IP server with HTTP interface (RTSP is the default interface for SAT>IP). In my environment the server is minisatip and the client is WMC.

I recommend this emulator. ;)

Hi, could you please tell how to setup this tool HDHRProxyIPTV with minisatip?
Do I also need to install official HDHomeRun drivers first?

Do I need a real HDHomeRun or can I use any device that can run minisatip and HDHRProxyIPTV?

Never mind, no need for real HDHomeRun and indeed drivers must be installed.

Joel Kåberg wrote:

Hey, author of tvhProxy here.

tvhProxy is just that, an proxy. It proxy requests between Plex DVR (https://www.plex.tv/features/live-tv-dvr/) and Tvheadend by emulating an offically supported (by Plex) HDHR device.

I believe tvhProxy still works (?), however I was in touch with Elan (CTO @ Plex) a while back who told me that an official API is underway which will let tuners act as an source for Plex DVR (I don't know if the API spec is finalized yet).

So my 2 cent is to sit tight, and wait for the API before moving forward.

Hi Joel any update oc this? Still waiting as having this emulation built into Tvheadend would be great.

Shane Kuzmanic wrote:

Hi Joel any update oc this? Still waiting as having this emulation built into Tvheadend would be great.

Hi,

No one working on it.

However, if Jaroslav agree with implement it, then I can help doing some coding after he provides the point #1 described in https://tvheadend.org/issues/5236#note-3

Sorry, but without this "template" I can't do anything.

Still what's wrong with this Plex addon that does exactly what you are seeking for.
Not en emulation but full support for TVheadend like any other Frontend like Kodi with pvr.hts etc.

https://forums.plex.tv/t/rel-livetvh-live-tv-streaming-with-tvheadend/191607

hey guys!

first up – thanks alot for TVHeadend! it's a superb solution for recording and i'm using it since a few years - loving it.

i've read alot about howto('s) integrate TVH into the PLEX universe via proxies and plug-ins and other stuff. i tried quite a few solutions and at the end of the day, they simply don't cut it. all of them have severe shortcomings in one or the other way. but the biggest point of no joy is, they are far from reliable - and that makes them simply a no solution.

the PLEX makers changed their minds about a few features shortly, so relying on any way of pimping up PLEX isn't going to last forever. maybe it's because of stability or other reasons, probably they will cut into the plug-ins support as well - so i wouldn't go with a solution which maybe works today, but not tomorrow.
the quoted plug-in one post above from Andreas has still some limitations and as users report also still has bugs which make it no candidate for me. and the history of development makes me to believe, that the author hasn't got enough time left for making it perfect (i do appreciate any efforts and can understand any time constraints he might have).

one of the great advantages of TVH is to be able to cumulate all receiving sources into one solution. now consuming this recorded content is the other big part of the game and this is really where PLEX shines, besides it's management features of the content. the great client support on so much devices makes it simply speaking a better consuming solution (also for recorded content from TV) as any other known client to me (and even i like a great iOS TVH client, this one can't forward or jump more than one time while playing back) and they have other shortcomings.

so maybe it's kinda hard to understand for non PLEX users, but once you got drawn into it, you see and like their approach to how you consume your content and it's way of organizing it. we PLEX users would simply love to use our clients available to us, to consume live TV from sources provided by our TVH servers. and as bad as it is right now, PLEX can only use a handful of TV cards right now and has no way of descrambling streams, so using the PLEX server as TV content provider directly is therefore not really of any interest.

the solution could be, to empower TVH to provide an HDHomeRun emulation - it would let other devices see it as a real HDHomeRun tuner in the network.
then PLEX would connect to it and could use it any way it wants to. that would be the most compatible way (and save with future revisions of PLEX development) and no one would need any special "tricks" to get one thing running, while breaking another - or having to do kinda voodoo to setup/change things on several places (for example you need to create tags inside TVH channels to define which codecs they use to make it compatible - sorry but this is cumbersome, error prone and quite a bit of manual work; probably for a lot of users simply not to handle well).

and let's think out of the box: wouldn't it be great to empower TVHeadend with
a) such a (hardware)protocol-emulation for it's own
b) making it the number one solution for PLEXers around the world to consume their TV content from already possessed/installed receiving hardware
c) bring TVH again into the talk of a lot of people for being simply great

i could and would love to help with testing (no coder here) and providing feedback to make it real thing.

greets,
oliver

I think that the paid version of plex supports SAT>IP (look to google) - so go ahead and test it using the tvh as the SAT>IP server.

Jaroslav Kysela wrote:

I think that the paid version of plex supports SAT>IP (look to google) - so go ahead and test it using the tvh as the SAT>IP server.

you're right – and i tried that in the past. forget it. it's only listed as unofficial and that's it exactly.
for fun you can go here and read a bit of users experiences (german).
https://forums.plex.tv/t/sat-ip-server-einbinden/208696

as long as it isn't officially supported (and to it's defined standard) there's only the HDHomeRun compatible way of getting it going.

and btw. back then when trying to get it running with the plug-ins and or proxies, i had one case where i could scan for the channels, and it found most of them, but all scrambled ones it didn't accept – wth i thought. somehow it knew, which were scrambled and which not. so this is one more proof, that this route isn't going to be reliable nor even acceptable.

but thanks anyway.

Again have you guys tested this addon that seems to do the job?

https://forums.plex.tv/t/rel-livetvh-live-tv-streaming-with-tvheadend/191607

Andreas Fornberg wrote:

Again have you guys tested this addon that seems to do the job?

https://forums.plex.tv/t/rel-livetvh-live-tv-streaming-with-tvheadend/191607

sorry andreas,

but have you read up about the preparations, limitations and problems of this plug-in and of the users?
plug-in gets updates (but the last one is of july, 25). that indicates the developers simply hasn't got enough time (which is ok with me) to keep up with it and it's bugs and/or users problems.

i tried that one in an earlier version, but wont play again with it.
plug-ins in PLEX aren't a save bet, mostly are slow and – let's be honest – is a hack.
not to forget about users which host their PLEX-server on NAS (or similar) devices – they might be unable to alter these packages – so no joy for them.

HDHomeRun is supported full out-of-the-box, will be supported by PLEX devs in the future and is compatible with lots of others devices.
so in short you get: best tuning speeds, best compatibility and it's future proof.

it would not only make us PLEX users happy, but alot of others too. and that is in the best interest of the TVHeadend project, or not?

it would not only make us PLEX users happy, but alot of others too. and that is in the best interest of the TVHeadend project, or not?

As the current main developer, I added many features which I do not personally use. As the open source developer, I strongly dislike some vendor specific APIs, so I am fan of SAT>IP. My interest to add HDHomeRun server code is really low (I don't need it for my home DVR system). I am using tvh/enigma2 (main) and tvh/kodi (kids) combos for MPEG-TS.

If plex supports SAT>IP network tuners (and as customer, you can try to push them to improve / make this support stable), I can fix potential bugs on the tvh server side. Basically, SAT>IP is widely used in Europe, HDHomeRuns are used mostly in US (Plex is originated from US? so that's probably the reason why they don't push the SAT>IP more).

But if someone other creates the HDHomeRun server code, I will include it as I noted before. And no, it's not too difficult. Perhaps a good project for a student.

Oliver S wrote:

it would not only make us PLEX users happy, but alot of others too. and that is in the best interest of the TVHeadend project, or not?

Generally, the backend provides standardized interfaces, which is used by the frontend developer to realize the required functionality. Something which is NOT the job of the backend developer.
In this special case it is even more grave that Plex "evolved into a commercial software business" with "65 employees" (wikipedia)
So, it's up to Plex to realize this function!

Furthermore, as Jaroslav pointed out in a friendlier way, the whole HDHomeRun stuff is a virtually unnecessary product: Instead of using a standardized protocol (Satip), they did their own thing, implementing a proprietary protocol.

Jaroslav Kysela wrote:

it would not only make us PLEX users happy, but alot of others too. and that is in the best interest of the TVHeadend project, or not?

As the current main developer, I added many features which I do not personally use. As the open source developer, I strongly dislike some vendor specific APIs, so I am fan of SAT>IP. My interest to add HDHomeRun server code is really low (I don't need it for my home DVR system). I am using tvh/enigma2 (main) and tvh/kodi (kids) combos for MPEG-TS.

If plex supports SAT>IP network tuners (and as customer, you can try to push them to improve / make this support stable), I can fix potential bugs on the tvh server side. Basically, SAT>IP is widely used in Europe, HDHomeRuns are used mostly in US (Plex is originated from US? so that's probably the reason why they don't push the SAT>IP more).

But if someone other creates the HDHomeRun server code, I will include it as I noted before. And no, it's not too difficult. Perhaps a good project for a student.

This guy seems to have done it as a stand alone app to re-stream EPG and Video from IP TV providers to plex and it works OK, i dont think he gives out the source though. https://xteve.de/

Hi Jaroslav, this feature is definitely still wanted. The xteve project does now share source https://github.com/xteve-project/xTeVe so if someone did have the time to add an option in tvheadend to emulate HDHomerun that would be awesome.

Thanks for the great project.

Shane Kuzmanic wrote:

Hi Jaroslav, this feature is definitely still wanted. The xteve project does now share source https://github.com/xteve-project/xTeVe so if someone did have the time to add an option in tvheadend to emulate HDHomerun that would be awesome.

Thanks for the great project.

i can only second this. it would make life much more easy and bring another valueable feature to TVHeadend.

Go ahead and implement it then. I know that I won't be able to implement it (lack of time) but if there's a PR for it I would definitely look over it and merge it. Unfortunately I'm the only active developer at the moment, so doing it yourself is the only way to get it implemented. And you would help the project a lot.

Flole Systems wrote:

Go ahead and implement it then. I know that I won't be able to implement it (lack of time) but if there's a PR for it I would definitely look over it and merge it. Unfortunately I'm the only active developer at the moment, so doing it yourself is the only way to get it implemented. And you would help the project a lot.

thx. for your answer here; but sorry to say, it doesn't help. don't you think somebody with that amount of knowledge wouild have made it then by now?
i'm glad that persons like you spent time on this project – very much appreciated here – but these phrases "do it yourself" won't help anybody.

if i could do it, i would have done it – the truth is as easy like that.
if i can help otherwise, even with a donation for this to get reality, i'll do.

sorry, this shouldn't sound too harsh, but i'm a little bit fed up with this phrase "do it yourself" – i know what i can do and nobody (expect those who know me) know what i can do. and i do help quite a bunch of people with their problems related to topics, where i can help.

this projects is important to many, many people. i love to use it, i love to recommend it and i help people to set it up/use it – this is what i can do.

and as sad it is, that the feature request does impose work to others, it would make TVHeadend even better; who can't see the benefit of it, isn't in the boat were i (and others who don't post here) are in. it's a reality, that other (and yes, sometimes not open sourced protocols) have their strong markets.

thx. again for your time spent on this project.
peace. harmony. fun to all.

Have you considered using Jellyfin instead of Plex/Emby? It's a free fork with no fees at all (so no need for a PlexPass). It has a TVHeadend plugin, though I've not used that particular plugin. It also supports free hardware encoding and has clients for Android, Apple, Amazon, web browsers, and some TVs.

[[https://jellyfin.org/docs/general/server/plugins/tvheadend.html]]

And if the TVHeadend plugin doesn't work to your liking, then it apparently supports HDHomeRun direct, though I imagine you have the possibility of conflicts with TVHeadend using them at the same time.

[[https://jellyfin.org/docs/general/server/live-tv/setup-guide.html]]

There are Docker images available, just follow the instructions on its installation page. It should be fairly easy to set up an instance to just quickly test against your HDHomeRun and then see if it is worth the effort to migrate. I'd say an hour or two effort to setup and do a test (less if setups are easy for you to do), and then probably a couple of nights to do a full migration and setup with multiple users with separate/shared libraries for different users.

Initially I'd stream TV to a client on your phone/tablet (not your web browser) since the server would have to transcode for a web browser since your browser probably doesn't your broadcast codecs. So, if you hear your fans suddenly spin up, then you'll need to go through the transcoding setup sections on Jellyfin. (The important bit is to pass the device through and ensure it has the correct permissions):

[[https://jellyfin.org/docs/general/administration/hardware-acceleration.html]]

Of course, you may be heavily invested in Plex so not able to migrate; or perhaps Jellyfin doesn't offer some feature that you currently use.

But, let us know if it helps (or doesn't!)

first up, thx. alot Em! thx. for taking the time to write up.

i do think you misunderstood a small but very important detail: i don't own/have a HDHomeRun device and it's not revolving around to support it as a hardware device. the point here is about to get the PLEX-Server connected to the TVHeadEnd-Server (backend). and because it doesn't support Sat>IP as a protocol*, but HDHomeRun's protocol, this whole thread came up.

so out of respect to your time put into your message here, i gave some more informations below your lines. thx. again.

Em Smith wrote:

Have you considered using Jellyfin instead of Plex/Emby? It's a free fork with no fees at all (so no need for a PlexPass). It has a TVHeadend plugin, though I've not used that particular plugin. It also supports free hardware encoding and has clients for Android, Apple, Amazon, web browsers, and some TVs.

well, i played around with Emby way before the split between Emby/Jellyfin happened. but i never was overly impressed with speed, UI or any other part except back then that it was Open Source. with it also going to be (partly) closed source and all surroundings it wasn't ever going to be an alternative.

And if the TVHeadend plugin doesn't work to your liking, then it apparently supports HDHomeRun direct, though I imagine you have the possibility of conflicts with TVHeadend using them at the same time.

because i have no HDHomeRun device… these are extremely popular in the US and some other parts of the world. i even read about quite a bunch of users here in Europe, which bought these because of their simplicity/reliability. no option for me, because: i have all my hardware, it runs quite perfectly so no need to change anything here.

There are Docker images available, just follow the instructions on its installation page. It should be fairly easy to set up an instance to just quickly test against your HDHomeRun and then see if it is worth the effort to migrate. I'd say an hour or two effort to setup and do a test (less if setups are easy for you to do), and then probably a couple of nights to do a full migration and setup with multiple users with separate/shared libraries for different users.

yep, i know – i do run my PLEX installation as a docker installation since years.

Initially I'd stream TV to a client on your phone/tablet (not your web browser) since the server would have to transcode for a web browser since your browser probably doesn't your broadcast codecs. So, if you hear your fans suddenly spin up, then you'll need to go through the transcoding setup sections on Jellyfin. (The important bit is to pass the device through and ensure it has the correct permissions):

well, i know mostly all about all the options, the support of h/w en-/decoding and stuff. that's not the problem here ;-)

Of course, you may be heavily invested in Plex so not able to migrate; or perhaps Jellyfin doesn't offer some feature that you currently use.

yep, major point here.
PLEX (with Pass) is running for years. put alot time in organizing my library. enjoying the PLEX universe (albeit nothing is perfect) and so this one last point of integration of (Live)TV is missing. i haven't seen one other solution which gets this all-in-one package dealt with as good as PLEX it does.

no need to argue about price, closed source and whatnot – everybody should enjoy what fits their needs.

greets!

Oliver S wrote:

first up, thx. alot Em! thx. for taking the time to write up.

i do think you misunderstood a small but very important detail: i don't own/have a HDHomeRun device and it's not revolving around to support it as a hardware device. the point here is about to get the PLEX-Server connected to the TVHeadEnd-Server (backend). and because it doesn't support Sat>IP as a protocol*, but HDHomeRun's protocol, this whole thread came up.

so out of respect to your time put into your message here, i gave some more informations below your lines. thx. again.

Em Smith wrote:

Have you considered using Jellyfin instead of Plex/Emby? It's a free fork with no fees at all (so no need for a PlexPass). It has a TVHeadend plugin, though I've not used that particular plugin. It also supports free hardware encoding and has clients for Android, Apple, Amazon, web browsers, and some TVs.

well, i played around with Emby way before the split between Emby/Jellyfin happened. but i never was overly impressed with speed, UI or any other part except back then that it was Open Source. with it also going to be (partly) closed source and all surroundings it wasn't ever going to be an alternative.

And if the TVHeadend plugin doesn't work to your liking, then it apparently supports HDHomeRun direct, though I imagine you have the possibility of conflicts with TVHeadend using them at the same time.

because i have no HDHomeRun device… these are extremely popular in the US and some other parts of the world. i even read about quite a bunch of users here in Europe, which bought these because of their simplicity/reliability. no option for me, because: i have all my hardware, it runs quite perfectly so no need to change anything here.

There are Docker images available, just follow the instructions on its installation page. It should be fairly easy to set up an instance to just quickly test against your HDHomeRun and then see if it is worth the effort to migrate. I'd say an hour or two effort to setup and do a test (less if setups are easy for you to do), and then probably a couple of nights to do a full migration and setup with multiple users with separate/shared libraries for different users.

yep, i know – i do run my PLEX installation as a docker installation since years.

Initially I'd stream TV to a client on your phone/tablet (not your web browser) since the server would have to transcode for a web browser since your browser probably doesn't your broadcast codecs. So, if you hear your fans suddenly spin up, then you'll need to go through the transcoding setup sections on Jellyfin. (The important bit is to pass the device through and ensure it has the correct permissions):

well, i know mostly all about all the options, the support of h/w en-/decoding and stuff. that's not the problem here ;-)

Of course, you may be heavily invested in Plex so not able to migrate; or perhaps Jellyfin doesn't offer some feature that you currently use.

yep, major point here.
PLEX (with Pass) is running for years. put alot time in organizing my library. enjoying the PLEX universe (albeit nothing is perfect) and so this one last point of integration of (Live)TV is missing. i haven't seen one other solution which gets this all-in-one package dealt with as good as PLEX it does.

no need to argue about price, closed source and whatnot – everybody should enjoy what fits their needs.

greets!

Just a very small chip in, and apologies if I missed it as skim read due to being at work...

You said "Plex does not support Sat>IP as a protocol*". I may have missed the explanation of the Astrix, but I have an Octo SatIP tuner in the Attic and, although an "Unsupported Device" on Plex it works perfectly?

I've never had to play around but have you tried enabling the TVH SatIP sever, and then doing a device scan on Plex> Mine is detected automatically.. if not try stipulating the IP dress of your TVH server.

Alex Scott wrote:

Just a very small chip in, and apologies if I missed it as skim read due to being at work...

You said "Plex does not support Sat>IP as a protocol*". I may have missed the explanation of the Astrix, but I have an Octo SatIP tuner in the Attic and, although an "Unsupported Device" on Plex it works perfectly?

damn, forgot the asterix – oh well ;-)

• PLEX shows some (very broken) support of Sat>IP since awhile. this starts with often it now recognizing the Sat>IP server (no matter which: TVH, miniSatIP…), then not being able to do a scan to discover services (channels) and later on not being able to watch the channel. there are alot of in betweens, but ultimately not useable at the time. they categorize it as unsupported anyway, so no hope to ever reach (production) quality status.

I've never had to play around but have you tried enabling the TVH SatIP sever, and then doing a device scan on Plex> Mine is detected automatically.. if not try stipulating the IP dress of your TVH server.

(see above answer)
i did and all variants of it. if you got pay tv channels (with your CI card, which works in TVH) no way here via Sat>IP.
PLEX recognizes only FTA channels.

thx.

Oliver S wrote:

Alex Scott wrote:

Just a very small chip in, and apologies if I missed it as skim read due to being at work...

You said "Plex does not support Sat>IP as a protocol*". I may have missed the explanation of the Astrix, but I have an Octo SatIP tuner in the Attic and, although an "Unsupported Device" on Plex it works perfectly?

damn, forgot the asterix – oh well ;-)

• PLEX shows some (very broken) support of Sat>IP since awhile. this starts with often it now recognizing the Sat>IP server (no matter which: TVH, miniSatIP…), then not being able to do a scan to discover services (channels) and later on not being able to watch the channel. there are alot of in betweens, but ultimately not useable at the time. they categorize it as unsupported anyway, so no hope to ever reach (production) quality status.

I've never had to play around but have you tried enabling the TVH SatIP sever, and then doing a device scan on Plex> Mine is detected automatically.. if not try stipulating the IP dress of your TVH server.

(see above answer)
i did and all variants of it. if you got pay tv channels (with your CI card, which works in TVH) no way here via Sat>IP.
PLEX recognizes only FTA channels.

thx.

Unfortunatly plex using ip>sat does not work to tvheadend or i would not have requested this feature 3 years ago. Originally people didnt seem to understand what i was asking for but now people are seeing the advantage of it.

I thought this is what open source was all about and if i could code this i would, im happy to be a tester but could not migrate this code into the project.

Its disapointing that the people on this project seem to be Kodi backers and noone is interested in putting in features that others who like Plex would like.

Shane Kuzmanic wrote:

Its disapointing that the people on this project seem to be Kodi backers and noone is interested in putting in features that others who like Plex would like.

Development was stalled for a few months until I picked this up. You should be glad that there are at least important bug fixes now so it's becoming more stable. Sure, I could just try to somehow put this in but I'd rather focus on important bug fixes rather than implementing new features.

It's disappointing that only a few of the users are interested in putting any features in, because that is what open source software really is: Someone needs it, implements it, and others benefit from it.

Flole Systems wrote:

Shane Kuzmanic wrote:

Its disapointing that the people on this project seem to be Kodi backers and noone is interested in putting in features that others who like Plex would like.

Development was stalled for a few months until I picked this up. You should be glad that there are at least important bug fixes now so it's becoming more stable. Sure, I could just try to somehow put this in but I'd rather focus on important bug fixes rather than implementing new features.

It's disappointing that only a few of the users are interested in putting any features in, because that is what open source software really is: Someone needs it, implements it, and others benefit from it.

Firstly, and most importantly, thank you.

I’ve used / dabbled / relied on TVH for over a decade and I know just how widely deployed it is. If it was to loose yourself and become unmaintained that would be a genuine loss to the entire OTA community.

Regarding users not contributing... unfortunately the skill set is not always there. I have, and will, compile test and submit bug reports... but the limit of my coding ability is bash scripting ( usually tweaked from a forum post! :). ).

That’s said if there is a donation page or the like I will happily donate to keep TVH maintained. I know a lot of FOSS authors / contributors don’t do it for money but it is a way for people like myself to show appreciation and also level of demand for continuation of a application.

Hope that made sense... I had to rewrite the last sentence so it didn’t read I was demanding you continue to work on TVH! Lol

We already lost the main developer that was working on it the last few years, since then this project is not maintained as good as it was before. My knowledge of the code is still limited, so I might be able to help with bug fixes and have done so, but when it somes to big restructuring or adding complex code I need to think about it many times and sometimes making decisions if something should be merged is hard: On one hand I really appreciate any contribution and it's a great feeling to click the merge button, but on the other hand the stability of the code is very important, so when I click the merge button when I shouldn't I would break everything or cause the code to become "bad". When I write own code this is even worse, there is nobody who looks over it so the risk of introducing errors is much higher. If I am not sure about a PR I currently leave it open instead of merging it.

I currently don't know who get's the donations from the about page, I would guess it's the person that runs the servers that this site is running on but I am not sure.

That being said, currently the most important thing is to get more developers onboard. So if you know someone who knows someone who might enjoy working on this feel free to send them over :) Also if you are a software developer yourself but don't have enough time to work on it, some employers offer "open source time" that can be used to work on any open source project so sometimes that is an option aswell.

Also I need to clean up this bug tracker, there are many issues that have been fixed or are not valid reports and sometimes when I have time I can go through all the old ones and close them. So if someone wants to look through all the old issues and comment on those that have been fixed or are invalid feel free to do so, that pushes them to the top and then I can go through and close them. Sometimes there are comments like "my mistake, sorry" and they aren't marked as invalid yet for example. However, if in doubt we currently leave issues that might be fixed open.

Em Smith wrote:

The reason Kodi gets good support is because they are very good and proactive at reviewing and merging patches. Typically changes I've submitted are merged within a couple of days.

Unfortunately HDHomeRun is only partially documented and (last time I checked) in Europe cost 20x more than a USB tuner, so it's not used a lot in Europe and makes testing to see what it does difficult. Plex costs money so makes it difficult to test against.

If Plex uses the basic HDHomeRun API then it looks simple enough to implement. See attached patch and "git apply myfilename.patch" to add it and then recompile.

In TVHeadend UI enable expert mode and then you need to add "persistent authentication" in Config->User->Password, and then add the same user to Config->General->Base in the "HDHomeRun Local User" text entry (visible only with expert mode).

Go to your Plex, enter your TVHeadend address with port such as 192.168.0.1:9981 since autodetect will not work.

This appears to work in Jellyfin and will stream from TVHeadend as LiveTV, though it seems to limit the total number of channels.

Maybe it will work in Plex. Or maybe they use different APIs. Give it a try. I don't know how Plex gets its EPG, perhaps you can get it straight from TVHeadend and it will auto-match the channels.

If it almost works, but not quite, then the API at ip:9981/lineup.json is the one that has URLs and channel numbers.

Thanks so much for your time Em, i will give this a go and report back. If it works then we could get this merged.

Shane

If it works and no problems after a couple of days then I'll submit it.

Couple of other things to help you test if necessary:

The other URL (if nothing at all works) is x.x.x.x:9981/discover.json

That gives the "LineupURL". The server has to calculate the address itself, but just double check to make sure it has calculated it correct in case you are running a strange environment. So it should be "http://x.x.x.x:9981/lineup.json". My guess is that Plex will go to discover.json, get the details then go to lineup.json to get the channel names/URLs. The URLs from lineup.json you should be able to play in VLC to check they work.

Other thing is that in Config->Base->Web Interface there are tick boxes for including channel number/sources with channel names. I'm using that in the HDHomeRun names, so if things don't match up with the EPG then trying disabling those.

On Jellyfin there was a "refresh" button, but to test I would delete the HDHomeRun, check LiveTV menu disappeared, then re-add it.

Shane Kuzmanic wrote:

Em Smith wrote:

If it works and no problems after a couple of days then I'll submit it.

Couple of other things to help you test if necessary:

The other URL (if nothing at all works) is x.x.x.x:9981/discover.json

That gives the "LineupURL". The server has to calculate the address itself, but just double check to make sure it has calculated it correct in case you are running a strange environment. So it should be "http://x.x.x.x:9981/lineup.json". My guess is that Plex will go to discover.json, get the details then go to lineup.json to get the channel names/URLs. The URLs from lineup.json you should be able to play in VLC to check they work.

Other thing is that in Config->Base->Web Interface there are tick boxes for including channel number/sources with channel names. I'm using that in the HDHomeRun names, so if things don't match up with the EPG then trying disabling those.

On Jellyfin there was a "refresh" button, but to test I would delete the HDHomeRun, check LiveTV menu disappeared, then re-add it.

Im being given 403 forbidden for those urls, i created a test user with a password set and choose enable on persistent authentication.
I get the HDHmeRun options in the menu but it has entries for HDHomerun address & Local IP address and local Socket Port Number. Are these all meant to be there?
Plex does not find but i assume this is due to the 403 forbidden.

CORRECTION: lineup.json responds with valid data but discover.json gets 403.

OK. Does lineup.json have "&auth=abcdef" on the end? If so, that means it has correctly detected the hdhomerun username.

I can't see yet why discover.json would fail if lineup.json is working. I'll take a bit more of a look.

Does the user you added have "STREAMING" capability?

Also try with your "admin" user and see if that works.

In Plex you should enter the address of your TVHeadend server. So if it's 192.168.0.5 then you'd enter "192.168.0.5" and "9981".

I retested and with a bad user (does not exist, or does not have permission), I get 401 (unauthorized) instead of 403 (forbidden). The same with the URLs inside the lineup.json.

You can add the following debugging information line around line 1616 in src/webui/webui.c.(AFTER the perm line).

  tvhinfo(LS_WEBUI, "Discover with %p %u %s", perm, perm ? perm->aa_rights : 0, perm ? perm->aa_username : "<none>");

This will log that the discover is being called at all so we know if the problem is the permissions.

So you'll see lines in your log like this:

webui: Discover with 0x7f0750001630 0 test

The last bit is the user, the bit before is the permissions (in this case 0 since the user doesn't exist).

Final thing you can try is running the server with "--noacl" (two minus signs) which disables all permission checking to help diagnose if it is a permission problem or a Plex/TVHeadend problem.

Ah, I just realized what you meant by "local IP address". You mean on TVHeadend (not Plex)? Yes, they should be there but they should be left blank. They are for TVHeadend to talk to a HDHomeRun device when TVHeadend is run inside docker without host network binding. We may need to use them in the future for this bug, but it's not supported yet.

So, you populate the "Local username" on TVHeadend as you have. Then on the Plex you should also have either "Address" or "Address and Port" that should be your TVHeadend's device.

If it still doesn't all work, then post a couple of captures from "curl -v -v -L http://192.168.0.99:9981/discover.json" and a few lines from a lineup.json with TVHeadend running with/without "--noacl" (amend with your IP address), and a screenshot of the Plex setup.

Hopefully we can get it working.
Thanks.

Em Smith wrote:

OK. Does lineup.json have "&auth=abcdef" on the end? If so, that means it has correctly detected the hdhomerun username.

I can't see yet why discover.json would fail if lineup.json is working. I'll take a bit more of a look.

Yes lineup.json is showing profile=pass&auth=PXG.... discover is now working also unsure as to why but rebooted and it come right. When i try and discover from plex the tvheadend debug screen shows

2020-06-11 20:11:11.286 http: 192.168.31.223: HTTP/1.0 GET (1) /lineup_status.json -- 404

and plex fails

If i view lineup_status.json on a real hdhomerun i get a json response of.

{"ScanInProgress":0,"ScanPossible":1,"Source":"Antenna","SourceList":["Antenna"]}

We may need to change '"ScanPossible": 1' to "ScanPossible": 0' and maybe toggle the ScanInProgress to 1. We basically want to prevent clients from trying to do a manual frequency scan and just use the channels that we give it. But, let's try with that patch first and see if it works :)

You should keep the first patch, then apply this patch on top of it.

I've been looking at some postings on plex with their log files, and we might need to generate a device.xml file too, so just working on that just in case.

Just a little though: Instead of providing valid credentials for everyone who has access to an URL, why don't you just configure a static IP for the clients (as far as I understood those are local anyways) and give them permissions? There are already quite some open Tvheadends on the internet, I would prefer to not give out any authentication information when this is used, you would have to limit the users IPs then anyways to not have an open server.

Let's try and get it to work at all first :).

I agree we might need to support giving an address and/or port to restrict access. I hinted at it in comment 65 about local address.

You don't have to give out any authentication information, it is done only at the server. If the user has not explicitly configured the details then the functionality is disabled, although I was going to make it a "configure" option so it can be completely disabled.

Correction real HDHomerun gets 400 bad request on lineup.post

Hopefully getting near. Yes, your first capture suggests it has received no channels.

Have you tried running the TVHeadend with the "--noacl" option I mentioned? Or you could try adding the logging in comment 63 to see if the code is being called.
Are you getting the 403 from curl? Or is it logged in Plex?

The post probably needs:

curl -X POST http://x.x.x.x/lineup.post?scan=start

But, I believe that's to tell the HDHomeRun to scan the frequencies, not to download the existing channel list.

In Plex logs I've seen it does:

ul 26, 2019 23:19:41.936 [5536] DEBUG - DVR:Device: Testing grabber HDHomerun device device://tv.plex.grabbers.hdhomerun/12418B16 at http://192.168.3.124
Jul 26, 2019 23:19:41.936 [5536] DEBUG - HTTP requesting GET http://192.168.3.124/discover.json
Jul 26, 2019 23:19:41.940 [5536] DEBUG - HTTP 200 response from GET http://192.168.3.124/discover.json
Jul 26, 2019 23:19:41.940 [5536] DEBUG - HTTP requesting GET http://192.168.3.124/lineup_status.json
Jul 26, 2019 23:19:41.952 [5536] DEBUG - HTTP 200 response from GET http://192.168.3.124/lineup_status.json
Jul 26, 2019 23:19:46.175 [8772] DEBUG - NetworkServiceBrowser: Parsing SSDP schema for http://192.168.3.124:80/dms/device.xml
Jul 26, 2019 23:19:46.175 [8772] DEBUG - HTTP requesting GET http://192.168.3.124:80/dms/device.xml
Jul 26, 2019 23:19:46.188 [8772] DEBUG - HTTP 200 response from GET http://192.168.3.124:80/dms/device.xml
Jul 26, 2019 23:19:46.188 [8772] DEBUG - NetworkServiceBrowser: found 1 SSDP devices via http://192.168.3.124:80/dms/device.xml
Jul 26, 2019 23:19:46.189 [8772] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.3.124 (HDHomeRun DMS 12418B16)

What is yours doing?

hey guys, nice to see some progress here.

i've played around with several hdhomerun emulators in the past. maybe it can be of help for you, to see the responses of one of them (xTeVe).

my understanding so far is, that PLEX is looking firstly for (hdhomerun and compatible) devices and when it finds one (it can be necessary to restart the PLEX server to be successful) it triggers http://ip_or_dns:port/discover.json to retrieve the basic informations about that device incl. the number of tuners available. /name only as reference for that url/file:

/discover.json

{
"BaseURL": "http://ip_or_dns:port",
"DeviceAuth": "xteve",
"DeviceID": "2020-06-3OU4-2MJGJW:8",
"FirmwareName": "bin_2.1.2",
"FirmwareVersion": "2.1.2",
"FriendlyName": "xTeVe",
"LineupURL": "http://ip_or_dns:port/lineup.json",
"Manufacturer": "Golang",
"ModelNumber": "2.1.2",
"TunerCount": 8
}

at one point (not sure about the order here) it will look for the type of services offered by calling:

/lineup_status.json

{
"ScanInProgress": 0,
"ScanPossible": 0,
"Source": "Cable",
"SourceList": [
"Cable"
]
}

i can only guess that ScanPossible = 0 means, PLEX can't trigger a new scan from that device (because xTeVe in that example has a prepared list of channels). Source can be (to my knowledge Cable, or Satellite).

then lastly the channel list and their respective urls (only a few here):

/lineup.json

[ {
"GuideName": "Das Erste HD",
"GuideNumber": "101",
"URL": "http://ip_or_dns:port/whatever"
}, {
"GuideName": "ZDF HD",
"GuideNumber": "102",
"URL": "http://ip_or_dns:port/whatever"
}, {
"GuideName": "BR Fernsehen Süd HD",
"GuideNumber": "103",
"URL": "http://ip_or_dns:port/whatever"
}
]

in case of xTeVe this lineup represents it's own urls which then get resolved later (probaly when PLEX tunes to them). xTeVe has some more magic going on, because it has some additional files which contain more informations about the channel icons and the direct callable link to tune a channel. if you need more information about that, i could try to resolve them.

as much as i like to help here, my testing possibilities are extremely limited, as i run this whole setup on unRAID inside dockers for all the components. no knowledge of compiling, etc. on my side, so i can only works with prepared docker images, etc.

Thanks, that's useful. When you say "additional files which contain more informations about the channel icons", is that from the xmltv guide it produces?

I've changed ScanPossible to be zero which will hopefully prevent Plex from offering that option of tuning. Shane.Can you try changing in src/webui.c after the "ScanPossible" from 1 to 0 and see if that works for you?

I think that we are returning all the data Plex needs, just slightly different values. It's good to know Plex is flexible about the fields (such as not requiring "Silicondust" as manufacturer).

Do you have any Plex logs when talking to xteve? Are they similar to the ones in comment 76?

The URLs we are returning are like this:

http://1.1.1.1:9981/stream/channel/abcdef01234567890?profile=pass

So they are:

[ {
      "GuideName" : "Channel",
      "GuideNumber" : "300",
      "URL": "http://1.1.1.1:9981/stream/channel/abcdef01234567890?profile=pass" 
}
]

I can see that xTeVe has "SSDP" (so it can presumably be discovered when you hit "discover device"?) We don't have that yet but I'm hoping that's not strictly needed to get it all to work.

Are you on Intel/AMD Ubuntu?

I've run xTevE in a docker. I've spotted one difference in "/device.xml" since ours does not have "uuid:" in front of the uuid. I don't know if that's important to Plex since the xTeVe uuid is an invalid format.

Shane. Could you also change this line in src/webui/webui.c?

"<UDN>%8.8x-745e-5d9a-8903-4a02327a7e09</UDN>" 

"<UDN>uuid:%8.8x-745e-5d9a-8903-4a02327a7e09</UDN>" 

I'll roll up the changes and add a bunch of extra debug later today in to a single big patch to post here.

i'm a little bit busy here today, but i'll try to provide further informations later on.

Hi Em i have made all the changes above (i think) and it does seen to be a permissions issue here are my curl responses.

• Trying 192.168.31.222...
• TCP_NODELAY set
• Connected to 192.168.31.222 (192.168.31.222) port 9981 (#0)

GET /discover.json HTTP/1.1
Host: 192.168.31.222:9981
User-Agent: curl/7.58.0
Accept: */*

• Connection #0 to host 192.168.31.222 left intact { "FriendlyName": "Tvheadend", "BaseURL" : "http://192.168.31.222:9981", "DeviceAuth": "3xw5UaJXhVShHEBoy76FuYQi", "DeviceID": "3C74E92B", "FirmwareName": "hdhomerun_atsc", "FirmwareVersion": "20200101", "LineupURL": "http://192.168.31.222:9981/lineup.json", "Manufacturer": "Silicondust", "ModelNumber": "HDTC-2US", "TunerCount": 6 }kuzmasha@dev-headend:~$

• Trying 192.168.31.222...
• TCP_NODELAY set
• Connected to 192.168.31.222 (192.168.31.222) port 9981 (#0)

GET /lineup.json HTTP/1.1
Host: 192.168.31.222:9981
User-Agent: curl/7.58.0
Accept: */*

• Connection #0 to host 192.168.31.222 left intact

i cant see any additional logging in TVHeadend since adding the login command, is this in the correct place?

if (access_verify2(perm, ACCESS_STREAMING)) {
    tvhinfo(LS_WEBUI, "Discover with %p %u %s", perm, perm ? perm->aa_rights : 0, perm ? perm->aa_username : "<none>");
    access_destroy(perm);
    return http_noaccess_code(hc);
  }

Yes, that's the correct place for the logging (assuming it was inside the lineup function).

I used a different access method in discover compared to the lineup. Now, I've moved it all to the same function as lineup uses since the other access function doesn't populate all the data we need.

I can't see any obvious reason why it would prompt you for authentication. I expect if you did a request to http://testuser:testuserpass@192.168.31.222:9981/lineup.json then it works? (Which isn't a solution since most media players can't do authentication).

The only thing I can think of is perhaps the username doesn't match or has some config that causes the user to not have access, which we interpret at "unauthorized", which the upper level then interprets as "request password."

Just taking a closer look i think the issue is they all have a guide number of 0 this is why its showing the last one only. If we can pass channel number down or a sequential number this may fix it.

I think the lineup.post is expected as we have scanning disabled.

When i do the same query on the HDhomerun the guide numbers are all different not 0

[{"GuideNumber":"1","GuideName":"TVNZ 1","VideoCodec":"H264","AudioCodec":"AC3","HD":1,"URL":"http://192.168.31.170:5004/auto/v1"},{"GuideNumber":"2","GuideName":"TVNZ 2","VideoCodec":"H264","AudioCodec":"AC3","HD":1,"URL":"http://192.168.31.170:5004/auto/v2"},{"GuideNumber":"3","GuideName":"Three","VideoCodec":"H264","AudioCodec":"AC3","HD":1,"URL":"http://192.168.31.170:5004/auto/v3"},{"GuideNumber":"4","GuideName":"Bravo","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v4"},{"GuideNumber":"5","GuideName":"Maori Televisio","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v5"},{"GuideNumber":"6","GuideName":"TVNZ 1 +1","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v6"},{"GuideNumber":"7","GuideName":"TVNZ 2 +1","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v7"},{"GuideNumber":"8","GuideName":"ThreePlus1","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v8"},{"GuideNumber":"9","GuideName":"Bravo PLUS 1","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v9"},{"GuideNumber":"10","GuideName":"PRIME","VideoCodec":"H264","AudioCodec":"AC3","HD":1,"URL":"http://192.168.31.170:5004/auto/v10"},{"GuideNumber":"11","GuideName":"The Edge TV","VideoCodec":"H264","AudioCodec":"AC3","HD":1,"URL":"http://192.168.31.170:5004/auto/v11"},{"GuideNumber":"12","GuideName":"ChoiceTV","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v12"},{"GuideNumber":"13","GuideName":"TVNZ DUKE","VideoCodec":"H264","AudioCodec":"AC3","HD":1,"URL":"http://192.168.31.170:5004/auto/v13"},{"GuideNumber":"14","GuideName":"Breeze TV","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v14"},{"GuideNumber":"15","GuideName":"Te Reo","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v15"},{"GuideNumber":"16","GuideName":"Al Jazeera","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v16"},{"GuideNumber":"17","GuideName":"HGTV","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v17"},{"GuideNumber":"20","GuideName":"TVSN Shopping","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v20"},{"GuideNumber":"25","GuideName":"Shine TV","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v25"},{"GuideNumber":"26","GuideName":"Firstlight","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v26"},{"GuideNumber":"27","GuideName":"Hope Channel","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v27"},{"GuideNumber":"28","GuideName":"ChineseTV","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v28"},{"GuideNumber":"29","GuideName":"TV29","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v29"},{"GuideNumber":"31","GuideName":"Parliament","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v31"},{"GuideNumber":"36","GuideName":"Apna Television","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v36"},{"GuideNumber":"37","GuideName":"PandaTV","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v37"},{"GuideNumber":"50","GuideName":"Radio NZ Nation","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v50"},{"GuideNumber":"51","GuideName":"Radio NZ Concer","VideoCodec":"MPEG2","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v51"},{"GuideNumber":"71","GuideName":"BaseFM","VideoCodec":"MPEG2","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v71"},{"GuideNumber":"200","GuideName":"Kordia TV","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v200"},{"GuideNumber":"201","GuideName":"Kordia Auckland","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v201"},{"GuideNumber":"500","GuideName":"INFO CHANNEL","VideoCodec":"MPEG2","AudioCodec":"AC3","URL":"http://192.168.31.170:5004/auto/v500"},{"GuideNumber":"600","GuideName":"Unknown","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v600"},{"GuideNumber":"601","GuideName":"Unknown","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v601"},{"GuideNumber":"602","GuideName":"Unknown","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v602"},{"GuideNumber":"603","GuideName":"Unknown","VideoCodec":"H264","AudioCodec":"AAC","HD":1,"URL":"http://192.168.31.170:5004/auto/v603"},{"GuideNumber":"5000","GuideName":"Unknown","VideoCodec":"H264","AudioCodec":"AAC","URL":"http://192.168.31.170:5004/auto/v5000"}]

We do pass down the numbers, so mine shows as: "GuideNumber" : "209"

But, perhaps it doesn't work for your channel numbers. I'm assuming you have channel numbers in TVHeadend.

What do your channel numbers look like in TVHeadend? In particular, if you grab
http://1.2.3.4:9981/xmltv/channels then at the top section you will have the "channel" sections and:

  <display-name>209</display-name>

Do they work for you?

Ok I’m just testing with a small IPTV file and all the channels are 0 I will test with a tuner tomorrow with channel numbers.

just as a quick info from my knowledge:
all channels need to have a number set in TVH, else PLEX ignores them. also, it doesn't matter which numbers they have and no need to be continues.
if you'll use the EPG from PLEX later on, these channels get mapped to the numbers from the EPG provider PLEX chooses.

e.g. you set "Das Erste HD" to channel #1 in TVH, then setup the DVR connection PLEX shows that channel still as #1. using the built-in EPG PLEX chooses an EPG-provider and that one lists this channel as #208 then this will be the new number for the channel. also the naming will be taken from the EPG-provider.

This is working correctly now. You need to need to give plex an xmltv path to move forward and the correct path is http://your_tvheadend:9881/xmltv/channels once this is done plex grabs the epg and gives you the grid and linking works fine.

A few notes for this.
1, You can only have one guide per plex server when setting up multiple tuners, apparently this can be got around by adding two turners at the same time in different browser tabs, yet to try.
2, The tuner in plex seems to go into "Device not found" ensure your device is powered on and connected to the network report. The tuner still works but would be nice to trace the keep alive here and stop this.
3, Plex has a limit of 400 guide channels if that's a problem for you.

Thanks so much for all your help here Em you a star.

Glad it works. I thought the "device not powered on" warning could be due to some upnp, but I had the same warning with xTeVe which implements upnp.

I'll wait a couple of days to see if you encounter any obvious problems, otherwise I'll submit it.

Yes agree as if you press scan you just get an error in the tvheadend log.

Also we just need to note in the setup info that you need to create a user with no password to run the service as. It would be tidier if that wasn't needed for people setting this up as then it would simply be a checkbox to enable the service.

The user that you create can have a password (mine do).

I did think about removing the need for a user, but the main advantage to having a user is that you can then use the user configuration options. For example, you can filter your channels by particular tags so you then only export selected channels to your Plex. This helps avoid the 400 channel Plex limit since you can reduce the playlist to specific channels.

I think the default setup creates a blank default user, so the username could be left blank so long as the persistent authentication is enabled for that user.

On your proper HDHomeRun, what results do you have for "curl -X POST http://x.x.x.x/lineup.post?scan=start". What about if you run it twice immediately after each other, does the second one generate an error? Does the lineup_status change during a scan?

I did a little investigation and this lineup.post seems like a generic interface where it's not just scanning but get/set various parameters. But, it would be useful to know for the future since I can find no documentation on what the interface returns.

There is no need for a user, you can use a * entry with ip based authentication. That would also avoid exposing the token over a http interface but force everyone to configure proper ip based entries. I think that's the way we should go as it gives increased security compared to giving access to everyone who has access to the server by giving out the token (and you can even configure individual permissions like for example giving the children access to a few channels only).

Em Smith wrote:

The user that you create can have a password (mine do).

I did think about removing the need for a user, but the main advantage to having a user is that you can then use the user configuration options. For example, you can filter your channels by particular tags so you then only export selected channels to your Plex. This helps avoid the 400 channel Plex limit since you can reduce the playlist to specific channels.

I think the default setup creates a blank default user, so the username could be left blank so long as the persistent authentication is enabled for that user.

On your proper HDHomeRun, what results do you have for "curl -X POST http://x.x.x.x/lineup.post?scan=start". What about if you run it twice immediately after each other, does the second one generate an error? Does the lineup_status change during a scan?

I did a little investigation and this lineup.post seems like a generic interface where it's not just scanning but get/set various parameters. But, it would be useful to know for the future since I can find no documentation on what the interface returns.

So the curl command gives no response at all but if i web to the HDHomerun both turners are then performing a scan.

Shane Kuzmanic wrote:

Em Smith wrote:

The user that you create can have a password (mine do).

I did think about removing the need for a user, but the main advantage to having a user is that you can then use the user configuration options. For example, you can filter your channels by particular tags so you then only export selected channels to your Plex. This helps avoid the 400 channel Plex limit since you can reduce the playlist to specific channels.

I think the default setup creates a blank default user, so the username could be left blank so long as the persistent authentication is enabled for that user.

On your proper HDHomeRun, what results do you have for "curl -X POST http://x.x.x.x/lineup.post?scan=start". What about if you run it twice immediately after each other, does the second one generate an error? Does the lineup_status change during a scan?

I did a little investigation and this lineup.post seems like a generic interface where it's not just scanning but get/set various parameters. But, it would be useful to know for the future since I can find no documentation on what the interface returns.

So the curl command gives no response at all but if i web to the HDHomerun both turners are then performing a scan.

Also i can run the command as many times as i like with no error it just gives no response.

OK, thanks for that. I'll add a lineup.post that just returns nothing. It won't kick off a scan since TVHeadend has separate scan/map channel stages that are best to do via the UI since different people want mapping to work differently (such as merging satellite/antenna channels, tidying up, etc.)

I've submitted the changes.

Unfortunately my trial of Plex stopped today so I can't test against it any more.

If you have time can you try changing "HD2C-2US" in src/webui.c (for model name and model number) to "tvheadend" and see if it still works in Plex?

If it does, can you try changing "hdhomerun_atsc" also to "tvheadend"? That way, I know if we can swap them over to make them less dependent on the official names.

Thanks.

There does still seem to be an issue with permissions, the error in the logs to trap it reports:

2020-06-17 22:17:07.170 [WARNING] webui: hdhomerun server received request but no streaming permission for user [test] [0] [discover]

when i try and view discover or lineup. this error goes in i launch tvheadend --noacl

test user is admin and has fill streaming rights

Plex does not seem to mind the change to tvheadend from HD2C, the process worked the same and it displays tvheadend under silicondust fine.

Em Smith wrote:

Do you have any IP filtering? Such as on "User" with its allowed networks? Do you have a "*" user?

I can't see anything obviously wrong. I've attached a patch that will do a lot more logging.

Stop any processes that access your tvheadend (including your browser!) since it will log lots every time we look up a permission. Then do a "curl http://1.2.3.4:9981/discover.json" and it may give some idea of what's wrong, or at least which paths are being taken.

You can then undo the extra logging by "git reset --hard HEAD" (which will delete all modifications since previous commit).

Thanks, i think its to do with my environment not the code as it doesn't make sense for it not to work.

It seems to be working fine and is reliable now. Only small visual issue is in Plex the tuner shows as off line after a while. It still works but the real homerun doesn’t do this, Can’t find what makes plex think it’s offline anywhere but only a visual issue. I think you can commit this now.

Thanks

Shane Kuzmanic wrote:

It seems to be working fine and is reliable now. Only small visual issue is in Plex the tuner shows as off line after a while. It still works but the real homerun doesn’t do this, Can’t find what makes plex think it’s offline anywhere but only a visual issue. I think you can commit this now.

Thanks

Shane, do you use scrambled channels with it?
for example your TVH instance has one/or more scrambled channel/s which you have a descramble device available for. when you do the channel scan:
a) are these channels recognized as non-scrambled/protected?
b) can you play them back normally in PLEX?

thx.

Oliver S wrote:

Shane Kuzmanic wrote:

It seems to be working fine and is reliable now. Only small visual issue is in Plex the tuner shows as off line after a while. It still works but the real homerun doesn’t do this, Can’t find what makes plex think it’s offline anywhere but only a visual issue. I think you can commit this now.

Thanks

Shane, do you use scrambled channels with it?
for example your TVH instance has one/or more scrambled channel/s which you have a descramble device available for. when you do the channel scan:
a) are these channels recognized as non-scrambled/protected?
b) can you play them back normally in PLEX?

thx.

Yes, this is why this feature was key. It allows TVH to be the consolidation point for IPTV, FTA, and services that need CA. I have tested with scrambled channels and these feed to plex fine.

Just an update, im not sure if its since the last plex update or not but the tuner no longer shows as offline after a few hours. This was visual only as it carried on working but just showed as offline.

Shane Kuzmanic wrote:

Oliver S wrote:

Shane Kuzmanic wrote:

It seems to be working fine and is reliable now. Only small visual issue is in Plex the tuner shows as off line after a while. It still works but the real homerun doesn’t do this, Can’t find what makes plex think it’s offline anywhere but only a visual issue. I think you can commit this now.

Thanks

Shane, do you use scrambled channels with it?
for example your TVH instance has one/or more scrambled channel/s which you have a descramble device available for. when you do the channel scan:
a) are these channels recognized as non-scrambled/protected?
b) can you play them back normally in PLEX?

thx.

Yes, this is why this feature was key. It allows TVH to be the consolidation point for IPTV, FTA, and services that need CA. I have tested with scrambled channels and these feed to plex fine.

thx. Shane! you're right and i think the same about TVH being the central aggregation system for all the different sources of media related to DVB & streams.

i just asked about the scrambled channels, because i can (whilst only partially) remember that i had tried TVHs SAT>IP export feature in the past already with PLEX DVR. and somehow PLEX couldn't (or didn't like to) tune to scrambled channels, albeit TVH could descamble them. it was again that it (somehow) detected that several channels are scrambled ones and it simply refuses from that point on (it says "protected" or something like that for these channles). not sure how, but i could imagine there's a scrambled bit for this information set/sent and so now way.

it's even now the same when using minisatip as source for PLEX DVR. same thing, it sees all channels but all scrambled ones (once again these are playable) are tagged as "proteced" and over/out.

You can choose to remove the scrambled bit in Tvheadend, then it shouldn't be possible for a client to know if something was scrambled or not anymore. That setting is in the Tuner tab, the original issue for this was #4193

Flole Systems wrote:

You can choose to remove the scrambled bit in Tvheadend, then it shouldn't be possible for a client to know if something was scrambled or not anymore. That setting is in the Tuner tab, the original issue for this was #4193

thx. – now i see where i had this info about the scrambled bit ;-)
but not sure, if i had tinkered with this back then.

How would i go about installing this? I installed tvheadend using APT on ubuntu 18.04. Would i have to have a fresh install? Will this be implemented so ill get it from a future update via APT? Sorry if this issent allowd here.

At the moment you would have to compile it yourself. At some point it might become available on apt (as soon as it's merged when you are using the latest branch) but for that to happen a few changes are needed.

Flole Systems wrote:

At the moment you would have to compile it yourself. At some point it might become available on apt (as soon as it's merged when you are using the latest branch) but for that to happen a few changes are needed.

I think i could manage to compile it myself, but would i need to do it on a fresh install or can i compile(recompile?) on an existing install?

You would have to grab the source, compile it (if you are smart you compile it into a deb package) and then you can install it using dpkg, overwriting the old installation but keeping all settings in place.

Flole Systems wrote:

At the moment you would have to compile it yourself. At some point it might become available on apt (as soon as it's merged when you are using the latest branch) but for that to happen a few changes are needed.

Hi Em, what changes are needed to have this combined into the APT build for the next release?

Flole Systems wrote:

You would have to grab the source, compile it (if you are smart you compile it into a deb package) and then you can install it using dpkg, overwriting the old installation but keeping all settings in place.

Thanx ill give it a go :)

Helge Bjorheim wrote:

Flole Systems wrote:

You would have to grab the source, compile it (if you are smart you compile it into a deb package) and then you can install it using dpkg, overwriting the old installation but keeping all settings in place.

Thanx ill give it a go :)

Managed to compile and copile into deb package witch i then installed, but cant find the option where i input the username for hdhomerun in "Config->General->Base in the "HDHomeRun Local User""
I must have done something wrong... my new version is: Build: 4.3-1892~g0f13f5912 (2020-07-07T21:30:35+0000)

Your version isn't "dirty", so it's the unmodified master (that's available over apt aswell). You forgot to manually apply the PR to you local copy.

Flole Systems wrote:

Your version isn't "dirty", so it's the unmodified master (that's available over apt aswell). You forgot to manually apply the PR to you local copy.

Ohh.. how would i do that?

There are multiple ways. I'd try to click on the PR tabs in GitHub, select the correct one, go to the address bar of your browser, append a .diff and you should see a diff file. Copy that to a local file, use patch -z1 < filename.here to apply.

(I almost certainly made a mistake in my instructions, so please correct me).

Flole Systems wrote:

There are multiple ways. I'd try to click on the PR tabs in GitHub, select the correct one, go to the address bar of your browser, append a .diff and you should see a diff file. Copy that to a local file, use patch -z1 < filename.here to apply.

(I almost certainly made a mistake in my instructions, so please correct me).

Ill try and figure it out. Thanx for your help :)

Helge Bjorheim wrote:

Flole Systems wrote:

There are multiple ways. I'd try to click on the PR tabs in GitHub, select the correct one, go to the address bar of your browser, append a .diff and you should see a diff file. Copy that to a local file, use patch -z1 < filename.here to apply.

(I almost certainly made a mistake in my instructions, so please correct me).

Ill try and figure it out. Thanx for your help :)

Just read up on patching a git build, i was manually editing each file at the start of this thread but half way through found out you can patch the source with the files in the thread and then build.

That's why I mentioned the .diff suffix on the PR, then you will get a single patch with the latest changes.

Flole Systems wrote:

That's why I mentioned the .diff suffix on the PR, then you will get a single patch with the latest changes.

Now im running Autobuild.sh after applying this file from the top of this post: 0001-Add-HDHomeRun-server-support-for-LiveTV-only-4461.patch would that be correct?

I don't know what these patches do, that's why I suggested to use the patch directly from GitHub. It might be that you are not getting the latest changes or need to apply multiple patches like this.

Most importantly you are not testing the PR itself like this so any positive feedback can not be considered when making a merge/not merge decision (shouldn't really matter in this case but might be important in other cases).

Flole Systems wrote:

I don't know what these patches do, that's why I suggested to use the patch directly from GitHub. It might be that you are not getting the latest changes or need to apply multiple patches like this.

Most importantly you are not testing the PR itself like this so any positive feedback can not be considered when making a merge/not merge decision (shouldn't really matter in this case but might be important in other cases).

I could not figure out how to do what you mantioned. But now it works and the channels are playing in plex. Was using xteve before and now i deleted that tuner and added tvheadned and works a treat :) Thanx for the help and i will try and figure out the mwthod you said tomorrow and do it all again. Will probably need e fresh clone from github first i guess? Again thax for your great help!!!

I'm sorry, I thought my description was easy to understand. When you go to the repository in a Webbrowser there is a Button that says "Pull Requests", after you clicked on that there should be one about HDHomeRun. Click on that. Now go to the address bar of your browser and just write .diff after what is already in there and it should load the patch.

Flole Systems wrote:

I'm sorry, I thought my description was easy to understand. When you go to the repository in a Webbrowser there is a Button that says "Pull Requests", after you clicked on that there should be one about HDHomeRun. Click on that. Now go to the address bar of your browser and just write .diff after what is already in there and it should load the patch.

Yes it was i just did it wrong the first time and then on all my retryes. i did .diff after a /

Gut it working now with the diff from github. Although no channels will start on that version so i had to go back to the one i made from the .patch file here. This might be something i did wrong though.
Used git apply filname.diff to apply the .diff file. Dont know if that is correct. Used a different command for the .patch file found here (git am --signoff < filename.patch) but that would not run on the .diff file so used apply

using patch -z1 < 1348.diff
leads to the following error:

patching file configure
patching file config_hdhomerun_server_username.md
can't find file to patch at input line 46
Perhaps you should have used the p or --strip option?
The text leading up to this was:
------------------------- |diff --git a/src/config.c b/src/config.c |index 2293d278be..2f56d4a6cf 100644 |--- a/src/config.c |+++ b/src/config.c
--------------------------
File to patch:

Flole Systems wrote:

(I almost certainly made a mistake in my instructions, so please correct me).

You found it, not -z1 but -p1 ;)

Nice thanx :)

Iv built now using the latest from git and that .diff file. No channels will play and all i get is An unknown error occurred if i try to play a channel via the epg page of the tvheadend app. Nothing plays via plex eather.

Hi,II stumbled across this looking for a way to use Tvheadend with plex. I created a patch of the two commits in the pull request for this feature, and applied it to master. Building this, I was unable to play any channel in plex or any other tvheadend client, same unknown error as mentioned above when trying to play from the epg in tvheadend web gui. Reverting the change in http.c (using INT64_MIN for content length of 0) seems to have resolved the issue; I can now watch TV in plex, VLC and through the Tvheadend web gui.

INT64_MIN is a negative number, that shouldn't be in there. Instead it should be 0.

Thanks. The existing http API used "0" to mean "unknown" and then repurposed INT64_MIN to mean "empty document". Since the lineup.post returned an empty document, we had to alter the http.c to pass through the empty size. But, looks like it had a knock-on effect for some clients.

I've fixed up the lineup.post to send a document with some text instead so we can revert the INT64_MIN change. I'll post the changes and some minor changes to the PR.

Thanx for the update. Works great now. Been using it for several days now using the patch file from this post and iv had 0 problems. So this sees solid!

Em Smith wrote:

I looked in to providing an unraid docker version for Oliver to test, but it's fairly difficult (sorry).

Hey Em, that's really nice – i would have loved to test!

One idea though: on unRAID we can use standard docker images... the only difference is specific settings like mountpoints for static files like config files, etc. or environment variables need to be provided by the template which sets all up. it is possible to do this manually by hand and i'm willing to do so for testing purposes.

if you would provide a list with environment variables which TVH needs for operation (which then get passed into the docker container) i could test it.
we probably need a few persistent directories (for example /config) i can bindmount it into the container; this then translates into a set path on unRAIDs storage.

the names of environment variables can be freely chosen (probably some restrictions apply, but when used with a prefix like TVH_CONFIG there shouldn't be any problem) and can be any number of them.

i'm ready to help...

The guide I found was here:
https://forums.unraid.net/topic/90487-creating-your-own-docker-containers-howto/

Is your unraid Intel? I've never installed it. Is your tvheadend docker from "linuxserver"? I found their repository here:
https://github.com/linuxserver/docker-tvheadend

So I imagine you would:

git clone --depth 1 https://github.com/linuxserver/docker-tvheadend && cd docker-tvheadend && docker build -t oliver/tvheadend  .
(make sure you include the final period!)

This will build the current version (without any patches). It normally creates lots of files in your root partition ("/"), so you need to ensure you have a few GB spare there, but it may differ on your unraid box and store the build images elsewhere.

I declined becoming a Tvheadend maintainer (so can't merge the patch), and the patch is unlikely to make its way in to the official Tvheadend and time soon, so you'd have to make an effort constantly to build your own version with the merged patch.

If the above docker build works then I'll figure out how to amend the Dockerfile to merge the patch for you. My guess (untested) is that you would download the patch, put it in to the "docker-tvheadend/patches" folder and change the line in "Dockerfile" from

 git checkout ${TVHEADEND_COMMIT} && \

 git checkout ${TVHEADEND_COMMIT} && git apply -3 patches/0001-hdhomerun-Add-HDHomeRun-server-support-for-LiveTV-on.patch && \

So

git clone --depth 1 https://github.com/linuxserver/docker-tvheadend
cd docker-tvheadend
cp ~/Downloads/0001-hdhomerun-Add-HDHomeRun-server-support-for-LiveTV-on.patch patches/.
(edit Dockerfile)
docker build -t oliver/tvheadend  .

(I'm assuming you're running 4.3/master: If not, then don't do any of the above or you'll have your config files upgraded and find it difficult to downgrade).

You may then need to follow the additional instructions on the first link for getting it to show in the correct tabs on unraid. Sorry I can't offer more detailed advice.

Actually, that should be:

 git checkout ${TVHEADEND_COMMIT} && git apply -3 /tmp/patches/0001-hdhomerun-Add-HDHomeRun-server-support-for-LiveTV-on.patch && \

You may need to avoid using ".patch" suffix to avoid the script trying to apply the patch when it builds the perl components, i.e., rename the file to "0001-hdhomerun.p"

Em Smith wrote:

Actually, that should be:
[...]
(since the docker copies the patches to /tmp/patches).

You may need to avoid using ".patch" suffix to avoid the script trying to apply the patch when it builds the perl components, i.e., rename the file to "0001-hdhomerun.p"

sorry Em,

i probably didn't make myself clear with the unRAID vs. Docker thingie ;-)

unRAID manages all docker containers for you via GUI (you probably can do manually stuff, but i wouldn't want to mess with it).
i'm using linuxserver.io's TVH docker for unRAID, but i could install also from Docker Hub directly (but then i have no template for all the necessary additional values needed – i would need to manually provide these parameters via my own 'template').

that means, as soon as there would be a docker available via docker hub (search), i then could install it from there and add my parameters via environment variables for this docker container.

made it a bit clearer? (hopefully)
thx.

Tryed using it in emby and it wont start there. Tryed with xteve and it worked at once so dont seem to be the fault of emby:
Error:
2020-07-17 16:30:09.088 Info LiveTvManager: Opening channel stream from Emby, external channel Id: hdhr_101
2020-07-17 16:30:09.088 Info LiveTV: Streaming Channel hdhr_101
2020-07-17 16:30:09.088 Info HdHomerunHost: GetChannelStream: channel id: hdhr_101. stream id: native_7ce9fd452946804bf450f723a11f06ea_b41d4305a80a79fb34980b9cbd994d3a profile: native
2020-07-17 16:30:09.089 Info SharedHttpPipelineSource: Opening SharedHttpPipelineSource Live stream from http://192.168.xxx.xxx:9981/stream/channel/dd72b9d5b5e1eecf3f183ca568407cc3?profile=pass&auth=(secrect)?transcode=none
2020-07-17 16:30:09.089 Info HttpClient: GET http://192.168.xxx.xxx:9981/stream/channel/dd72b9d5b5e1eecf3f183ca568407cc3?profile=pass&auth=(secrect)?transcode=none
2020-07-17 16:30:09.092 Info HttpClient: Http response 401 from http://192.168.xxx.xxx:9981/stream/channel/dd72b9d5b5e1eecf3f183ca568407cc3?profile=pass&auth=(secrect)?transcode=none after 3ms. HeadersServer=HTS/tvheadend, Cache-Control=no-cache, WWW-Authenticate=Basic realm="tvheadend", Connection=close
2020-07-17 16:30:09.098 Error HdHomerunHost: Error opening tuner

You're the first to test with Emby!

The URL that your Emby has logged doesn't look right to me since it should have one "?" and the other arguments should be joined by "&". It seems your Emby has appended "?transcode" instead of "&transcode"

Yes, looks like it hardcodes it here:
https://github.com/MediaBrowser/Emby/blob/master/Emby.Server.Implementations/LiveTv/TunerHosts/HdHomerun/HdHomerunHost.cs#L614

So, it means we (correctly) misinterpret the auth string to have "?transcode=none" on the end (rather than a separate "transcode" argument).

Unfortunately, it would almost certainly be wrong to try and alter our "http_parse_args" function to pretend a "?" is an "&" since it could affect the WebUI since browsers do the escaping correctly.

Perhaps you could modify src/webui.c and alter the line around 1558 in hdhomerun_server_lineup from:

       sprintf(url, "http://%s:%u/stream/channel/%s?profile=pass%s%s",

       sprintf(url, "http://%s:%u/stream/channel/%s?profile=pass%s%s&extraarg=t",

Iv asked on the Emby beta forum and hope for some feedback from them.
https://emby.media/community/index.php?/topic/88353-tvheadend-and-emby/

Theyr going to fix it in the next release :)

Hey all, I'm one of the core project leaders of Jellyfin. Having this feature built in to TVHeadend would be a massive benefit to a lot of our users, myself included. Is there anything we can do to help get this merged?

Anthony Lavado wrote:

Hey all, I'm one of the core project leaders of Jellyfin. Having this feature built in to TVHeadend would be a massive benefit to a lot of our users, myself included. Is there anything we can do to help get this merged?

Offer acceptable patch to
https://github.com/tvheadend/tvheadend

saen acro wrote:

Anthony Lavado wrote:

Hey all, I'm one of the core project leaders of Jellyfin. Having this feature built in to TVHeadend would be a massive benefit to a lot of our users, myself included. Is there anything we can do to help get this merged?

Offer acceptable patch to
https://github.com/tvheadend/tvheadend

I think i will just get merged into the next version. I have been using it for a while now issue free.

It wasn't initially clear to me that the PR was on GitHub.

For reference, because I don't see it linked anywhere else: https://github.com/tvheadend/tvheadend/pull/1348

I've made a comment there as well.

Flole998 aka Flole Systems is only one can commit it.

I also wait to improve some other PR's.
But as some other developers he is more "bureaucratically" active ;)

I have case when one developer ask me to fill out a few page survey,
to see if there is a problem, no matter that I show him an easy reproduction of the same.

Nothing personal Flole.

I am not the only one who can commit but the only one who hasn't left and actually wants to commit ;)

I leave PRs open for some time usually to wait for reports of people who tested those. So if someone tests a PR and it works, feel free to comment on it, if someone tests a PR and sees an issue, feel even more free to comment on it. For this one I requested changes as I do not want to punch a hole in the security system: For HDHomeRun you are basically allowing everyone without authentication access, so mapping it to an user doesn't seem right to me. Whoever requests the right URL will receive an access token, that has no security and so the user should notice that and that is the case when the user has to create an "allow all from IP xyz" entry, because that is exactly what you are actually doing: Allowing everyone from an IP Range access. That means the current implementation would need to be reduced by a few lines to address that.

Flole Systems comit to 4.3 is not stable so I dont see problem for commits,
new comits are tested by lot more people.

About URL, cut ticket part, work in colaboration with others add modified by you code,
else there is a https://tvheadend.org/issues/5741 with can accelerate testing of proposed patches ;)

I understand that not all are multifunctional programers but collaboration is for that.

p.s.
https://tvheadend.org/projects/tvheadend/wiki/Team vote to add Flole Systems to list ;)

I'm trying to not break 4.3 now though as when I find some time and figure out how to do it there'll be the branch for a new stable and dev release. Then new dev can also include changes where I am not sure if those are working and/or well-tested.

I haven't found time to do it and I was still hoping that someone else removes the token and tests this.

Flole Systems wrote:

I'm trying to not break 4.3 now though as when I find some time and figure out how to do it there'll be the branch for a new stable and dev release. Then new dev can also include changes where I am not sure if those are working and/or well-tested.

I haven't found time to do it and I was still hoping that someone else removes the token and tests this.

Hi,
can you please make a tutorial how to patch a clean "git clone" ? the idea sounds awesome but i have no knowhow hot to put in practice...
thx. Mihai.