342 replies to this topic

[Erik Slagter]

FYI: https://code.mythtv....icket/12092#no1
 

This is PoC patch for potential issue related to fact that UniCable bus is shared type bus. For reliable operation, shared bus requires access coordination or collision detection. Patch implements access coordination. From functional point of view patch should avoid situations where 2 or more recorders/EIT scanners are issuing tuning command in EXACTLY the same time. Even as tuner's Disecq HW will serialize commands - Unicable protocol requires defined guard silence between tuning command sets. For reference: in my system (4 unicable tuners, 350-500 recordings per week) I catch 1 such case during 5 months period.

As you can see, other DVB projects also had same issue.

So the 1sec delay was not a bad idea at all, but still a temporary solution.

When tuners are using unicable/Jess, we can detect it from linked frontends, right?

 

If you read the complete document, you can see when they talk of "collision detection" they mean the use of multiple tuners (as in: multiple set-top-boxes) on a single cable. A single STB has a single enigma2 instance and a single driver instance and therefore there are no collisions.

[Erik Slagter]

Thanks for the info.

 

We have tested with a couple of switches too and results were the same as with the LNBs. Without the patch in RecordTimer.py the recordings were also zero length.

 

Test machine:

Gigablue Quad 4K.

 

Switches:

DUR-Line DCR 5-1-8-L4

Spaun SUS 5581/33 NFA

Maybe it's a bug in the GB's drivers?

[Erik Slagter]

So as far as I read it the delay between retries should be random so there is no chance of collision happening more than once.

Enigma already does that, as long as no LOCK is achieved, it keeps tuning. Every tunning attempt results into a SCR command being sent. There is no need (or preference) to repeat this functionality at the physical layer. You can see that it works by power cycling a multiswitch. The tuner looses lock and then re-gains it after a few seconds, because enigma sends the commands again.

[Erik Slagter]

 

Agreed, up to 1s but what is the minimum? 250ms, 75ms ?

I think a reasonable minimum for "guard silence" between commands would be 100ms.

I think that's our goal, like I said before. There is already a set of SEC delays and one of them should be the inter-command-delay. Set that to any value you want and you've achieved your goal. I don't think this needs any code change at all, rather not, really.

[Erik Slagter]

Looks good to me.
What others are saying for the C++ patch?
@pieterg, @erik, @betacentauri, @littlesat review final patch (with rand delay 100-999 ms).

I would only agree if it:

 

