Jump to content


Photo

Unicable / simultaneous recordings


  • Please log in to reply
342 replies to this topic

Re: Unicable / simultaneous recordings #241 littlesat

  • PLi® Core member
  • 57,456 posts

+708
Excellent

Posted 14 October 2018 - 07:04

This means the cullpit isn’t found yet?!

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #242 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 14 October 2018 - 10:13

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #243 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 14 October 2018 - 10:17

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #244 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 10:25

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() )

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unicable / simultaneous recordings #245 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 14 October 2018 - 10:31

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #246 littlesat

  • PLi® Core member
  • 57,456 posts

+708
Excellent

Posted 14 October 2018 - 10:44

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

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #247 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 10:46

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.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unicable / simultaneous recordings #248 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 14 October 2018 - 12:33

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #249 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 13:13

In case at least 2 linked tuner are concurrently tuning, we can detect it and delay sec? all except one.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unicable / simultaneous recordings #250 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 14 October 2018 - 15:05

If that can be done 

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

I have no objections.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #251 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 15:13

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unicable / simultaneous recordings #252 Huevos

  • PLi® Contributor
  • 4,766 posts

+167
Excellent

Posted 14 October 2018 - 15:39

 

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.



Re: Unicable / simultaneous recordings #253 Huevos

  • PLi® Contributor
  • 4,766 posts

+167
Excellent

Posted 14 October 2018 - 16:04

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.


Re: Unicable / simultaneous recordings #254 littlesat

  • PLi® Core member
  • 57,456 posts

+708
Excellent

Posted 14 October 2018 - 16:09

Are the sequences pulled with some kind of type order?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #255 Huevos

  • PLi® Contributor
  • 4,766 posts

+167
Excellent

Posted 14 October 2018 - 16:20

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.



Re: Unicable / simultaneous recordings #256 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 16:21


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, ...);
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unicable / simultaneous recordings #257 Huevos

  • PLi® Contributor
  • 4,766 posts

+167
Excellent

Posted 14 October 2018 - 16:35

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



Re: Unicable / simultaneous recordings #258 Huevos

  • PLi® Contributor
  • 4,766 posts

+167
Excellent

Posted 14 October 2018 - 16:41

In frontend.cpp, right?



Re: Unicable / simultaneous recordings #259 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 16:43

Yes, correct.

Also the eDebug in sec.cpp should be changed with eDebugNoSimulate in order not to get "tuning Jess" when in simulation?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unicable / simultaneous recordings #260 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 October 2018 - 19:18

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916


5 user(s) are reading this topic

0 members, 5 guests, 0 anonymous users