[mythtv-users] Rotor issues

[Peter Bienstman]

OK, I've created a quick and dirty hack which does precisely that:

diff --git a/mythtv/libs/libmythtv/diseqc.cpp b/mythtv/libs/libmythtv/diseqc.cpp
index 0eadbea..9df215c 100644
--- a/mythtv/libs/libmythtv/diseqc.cpp
+++ b/mythtv/libs/libmythtv/diseqc.cpp
@@ -2091,8 +2091,15 @@ bool DiSEqCDevRotor::ExecuteUSALS(const
DiSEqCDevSettings&, const DTVMultiplex&,
     cmd[0] = ((azimuth > 0.0) ? 0xE0 : 0xD0) | ((az16 >> 8)  &0x0f);
     cmd[1] = (az16  &0xff);

-    return m_tree.SendCommand(DISEQC_ADR_POS_AZ, DISEQC_CMD_GOTO_X,
-                              m_repeat, 2, cmd);
+    bool err = m_tree.SendCommand(DISEQC_ADR_POS_AZ, DISEQC_CMD_GOTO_X,
+                              m_repeat, 2, cmd);
+    LOG(VB_CHANNEL, LOG_INFO, LOC + "Waiting");
+       sleep(5);
+    LOG(VB_CHANNEL, LOG_INFO, LOC + "Done");
+       return err;
+
+    //return m_tree.SendCommand(DISEQC_ADR_POS_AZ, DISEQC_CMD_GOTO_X,
+    //                          m_repeat, 2, cmd);
 }

 double DiSEqCDevRotor::CalculateAzimuth(double angle) const

Compiling mythtv from source actually went surprisingly easy :-)

Now switching satellites works without any problems. It's obviously
not a patch that can go into production, if only because of the
hardcoded delay. Also, there seems to be already code in that file to
determine when the rotor is still moving. However, it does not seem to
work, perhaps because disceqc 2.0 is required?

Anyhow, I'll open a bug report on this.

On Wed, May 25, 2016 at 4:51 PM, Peter Bienstman
<peter.bienstman at gmail.com> wrote:
>>       I tried tracing the code and gave up on the logic being used at
>> the moment. It seems to do a whole lot of nothing to me. It appears to
>> just do a bunch of calculations and then just exit after a while. Sort
>> of a big loop for i = 1 to 10,000,00
>
> What would probably already be helpful is simply waiting for a certain
> amount of time (best user configurable) before that code exits.
>
> Perhaps that's what this for-loop was supposed to accomplish?
>
> I don't really see a better alternative: as far as I can see DiSeqC 1.3 does
> not seem to have a command to query if the rotor is still moving. And making
> an estimate of turning speed based on the previous location seems a lot of
> work to get robust, because you'd need to store the previous location.
>
> Peter
>