[mythtv] diseqc

[Yeasah Pell]

>This is mainly because I'm fearful of touching it because I have
>neither here to do any testing with. If you could come up with a
>clean DiSEqC implementation this would be much appreciated.
>The code is just scary in so many ways, just look at that
>handle_diseqc loop in DVBChannel, retries really should be
>handled within the DiSEqC class, don't you think?
>  
>
Absolutely. There's a ton of things like that in the diseqc stuff.

>Chained DisEqC devices aren't handled, except for the special
>case of a switch+rotor*.  We should at minimum support a tree
>of switches, possibly ending in rotors and other devices;
>preferably we should support devices anywhere in the tree.
>This would require a new setup GUI in addition to the DiSEqC
>code changes.
>  
>
I deliberately avoided talking about cascaded switches (didn't want to 
get lynched), but you're absolutely right. :-)

There's other even more crazy situations that can arise with rotors too:

    * Two tuners driven by LNBs that are attached to the same motor. The 
first card controls the position, and the second one is a slave.
    * Two tuners driven by daisy chaining a single LNB. The first card 
controls the position, polarization and frequency range, and the second 
one is a slave (VDR does support this with a plugin.)

Given that this has scheduling ramifications, and that even just 
recording multiple programs from a single multiplex is AFAIK still in 
development (right?), that kind of stuff seems way out there (certainly 
outside this discussion), but they are real world configurations that 
are definitely useful.

>BTW Do you know if there is some way to determine when a rotor
>command has been processed, i.e. when the dish is pointing where
>you told it too? It would greatly aid the tuning code to know this.
>  
>
DiSEqC 2.0 supports bidirectional commands, and the spec defines 
everything you'd need to know what the motor is doing. Unfortunately I 
don't know of any motor that supports this, and even if they existed, 
the linux dvb api doesn't support 2.0 (although many cards do.) However, 
for my setup I have the diseqc class calculate how long it will take to 
do the move based on the last known location, and the motor manufacturer 
specifications for the angular speed at 13V and 18V. It works fairly 
well, though it's obviously not as good as having real motor feedback.