342 replies to this topic

[littlesat]

This means the cullpit isn’t found yet?!

[Erik Slagter]

That means, like I am already saying for some time, we are at the start of the process of finding the root cause. There are no simple solutions for complex issues.

[Erik Slagter]

sec_sequence.push_back( eSecCommand(eSecCommand::SLEEP, m_params[DELAY_AFTER_LAST_DISEQC_CMD]) );

Increased that to 1000 (1 second). Makes no difference for the recording problem and just makes the STB very sluggish. Commands are still sent 1ms apart.

I think the next step is to try other parameters.

 

If all of them fail, apparently we have an issue where enigma doesn't wait for each tuner to be tuned before going to the next. I can image in a simple setup, where all tuners are independent that is the best way to go, minimal delay. But if some of the tuners are looped through (regular, FBC and/or SCR) it may be better to wait for a tuner to have LOCK before continueing to the next. I am not even sure enigma recognises that more than one tune request is done at the same time. If not, we may even have to start there.

[athoik]

If all of them fail, apparently we have an issue where enigma doesn't wait for each tuner to be tuned before going to the next. I can image in a simple setup, where all tuners are independent that is the best way to go, minimal delay. But if some of the tuners are looped through (regular, FBC and/or SCR) it may be better to wait for a tuner to have LOCK before continueing to the next. I am not even sure enigma recognises that more than one tune request is done at the same time. If not, we may even have to start there.

I have already post a patch (few pages ago) that recognizes that a (linked) tuner is already in a tuning process.

Also we added a random SEC sleep.

Anyway the logic is here:

If the delay is -1 (default init value) and tuner differs than the current tuner, and state of the other tuner is tuning and the current sequence on the current tuner is on begin..

Then do something smart and set delay to 0 in order not to re-enter.

The sec_fe != this && sec_fe->m_state == stateTuning && m_sec_sequence is the minimum check required.

@@ -1583,6 +1583,14 @@ int eDVBFrontend::tuneLoopInt()  // called by m_tuneTimer
                                prev->inc_use();
                        }
                }
+               else if (delay == -1 && sec_fe != this && sec_fe->m_state == stateTuning &&
+                       m_sec_sequence && m_sec_sequence.begin() == m_sec_sequence.current())
+               {
............................. do something smart here?
+                       delay = 0;
+               }
        }

        if ( m_sec_sequence && m_sec_sequence.current() != m_sec_sequence.end() )

[Erik Slagter]

Does this operate on FBC only? Because that would be incorrect. It should operate on all tuners that are looped through, even if they're separate tuners, they would have the same issue.

 

If none of the SEC delays give the solution, I think we should, indeed, explore this.

[littlesat]

Good point Erik and indeed we should do the same for looped tuners...

[athoik]

No, it simply detects linked satellites tuners in tuning state.

So, the do "something smart here", might add an extra SEC delay every time a linked tuner is in stateTuning.

[Erik Slagter]

So what you're saying is that you're now preventing ANY tuner to be in tuning state at the same time of any tuner?

 

It may be good enough, but we really need to overthink the consequences. For instance, what happens when recording should start while I am scanning or I am using the signal finder...

 

So my gut feeling says we should try to discriminate between tuners that are linked together and those that are not.

[athoik]

In case at least 2 linked tuner are concurrently tuning, we can detect it and delay sec? all except one.

[Erik Slagter]

If that can be done 

• without delaying the user interface and other components of enigma
• and have if configurable

I have no objections.

[athoik]

Then focus on retries? Find why retries also take that much?

(because it will add an extra delay on concurrent tune on linked tuners for sure)

Edited by athoik, 14 October 2018 - 15:17.

[Huevos]

 

If all of them fail, apparently we have an issue where enigma doesn't wait for each tuner to be tuned before going to the next. I can image in a simple setup, where all tuners are independent that is the best way to go, minimal delay. But if some of the tuners are looped through (regular, FBC and/or SCR) it may be better to wait for a tuner to have LOCK before continueing to the next. I am not even sure enigma recognises that more than one tune request is done at the same time. If not, we may even have to start there.

I have already post a patch (few pages ago) that recognizes that a (linked) tuner is already in a tuning process.

Also we added a random SEC sleep.

Anyway the logic is here:

If the delay is -1 (default init value) and tuner differs than the current tuner, and state of the other tuner is tuning and the current sequence on the current tuner is on begin..

Then do something smart and set delay to 0 in order not to re-enter.

The sec_fe != this && sec_fe->m_state == stateTuning && m_sec_sequence is the minimum check required.

@@ -1583,6 +1583,14 @@ int eDVBFrontend::tuneLoopInt()  // called by m_tuneTimer
                                prev->inc_use();
                        }
                }
+               else if (delay == -1 && sec_fe != this && sec_fe->m_state == stateTuning &&
+                       m_sec_sequence && m_sec_sequence.begin() == m_sec_sequence.current())
+               {
............................. do something smart here?
+                       delay = 0;
+               }
        }

        if ( m_sec_sequence && m_sec_sequence.current() != m_sec_sequence.end()unicable_rand)

This worked for me with random sleep but not for Abu. Both of us using the Solo 4K.

[Huevos]

Here is what I see.

https://github.com/O...c.cpp#L709-L846

 

Here is a big string of commands that are supposed to be run sequentially with pauses between the commands. That works fine with a single tune.

 

But what happens with a multiple tune? All the pauses run. Then all the command words are sent without any pauses.

 

So somehow only one instance of that Unicable clause should be run at once, so all the commands are pushed to the queue in the correct order, and then the commands for the next tuner are all pushed to the queue, etc, etc.

 

