342 replies to this topic

[Huevos]

And obviously if no resends are needed there is going to be no sluggishness.

[Erik Slagter]

The problem is that none of the SCR code deals with retransmits (nor delays or timeslots) nor has the code the tools to implement those. The retransmits and the delays are handled in a different part of enigma!

 

Crude delays using sleep() etc. won't work, because they won't be remembered by enigma when doing a retry. And they will slow down regular tuning. That's why I keep pestering about using DiSEqC delays, that's the way enigma works.

Edited by Erik Slagter, 8 October 2018 - 19:25.

[littlesat]

+1, the original adanin or so did made was attickwere.... it never followed the specs... and when you look at atv’s code it has a lot of programmable work a rounds that also can never work for 100%

Edited by littlesat, 8 October 2018 - 20:28.

[Huevos]

Personally I think instead of concentrating on retries we should be asking why it doesn't tune on the first attempt.

[littlesat]

I’m afraid that almost should be a colision. Two control words given at once... the one sec delay work-a-round almost proves it....

[Huevos]

Is that piece of code single thread or multi thread?

[littlesat]

Good question....

[Erik Slagter]

Personally I think instead of concentrating on retries we should be asking why it doesn't tune on the first attempt.

I share that opinion. Although the root cause may very well be that two tuners command the switch/LNB too close to each other (according to certain switches/LNB's) and then a delay will help.

[Erik Slagter]

I’m afraid that almost should be a colision. Two control words given at once... the one sec delay work-a-round almost proves it....

I think someone needs to read quite a bit of posts again.

[Erik Slagter]

Is that piece of code single thread or multi thread?

It may be multithreaded, but I don't think that is relevant here, why do you want to know?

[Huevos]

Well Athoik suggested a race condition. So what I am really asking is, are 2 commands sent at the same time, or is it that they are sent so close together that the LNB can't understand them?

 

And this based on the fact that we know for sure the LNB failed to tune based on the data from the analyser.

Edited by Huevos, 9 October 2018 - 18:55.

[littlesat]

Why is multithreaded not relevant as it might clarify everything... in case each tuner has it’s own class....

[Erik Slagter]

Well Athoik suggested a race condition. So what I am really asking is, are 2 commands sent at the same time, or is it that they are sent so close together that the LNB can't understand them?

 

And this based on the fact that we know for sure the LNB failed to tune based on the data from the analyser.

As I said earlier, this is impossible for two reasons:

 

1) the SEC commands are not sent by the SCR code, they only prepare a queue of commands and hand them over to enigma, which send them at some point sequentially to the driver

2) I can't believe the driver will allow opening the channel twice and sending more than one commands at a time

 

So, I don't think the issue is that commands are sent interleaved, I said that before. If that were the case, I would see the issue as well, and I don't (will check that friday). The issue is most probably two commands for different LNB's too close after each other. And that can be solved by tweaking the "generic" DiSEqC delays.

[twol]

Well Athoik suggested a race condition. So what I am really asking is, are 2 commands sent at the same time, or is it that they are sent so close together that the LNB can't understand them?
 
And this based on the fact that we know for sure the LNB failed to tune based on the data from the analyser.

As I said earlier, this is impossible for two reasons:
 
1) the SEC commands are not sent by the SCR code, they only prepare a queue of commands and hand them over to enigma, which send them at some point sequentially to the driver
2) I can't believe the driver will allow opening the channel twice and sending more than one commands at a time
 
So, I don't think the issue is that commands are sent interleaved, I said that before. If that were the case, I would see the issue as well, and I don't (will check that friday). The issue is most probably two commands for different LNB's too close after each other. And that can be solved by tweaking the "generic" DiSEqC delays.

I think almost every example so far has been to either a single Unicable LNB on 28.2E or as in my case through a specific Unicable switch to a single LNB (in my case Quatrro LNB)

[littlesat]

The a simple 1 sec delay between the commands should solve it...

[athoik]

Assuming that commands are send in parallel, adding a constant in commands will not change something because parallel+constant will follow the same execution path (all sec will simply delayed by the same constant value).

The 1 sec delay in timer forces sec command to run in different timeslots, so not in parallel.

But don't focus on parallel, focus on retries, retries are taking too long without an aparent reason!

[littlesat]

First we need to discover if they are send in parallel or too close after eachother...

[Erik Slagter]

The a simple 1 sec delay between the commands should solve it...

Sigh...

[Erik Slagter]

As promised I performed a test myself. Equipment: VU+ Ultimo4k, with two JESS switches connected, I am using one here, connected to input "A". I am recording three channels from 23.5E, NPO 1, NPO 2 and RTL 4, they're all on different transponders and they're all encrypted. I set the starting time to be exactly the same.

 

Results:

 - my log is flooded with huge amounts of "JESS tuning" requests, over and over again for the transponders that the three services are on. BUT this is during startup of enigma en during the "preparing" stage. Most fo the time user band 0 is requested, very rarely ub 1, but never 2. Which is strange in itself.

- then at the time when the real recording starts, all user band requests are sent exactly once, they get tuned, get LOCK and start to record, everything ok, no issues.

 

My conclusions here:

 

- there is something really strange going on in the "prepare" stage. Maybe it has to do with the "simulate" mode in enigma which is very weird in itself. Maybe I should check if the JESS code checks this flag/parameter (afaik, it does).

- there is nothing fundamentally wrong, but there may be a timing issue, where the ub requests get sent too quick after another for some equipment.

 

The latter could be solved by tweaking the SEC delays in enigma and if that doesn't help, the JESS code should add explicit "delay" commands to the SEC queue (and that's how it works, never use a sleep() etc. here).

Edited by Erik Slagter, 12 October 2018 - 13:24.

[Huevos]

Hi Erik, yes

 

1) I think the simulate stuff runs everytime enigma2 starts and is pretty noisy in the log.

2) Are you running the latest PLi develop build (because that has the fix in RecordTimer.py so the fault will not show). With the RecordTimer.py changes the STB tunes on the first attempt.

3) If the answer to 2 is you tested with RecordTimer.py changes removed, the fault must be control words sent too close together and the LNB can't divide the string so thinks the command is junk.

Edited by Huevos, 12 October 2018 - 15:07.