- does not introduce regressions (having additional delays in an environment where it's not required, is unacceptable)

- does not duplicate functionality (enigma already retries tuning when not successful)

 

So imho the only acceptable implementation is to add a SEC delay parameter "max inter command delay" and then use the already existing "inter command delay" as a minimum, and vary the actual used value between min and max randomly. Or better, use an exponentional backoff algorithm like may broadcast mediums use, where the first retry is immediate and after that an ever increasing delay is inserted between attempts. It has been proved since many years that's the best approach.

[Huevos]

 

Thanks for the info.

 

We have tested with a couple of switches too and results were the same as with the LNBs. Without the patch in RecordTimer.py the recordings were also zero length.

 

Test machine:

Gigablue Quad 4K.

 

Switches:

DUR-Line DCR 5-1-8-L4

Spaun SUS 5581/33 NFA

Maybe it's a bug in the GB's drivers?

 

The bug is not brand specific. It also shows on Ultimo 4K and Solo 4K.

[Huevos]

For Abu the test failed several times. This is the code he tested: https://github.com/H...0cc1b776a02f308

 

For me this worked fine.

 

Both of us using Solo 4K in this test. Abu also tested on GB UE 4K. Also failed. Only difference in the current tests is I am using an Inverto LNB and he is using a GT-Sat.

[Erik Slagter]

Yes, I already read that after I posted this. So it's not STB brand specific. Apparently it IS LNB/switch specific. And that's why I don't want a "generic" workaround, for me (and probably some others too) it now works and I'd very much like to keep it that way. A workaround is never allowed when it breaks the stuff that already worked.

[twol]

I don‘t think anything has been broken, that wasn‘t already broken..... but some additional things now work...... and the code improvements should benefit everybody.

[Abu Baniaz]

Unicable LNBs are expensive. I have tried an Inverto as well as a GT-Sat LNB. Both have have the issue when using FBC tuners.

So far only Vu+ and GigaBlue have FBC tuners. They both fail for me.

I'd be grateful for any further suggestions/changes that can help make recordings reliable.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[Huevos]

Yes, I already read that after I posted this. So it's not STB brand specific. Apparently it IS LNB/switch specific. And that's why I don't want a "generic" workaround, for me (and probably some others too) it now works and I'd very much like to keep it that way. A workaround is never allowed when it breaks the stuff that already worked.

Just because some switches aren't vulnerable to this bug doesn't mean the ones that are, are faulty. Too many devices affected and the one thing they have in common is running enigma2.

[Dimitrij]

So far only Vu+ and GigaBlue have FBC tuners.

Lunix3-4K  two FBC tuners same as in Ultimo 4K

[Pr2]

For me this should be escalated to the driver manufacturer and they should fix it at the driver level (too). Because from what I read here it is supposed to work as ethernet (CSMA-CD) and this should be done at the driver level, since higher you cannot detect collisions.

[littlesat]

As far I know it is a one way communication without feedback from the lnb. The only feedback is that it can be tuned or not. Will the ‘diseqc’ type commands from unicable/jess be repeated at a retune?

[Huevos]

As far I know it is a one way communication without feedback from the lnb. The only feedback is that it can be tuned or not. Will the ‘diseqc’ type commands from unicable/jess be repeated at a retune?

Yes commands are repeated. If receiver loses lock, for example the control word is sent again.

 

If you remove the PSU from the switch tune fails. Reinsert the PSU and the picture reappears. That proves the control word is resent.

 

@PR2, this is not just FBC. Rob has confirmed twice in this thread that other tuner types are affected.

[Erik Slagter]

 

Yes, I already read that after I posted this. So it's not STB brand specific. Apparently it IS LNB/switch specific. And that's why I don't want a "generic" workaround, for me (and probably some others too) it now works and I'd very much like to keep it that way. A workaround is never allowed when it breaks the stuff that already worked.

Just because some switches aren't vulnerable to this bug doesn't mean the ones that are, are faulty. Too many devices affected and the one thing they have in common is running enigma2.

My rationale is: the standard doesn't require delays and some of the SCR switches prove this point. I am not against making non-standard adhering stuff work, but never at the expense of devices that already work without the workaround. So extra delays: fine, but only when explicitly requested or, if possible, auto-detected from the connected devices.

 

I still think the standard SEC delays should be tried first.

[Erik Slagter]

 

So far only Vu+ and GigaBlue have FBC tuners.

Lunix3-4K  two FBC tuners same as in Ultimo 4K

Same hardware, but not same drivers, of course.

 

The Ultimo4k has 1x FBC + 1x FBC + 1x standard.

Lunix3-4k has 1x FBC + 1x standard.

 

You've been fooled by the "dual" mentioning, as many people do.

[Erik Slagter]

For me this should be escalated to the driver manufacturer and they should fix it at the driver level (too). Because from what I read here it is supposed to work as ethernet (CSMA-CD) and this should be done at the driver level, since higher you cannot detect collisions.

No it's not (completely) supposed to work like this. Ethernet has always a at least one layer above it for error detection and correction. The collision detection is only there to prevent a situation where packets get sent over and over again unnecessarily.

 

DiSEqC has, for each version, a counterpart that enables two-way communication (e.g. 2.0 from 1.0, 2.1 from 1.1 etc.). Most devices do actually implement the two-way communication, but enigma2 doesn't use it at all. I am afraid it's a vicious circle; DMM never bothered to implement it's functionality in enigma2, so other vendors didn't bother to add this functionality (probably...) in their drivers. May be the hardware isn't even capable.

 

Anyway, SCR is not the same as DiSeqC, it only uses most of it's signalling. The good news is that at least JESS (but probably Unicable as well) support inherently two-way communication, but in a different way than DiSEqC. AFAIK there is a command to query the currently assigned user bands, so I guess that's what one should use to check communications. But here also counts the same as for DiSEqC, probably the drivers or even hardware don't support actually reading DiSEqC. Even if only vendor doesn't support it, there would be a problem.

 

So enigma defaults to the "second best practice", where one sends the command, checks for LOCK and if it doesn't come, try again a few times until time out. It's not beautiful but it is very robust. As said the retransmission of the SEC commands take place a higher level than the SCR handling, so we shouldn't be modifiying code there (SCR). If not already there, I think we should modify the retry pattern into an exponentional backoff one, as described earlier. We could add to the pattern a random fragment, which would make the pattern even more efficient.

[Erik Slagter]

 

As far I know it is a one way communication without feedback from the lnb. The only feedback is that it can be tuned or not. Will the ‘diseqc’ type commands from unicable/jess be repeated at a retune?

Yes commands are repeated. If receiver loses lock, for example the control word is sent again.

 

If you remove the PSU from the switch tune fails. Reinsert the PSU and the picture reappears. That proves the control word is resent.

Just like I said a few posts back The communication is indeed via the LOCK status.

 

That's why the SCR and SEC code don't send their commands directly, but build a queue, which enigma attaches to the currently service (and then sends itself, whenever tuning is required). And that's why delays in the SCR/SEC code won't work.

Edited by Erik Slagter, 5 October 2018 - 08:42.

[Dimitrij]

Lunix3-4k has 2x FBC + 1x DVB-S or multi DVB-C/DVB-T2 .

Edited by Dimitrij, 5 October 2018 - 08:58.