Currently you end up with this (if you start 3 recordings simultaneously). If those where sequential and not parallel I think the trouble would be gone.

<  3744.338> [eDVBFrontend] set static current limiting
<  3744.338> [eDVBFrontend] set static current limiting
<  3744.338> [eDVBFrontend] invalidate current switch params
<  3744.339> [eDVBFrontend] invalidate current switch params
<  3744.339> [eDVBFrontend] invalidate current switch params
<  3744.339> [eDVBFrontend] set sequence pos 3
<  3744.339> [eDVBFrontend] set sequence pos 3
<  3744.339> [eDVBFrontend] set sequence pos 3
<  3744.339> [eDVBFrontend] setVoltage 2
<  3744.340> [eDVBFrontend] setVoltage 2
<  3744.340> [eDVBFrontend] setVoltage 2
<  3744.341> [eDVBFrontend] setTone 0
<  3744.342> [eDVBFrontend] setTone 0
<  3744.342> [eDVBFrontend] setTone 0
<  3744.343> [eDVBFrontend] sleep 75ms
<  3744.343> [eDVBFrontend] sleep 75ms
<  3744.343> [eDVBFrontend] sleep 75ms
<  3744.474> [eDVBFrontend] sendDiseqc: 7003e500(?)
<  3744.530> [eDVBFrontend] sendDiseqc: 700cdf00(?)
<  3744.586> [eDVBFrontend] sendDiseqc: 70145a02(?)
<  3744.586> [eDVBFrontend] sleep 1000ms
<  3744.586> [eDVBFrontend] sleep 1000ms
<  3744.587> [eDVBFrontend] sleep 1000ms

Edited by Huevos, 14 October 2018 - 16:09.

[littlesat]

Are the sequences pulled with some kind of type order?

[Huevos]

I don't know. But what I am saying is the complete sequence should be completed before the next sequence starts. But I have no idea how to do that in practice. If we could somehow force that we would not need extra delays.

[athoik]

Here is what I see.
https://github.com/O...c.cpp#L709-L846

Here is a big string of commands that are supposed to be run sequentially with pauses between the commands. That works fine with a single tune.

But what happens with a multiple tune? All the pauses run. Then all the command words are sent without any pauses.

So somehow only one instance of that Unicable clause should be run at once, so all the commands are pushed to the queue in the correct order, and then the commands for the next tuner are all pushed to the queue, etc, etc.

Currently you end up with this (if you start 3 recordings simultaneously). If those where sequential and not parallel I think the trouble would be gone.

<  3744.338> [eDVBFrontend] set static current limiting
<  3744.338> [eDVBFrontend] set static current limiting
<  3744.338> [eDVBFrontend] invalidate current switch params
<  3744.339> [eDVBFrontend] invalidate current switch params
<  3744.339> [eDVBFrontend] invalidate current switch params
<  3744.339> [eDVBFrontend] set sequence pos 3
<  3744.339> [eDVBFrontend] set sequence pos 3
<  3744.339> [eDVBFrontend] set sequence pos 3
<  3744.339> [eDVBFrontend] setVoltage 2
<  3744.340> [eDVBFrontend] setVoltage 2
<  3744.340> [eDVBFrontend] setVoltage 2
<  3744.341> [eDVBFrontend] setTone 0
<  3744.342> [eDVBFrontend] setTone 0
<  3744.342> [eDVBFrontend] setTone 0
<  3744.343> [eDVBFrontend] sleep 75ms
<  3744.343> [eDVBFrontend] sleep 75ms
<  3744.343> [eDVBFrontend] sleep 75ms
<  3744.474> [eDVBFrontend] sendDiseqc: 7003e500(?)
<  3744.530> [eDVBFrontend] sendDiseqc: 700cdf00(?)
<  3744.586> [eDVBFrontend] sendDiseqc: 70145a02(?)
<  3744.586> [eDVBFrontend] sleep 1000ms
<  3744.586> [eDVBFrontend] sleep 1000ms
<  3744.587> [eDVBFrontend] sleep 1000ms

Mayb we need to add debug like this order to know the tuner?

"[eDVBFrontend %d] ...", m_dvbid, ...);

[Huevos]

Tell me where/how and I can add and test.

[Huevos]

In frontend.cpp, right?

[athoik]

Yes, correct.

Also the eDebug in sec.cpp should be changed with eDebugNoSimulate in order not to get "tuning Jess" when in simulation?

[athoik]

Here is another approach, delay randomly the concurrent tune on linked tuners only when tuner is in initial phase of tuning, and we are not simulating.

m_state == stateTuning
m_tuning == 0
 

diff --git a/lib/dvb/frontend.cpp b/lib/dvb/frontend.cpp
index 30918be..af2f73c 100644
--- a/lib/dvb/frontend.cpp
+++ b/lib/dvb/frontend.cpp
@@ -1583,6 +1583,14 @@ int eDVBFrontend::tuneLoopInt()  // called by m_tuneTimer
                                prev->inc_use();
                        }
                }
+               else if (!m_simulate && sec_fe != this && sec_fe->m_state == stateTuning && !sec_fe->m_tuning &&
+                       m_sec_sequence && m_sec_sequence.begin() == m_sec_sequence.current())
+               {
+                       delay = 100 + rand() % 900; // random value between 100 and 999 ms
+                       eDebug("[eDVBFrontend %d] linked on %d is also initiating tuning, delaying %d ms", m_dvbid, sec_fe->getDVBID(), delay);
+                       m_tuneTimer->start(delay, true);
+                       return delay;
+               }
        }

        if ( m_sec_sequence && m_sec_sequence.current() != m_sec_sequence.end() )

Edited by athoik, 14 October 2018 - 19:28.