342 replies to this topic

[WanWizard]

Only way to cure this properly is not send any parallel commands. Commands need to go in a queue.

 

Yes, that was what I wrote about 14 pages ago.

[Huevos]

 

Only way to cure this properly is not send any parallel commands. Commands need to go in a queue.

 

Yes, that was what I wrote about 14 pages ago.

Yes but they need to get flushed to the queue in one block and dealt with as a block of commands. Then deal with the next block.

[WanWizard]

I know. But that is far beyond my capabilities, I've just spend three days in C++ to fix some Samba issues, which was the first C for me in probably 30 years (which is why it took 3 days) ...

[Huevos]

TBH, Athoik's tuning delay patch works so far for me but I haven't had time to check external linking.

 

And computer failed today so can't do much more without a replacement.

Edited by Huevos, 20 October 2018 - 00:57.

[Erik Slagter]

I’m afraid the only way to solve this issue is arrange that per dvb-s physical input we only can give one diseqc command... and not per tuner...

If you say that you don't understand the issue.

[Erik Slagter]

It still won't solve it. I.e. 2 cable leave the STB. They join up externally at a unicable splitter, then the diseqc commands go over a single cable to the LNB/switch.

 

Only way to cure this properly is not send any parallel commands. Commands need to go in a queue. Send the commands for one tuner. Don't send any more commands until either tuning on that tuner is confirmed, or tuning timeout has been reached. Then move on to the next set of commands in the queue.

 

Also you need to decide how to handle a failure to tune, so that failure to tune on one tuner does not block tuning another tuner.

 

I can't see an easy fix. Looks like it would need a big code rewrite.

I think we totally agree here (and indeed, Littlesat still hasn't got the whole picture here).

 

Also it's really wrong to mention any of Unicable, JESS, SCR or FBC because their use only makes the issue show more often, but they're not the cause nor related to the issue.

 

As said, I am willing to have a thorough look and try to come up with a fix, but that will be after the sumo release, one thing at a time. My first task will be to find out what causes the interleaved (of multiple tuners) sending of the SEC commands, even though they're completely pre-constructed. It suggests all commands of the tuner's queue are sent in one go, without being interrupted by other tuners' commands. Maybe it's just a bug and the design is actually ok (although in enigma that would be a surprise...). And otherwise I think it will turn out that all looped through tuners need to be grouped together (which, btw, already is implemented, all looped through tuners have pointers to each other in the frontend class) and only one tuner of such a group can do a tune action, at any given time. And yes, that has consequences, especially for transponders that won't tune at all or transponders that tend to loose lock after some time or intermittently.

[Erik Slagter]

 

 

Only way to cure this properly is not send any parallel commands. Commands need to go in a queue.

Yes, that was what I wrote about 14 pages ago.

Yes but they need to get flushed to the queue in one block and dealt with as a block of commands. Then deal with the next block.

I think it's better to completely separate tuning actions altogether. Some tuning actions may need more than one command to complete and some devices may need to have them in one sequence.

 

BTW I was mislead by the use of SEC queues in enigma, which apparently don't work as suggested.

Edited by Erik Slagter, 20 October 2018 - 08:54.

[Erik Slagter]

TBH, Athoik's tuning delay patch works so far for me but I haven't had time to check external linking.

And computer failed today so can't do much more without a replacement.

It's fine to use such a workaround in your own environment, but it won't make it into the OpenPLi enigma. As it doesn't solve the problem.

[littlesat]

If you say that you don't understand the issue.

 

Then I indeed don't understand the issue.... So explain..... Anyhow somehow the 'commands' over the 'line' get corrupted.....

Edited by littlesat, 20 October 2018 - 13:52.

[Huevos]

 

If you say that you don't understand the issue.

 

Then I indeed don't understand the issue.... So explain..... Anyhow somehow the 'commands' over the 'line' get corrupted.....

 

All the diseqc commands need to arrive at the LNB/switch, but they need sending with the correct timing and pauses between them.

Edited by Huevos, 20 October 2018 - 15:01.

[Erik Slagter]

I would describe it differently. It's not the timing or delays. It's the sequence. The problem is that SEC commands from different tuners apparently get interleaved. If you have two tuners with two cables and two switches, that is no problem. As soon as a cable is shared, be it looping through externally, internally or FBC, you can't have that, it will confuse the switches / LNB's (which apparently is what's happening).

 

So the solution is to prevent multiple tuners on the same cable from tuning at the same time.

 

And once again, the issue is not specific to either FBC or SCR.

[littlesat]

So in short... eg you need per tuner 3 commands for tune with one tuner a you send A1, A2, A3... when you have two tuners you should expect a1a2a3b1b2b3 but you get a1b1a2b2a3b3???

[WanWizard]

In short, you need a queue per cable, and not a queue per tuner.

[Huevos]

So in short... eg you need per tuner 3 commands for tune with one tuner a you send A1, A2, A3... when you have two tuners you should expect a1a2a3b1b2b3 but you get a1b1a2b2a3b3???

Yes but because it is a race condition you might get a1b1b2a2a3b3.

 

What you want is...

• voltage 13,
• pause,
• voltage 18,
• tone off,
• pause,
• diseqc control word,
• pause,
• voltage 13.

 

If you mix that up with another set of commands the LNB can't understand a thing.

[littlesat]

So you have one queu and multiple tuners do write in that one queue....? Or something like that??? If so I understand it... Than it needs to be arranged that only one tuner can add a new command in that one queue...(first of course check if this is indeed the reason... and the next tuner can only add something to this queue when a tune is ok or fails...

Edited by littlesat, 20 October 2018 - 21:57.

[littlesat]

Probably relevant.... https://forums.openp...en/#entry951530

[Huevos]

So you have one queu and multiple tuners do write in that one queue....? Or something like that??? If so I understand it... Than it needs to be arranged that only one tuner can add a new command in that one queue...(first of course check if this is indeed the reason... and the next tuner can only add something to this queue when a tune is ok or fails...

Yes, but, and I my be wrong about this, the cause is that more than one instance is being run at once.

[Huevos]

Probably relevant.... https://forums.openp...en/#entry951530

That looks like a softcam issue.

[betacentauri]

If that’s the same problem I have, it’s no softcam issue. It happens also on fta channels.

[littlesat]

I agree that that other thread is not a softcam issue.. A softcam issue does not give a message tuning failed...