Tvheadend dvb config revamp » History » Revision 11
Revision 10 (Andreas Smas, 2010-08-17 21:52) → Revision 11/15 (Andreas Smas, 2012-01-23 22:22)
There are a few problems with how the TV adapter tab is implemented today
* It cannot handle a large amount of services. With DVB-S you can easily hit >1k services. Ticket #100
* It's hard (but possible via sorting) to see which services that is transmitted on which mux.
* The DVB satconf solution is a bit cumbersome
* Updates to the quality meter indicator refreshed the grid in a way that is bad UX. Ticket #108
* If a DVB adapter is renamed by the kernel after boot (/dev/dvb/adapterX -> /dev/dvb/adapterY) the user must do a lot of work
* Inter-adapter dependencies are not handled (adapters with both analog and digital receivers, etc)
Therefore the plan is to totally redesign how Tvheadend interacts with hardware.
This rewrite will not be configuration compatible and will therefore bump Tvheadend version to 3.x
h1. Device tree
This tree will present the available devices to the user
<pre>
+ DVB Adapter #1
| + DVB-C Frontend
|
+ DVB Adapter #2
| + DVB-T Frontend
| + DVB-C Frontend
|
+ DVB Adapter #3
| + DVB-S Frontend
| | + Switchport 1
| | + Switchport 2
| | + Switchport 3
| | + Switchport 4
| | + Switchport n
| + DVB-T Frontend
|
+ V4L Adapter #1
+ Tuner
+ Composite
+ S-Video
</pre>
Pressing on a node will present the user with information about the entry and a few configuration options as follows:
h3. DVB / ATSC Adapter ===
Info ====
Various information about the hardware
h4. Config
* Enable/Disable adapter
h3. DVB-C / DVB-T / ATSC Frontends
===
Info ====
TBD
h4. Config
* Network the frontend is attached to
* If this device may update network configuration
h3. DVB-S Frontends
===
Info ====
TBD
h4. Config
* Number of Diseqc switchports
or
* Network the frontend is attached to
* If this device may update network configuration
* LnB configuration
h3. Switchport
===
Info ====
TBD
h4. Config
* Network the switchport is attached to
* If this device may update network configuration
* LnB configuration
h3. V4L adpater
===
Info ====
Various information about the hardware
h4. Config
* Enable/Disable adapter
h3. V4L frontends
===
Info ====
Various information about the hardware
h4. Config
* TV system type (PAL, NTSC, etc) (for tuners)
* Network the frontend is attached to
h1. Device mapper
Upon startup Tvheadend will try to map the available hardware to the adapters as good as it can.
In Tvheadend 2.x it was required that the stored configuration about the adapter exactly matched the plugged in hardware.
Instead Tvheadend 3.x will try to map hardware to configured devices according to the following ruleset:
* device type AND device name AND bus-id AND device path
* device type AND device name AND bus-id
* device type AND device name
* device type AND bus-id
* device type
||device path||Path in filesystem||/dev/dvb/...||
||bus-id||Hardware address||Bus 001 Device 004: ID 0ccd:0038 [[TerraTec]] Electronic GmbH Cinergy T2 DVB-T Receiver
||device-name||Name of device(vendor) as reported via DVB API||ST STV0297 DVB-C||
||device-type||Frontend type(s)||DVB-T, DVB-C, etc||
It will start will all devices and try rule 1 then all devices that could not be mapped and rule 2, and so on.
This will mitigate problems when USB controllers probe devices in different order, etc
Also you can swap your DVB hardware to a new one (different vendor) and still have tvheadend map it correctly.
If the mapper cannot find a hardware device using the first rule the adapter info/configuration will highlight this
and the user will be able to "nail" the configuration to the detected hardware. Ie. to acknowledge to Tvheadend
that: "Yes, this is the correct hardware. I've changed/moved it" or whatever
h1. Networks
In Tvheadend 2.x a DVB network (ie. a collection of DVB Muxes) are implicitly tied to a DVB adapter.
There are a number of drawbacks with this
* Adding another adapter to the same network require all muxes to be rescanned or copied from an already present adapter
* Replacing an adapter will void all configuration so it needs to be reconfigured.
Instead Tvheadend 3.x will keep the Network configuration separated from the adapter configuration.
This obviously fixes the two caveats mentioned above.
h1. LNB configuration
Tvheadend 2.x have a set of preconfigured LNBs to select from. Tvheadend 3.x will also have those but also make it possible to enter LNB parameters manuallt.
* It cannot handle a large amount of services. With DVB-S you can easily hit >1k services. Ticket #100
* It's hard (but possible via sorting) to see which services that is transmitted on which mux.
* The DVB satconf solution is a bit cumbersome
* Updates to the quality meter indicator refreshed the grid in a way that is bad UX. Ticket #108
* If a DVB adapter is renamed by the kernel after boot (/dev/dvb/adapterX -> /dev/dvb/adapterY) the user must do a lot of work
* Inter-adapter dependencies are not handled (adapters with both analog and digital receivers, etc)
Therefore the plan is to totally redesign how Tvheadend interacts with hardware.
This rewrite will not be configuration compatible and will therefore bump Tvheadend version to 3.x
h1. Device tree
This tree will present the available devices to the user
<pre>
+ DVB Adapter #1
| + DVB-C Frontend
|
+ DVB Adapter #2
| + DVB-T Frontend
| + DVB-C Frontend
|
+ DVB Adapter #3
| + DVB-S Frontend
| | + Switchport 1
| | + Switchport 2
| | + Switchport 3
| | + Switchport 4
| | + Switchport n
| + DVB-T Frontend
|
+ V4L Adapter #1
+ Tuner
+ Composite
+ S-Video
</pre>
Pressing on a node will present the user with information about the entry and a few configuration options as follows:
h3. DVB / ATSC Adapter ===
Info ====
Various information about the hardware
h4. Config
* Enable/Disable adapter
h3. DVB-C / DVB-T / ATSC Frontends
===
Info ====
TBD
h4. Config
* Network the frontend is attached to
* If this device may update network configuration
h3. DVB-S Frontends
===
Info ====
TBD
h4. Config
* Number of Diseqc switchports
or
* Network the frontend is attached to
* If this device may update network configuration
* LnB configuration
h3. Switchport
===
Info ====
TBD
h4. Config
* Network the switchport is attached to
* If this device may update network configuration
* LnB configuration
h3. V4L adpater
===
Info ====
Various information about the hardware
h4. Config
* Enable/Disable adapter
h3. V4L frontends
===
Info ====
Various information about the hardware
h4. Config
* TV system type (PAL, NTSC, etc) (for tuners)
* Network the frontend is attached to
h1. Device mapper
Upon startup Tvheadend will try to map the available hardware to the adapters as good as it can.
In Tvheadend 2.x it was required that the stored configuration about the adapter exactly matched the plugged in hardware.
Instead Tvheadend 3.x will try to map hardware to configured devices according to the following ruleset:
* device type AND device name AND bus-id AND device path
* device type AND device name AND bus-id
* device type AND device name
* device type AND bus-id
* device type
||device path||Path in filesystem||/dev/dvb/...||
||bus-id||Hardware address||Bus 001 Device 004: ID 0ccd:0038 [[TerraTec]] Electronic GmbH Cinergy T2 DVB-T Receiver
||device-name||Name of device(vendor) as reported via DVB API||ST STV0297 DVB-C||
||device-type||Frontend type(s)||DVB-T, DVB-C, etc||
It will start will all devices and try rule 1 then all devices that could not be mapped and rule 2, and so on.
This will mitigate problems when USB controllers probe devices in different order, etc
Also you can swap your DVB hardware to a new one (different vendor) and still have tvheadend map it correctly.
If the mapper cannot find a hardware device using the first rule the adapter info/configuration will highlight this
and the user will be able to "nail" the configuration to the detected hardware. Ie. to acknowledge to Tvheadend
that: "Yes, this is the correct hardware. I've changed/moved it" or whatever
h1. Networks
In Tvheadend 2.x a DVB network (ie. a collection of DVB Muxes) are implicitly tied to a DVB adapter.
There are a number of drawbacks with this
* Adding another adapter to the same network require all muxes to be rescanned or copied from an already present adapter
* Replacing an adapter will void all configuration so it needs to be reconfigured.
Instead Tvheadend 3.x will keep the Network configuration separated from the adapter configuration.
This obviously fixes the two caveats mentioned above.
h1. LNB configuration
Tvheadend 2.x have a set of preconfigured LNBs to select from. Tvheadend 3.x will also have those but also make it possible to enter LNB parameters manuallt.