Feature #2762: More intelligent tvheadend stacking (proxy?) - Tvheadend

Feature #2762

More intelligent tvheadend stacking (proxy?)

Added by B C over 9 years ago. Updated over 8 years ago.

Status:

New

Priority:

Normal

Assignee:

Category:

Infrastructure

Target version:

999

Start date:

2015-12-01

Due date:

% Done:

100%

Estimated time:

(Total: 0.00 h)

Description

Well quite a big feature request :-). Would it be possible to add a "tvheadend" input type as DVB source which combinies some features of SAT>IP (share a complete network) and htsp (reencoding/compression)? Right now we can either use SAT>IP which does not feature compression, or add single channels, but my goal would be to be able to share a complete network (or in terms of access control specific input sources/dvb adapters) to somebody else without me being responsible for what channels he actually wants to include in his channel list an with the comfort of not having to add the url manually for each channel on the tvheadend client side. From the server point of view, the web api already provides everything needed except source based access control (well with a custom tag which includes all services to be exported it would even support that as well but with a lot of administrative effort), so the main work would be to add the special input device. With this feature, enthusiasts/freaks could overcome geographic restrictions. So I could e.g. make the sky visible from europe available to someone in the US while I can sniff in the US ether...
A lot of us have enough bandwidth and free devices most of the time. Of course I could also add another backend to my player (Kodi) but it would not integrate as nicely (in terms of channel selection/order) and would have to be added/maintainend on every single client. Also if I've more friends from a specific region, I could merge for backup.......

Subtasks

History

Updated by Digi Hoe over 9 years ago

I think it's a good idea, but I would like to see the DVB devices as input sources from the slave/client tvheadend so I can setup diseqc/rotor on these as well. From my point of view this would provide a good alternative to long cable runs, I have powerline network setup so instead I would place small client/slave (rpi) tvheadends in diffrent locations all over my building and have my server with reencoding in a diffrent location (maybe even without any dvb connected to it at all). In my mind it will be easier than using vTuner/IP>SAT.

I have kodi with tvheadend client setup in several rooms and would like to connect to only one server and get all my services (cable/terrestial/sat) and as a bonus the shorter cables needed the better the signal quality for sure. Right now I have 4 terrestial tuners (shares cable), 1 cable tuner (one cable) and 3 satellite tuners (3 different cables) and the cables start in different parts of the building.

Since you were on the subject of channellists here´s my idea;
I would like to open up for diffrent channellists (connect channellist with user), kodi setup in the kids room can have diffrent channels than in the teenagers room, in the master suite another channellist, and so on. For me it would be easier.

Best regards!

Updated by Jaroslav Kysela over 9 years ago

Digi Hoe wrote:

I think it's a good idea, but I would like to see the DVB devices as input sources from the slave/client tvheadend so I can setup diseqc/rotor on these as well.

What is missing in the current implementation ? Just define networks with unique SAT>IP Source numbers and you can get them all in the slave tvh... The rotor/diseqc configuration should be configured only on the master tvh.

Updated by saen acro over 8 years ago

Jaroslav Kysela wrote:

What is missing in the current implementation ? Just define networks with unique SAT>IP Source numbers and you can get them all in the slave tvh... The rotor/diseqc configuration should be configured only on the master tvh.

Missing configuration transfer that what is missing
when on "Master" TVH connect "Slave" TVH why do we have to make already done configuration

This is maby most stupid thing in SAT>IP rescanning on any new device
same as on any new HTS client (Kodi for example) to need new scan new picons setup etc.

Updated by Jaroslav Kysela over 8 years ago

saen acro wrote:

Jaroslav Kysela wrote:

What is missing in the current implementation ? Just define networks with unique SAT>IP Source numbers and you can get them all in the slave tvh... The rotor/diseqc configuration should be configured only on the master tvh.

Missing configuration transfer that what is missing
when on "Master" TVH connect "Slave" TVH why do we have to make already done configuration

This is maby most stupid thing in SAT>IP rescanning on any new device
same as on any new HTS client (Kodi for example) to need new scan new picons setup etc.

I've not quoted the original request. And I'm getting overloaded, so I'm trying to concentrate to bug-fixes and my requirements. More intelligent TVH stacking is not on the list :-(