danielk at cuymedia.net
Wed May 24 20:00:02 UTC 2006
On Wed, 2006-05-24 at 15:33 -0400, Yeasah Pell wrote:
> The DVB DiSEqC code in myth has some shortcomings that make it difficult
> to use for my hardware. I'd like to have a quick discussion about what's
> wrong with it, and the best way to improve the state of things.
> I have already done some of this work, but I'd like some feedback as to
> whether this is perceived as being generally useful, and if so, whether
> this seems like a good approach.
Both the DiSEqC code and the CAM code are a mess.
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?
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
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.
* You probably just need to reconfigure if this combo isn't working,
the x10 switch was aliased with this for a few weeks in the code.
I created the enum to prevent this from happening again. i.e. Newly
configured devices shouldn't be aliased anymore.
More information about the mythtv-dev