342 replies to this topic

[littlesat]

As far I can see each frontend instance has it own 'diseqc' instance.... while actually each 'cable' should have one diseqc instance.... Tell me when I'm not right here....

 

https://github.com/O...vb/frontend.cpp

[Erik Slagter]

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???

 

 

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

 

Both correct.

[Erik Slagter]

As far I can see each frontend instance has it own 'diseqc' instance.... while actually each 'cable' should have one diseqc instance.... Tell me when I'm not right here....

 

https://github.com/O...vb/frontend.cpp

 

Yes.

 

Without looking at the code, the current code will ensure the array of SEC commands will be remembered per frontend so it can be sent again if necessary. But it will not ensure two linked frontends will send them at the same time, on the same cable.

 

So, again, my proposed solution is to have all linked frontends ("tuners") to be required to take a lock at the cable before sending any SEC sequence. All frontends that are on a single cable are always already linked in software as well, using a linked list which you can travel to find all connected tuners.

 

The only thing is:

 

- how to ensure the UI responsiveness doesn't suffer from the implied waits for the lock to be released (maybe this is a no-brainer because this code is not executed by the UI thread, who knows)

- how to ensure the whole tuning subsystem doesn't get completely locked up caused by a tuner that doesn't want to tune / get a lock, for whatever reason

 

Maybe something like a lock that times out and when it times out it has to be acquired again, where all competing tuners have an equal chance to acquire the lock.

Edited by Erik Slagter, 21 October 2018 - 10:45.

[littlesat]

sounds like I understood the issue from the beginning...

[Huevos]

 

As far I can see each frontend instance has it own 'diseqc' instance.... while actually each 'cable' should have one diseqc instance.... Tell me when I'm not right here....

 

https://github.com/O...vb/frontend.cpp

 

Yes.

 

Without looking at the code, the current code will ensure the array of SEC commands will be remembered per frontend so it can be sent again if necessary. But it will not ensure two linked frontends will send them at the same time, on the same cable.

 

So, again, my proposed solution is to have all linked frontends ("tuners") to be required to take a lock at the cable before sending any SEC sequence. All frontends that are on a single cable are always already linked in software as well, using a linked list which you can travel to find all connected tuners.

 

The only thing is:

 

- how to ensure the UI responsiveness doesn't suffer from the implied waits for the lock to be released (maybe this is a no-brainer because this code is not executed by the UI thread, who knows)

- how to ensure the whole tuning subsystem doesn't get completely locked up caused by a tuner that doesn't want to tune / get a lock, for whatever reason

 

Maybe something like a lock that times out and when it times out it has to be acquired again, where all competing tuners have an equal chance to acquire the lock.

 

How is enigma supposed to know about external links? e.g 3 DVB-S2 tuners connected to a Unicable splitter?

 

For linked tuners Athoik's tuning lock patch works perfectly (for me).

[Huevos]

Or, e.g. Vu+ Ultimo 4K, one cable to tuner A, second cable to tuner I, both from Unicable splitter. How is enigma supposed to know they are connected to the same Unicable LNB/switch?

Edited by Huevos, 21 October 2018 - 22:49.

[anudanan]

I think a nee solution for multiple tuners on one cable would also work for tuners with separate cables. Why is the knowledge neccessaryfor enigma which tuners are on the same cable?

[anudanan]

nee = new

Or do you trink the tuning performance is bad then for seperate cables?

[littlesat]

Knowing about external links is complicated. What about having just one thread that can write it’s commands to just one diseqc/jess/unicable sequence thing in the first place... I guess nobody notice the possible delays... (just thinking easy and maybe later arrange multiple ‘cables’ as maybe the ui should help here...by forwarding a cable number to e2... but mayby this is not required af all when just one diseqc instance already does the job)

Edited by littlesat, 22 October 2018 - 08:00.

[Huevos]

If multiple simultaneous tuning events are not permitted there is no need to know about cables or add logic for them.

 

Anyway, what good reason is there for multiple simultaneous tuning events? Those will only ever happen at the start of multiple simultaneous recordings so removing them should not affect zapping.

 

If you suggest a patch I would be happy to test.

[Erik Slagter]

sounds like I understood the issue from the beginning...

Apparently not, as you keep talking of delays and timings. It's not a timing issue.

[Erik Slagter]

How is enigma supposed to know about external links? e.g 3 DVB-S2 tuners connected to a Unicable splitter?
 
For linked tuners Athoik's tuning lock patch works perfectly (for me).

Most use cases can be recognised, but that case, indeed not. I guess we should have two options in the tuner set up screen: internally looped through (the usual way) or externally looped through. In that case enigma won't try to setup the link, but it can recognise what services can be tuned to or not, in itself already an improvement to the current situation. And the other benefit will be the SEC access regulation.

 

And what does it do? AFAIK it only keeps retrying until success. Sounds like a workaround to me.

[Erik Slagter]

I think a nee solution for multiple tuners on one cable would also work for tuners with separate cables. Why is the knowledge neccessaryfor enigma which tuners are on the same cable?

Read the topic and you will know.

[Erik Slagter]

Knowing about external links is complicated. What about having just one thread that can write it’s commands to just one diseqc/jess/unicable sequence thing in the first place... I guess nobody notice the possible delays... (just thinking easy and maybe later arrange multiple ‘cables’ as maybe the ui should help here...by forwarding a cable number to e2... but mayby this is not required af all when just one diseqc instance already does the job)

 

Translated into my words: instead of taking a lock on a group of tuners that share one cable, make just one group, of all tuners, and use only one lock. That would make stuff a bit simpeler, but we need to think about the consequences:

- is it acceptable that no single tuner can do tuning whenever one other tuner is tuning

- can't this create a deadlock

 

What consequences will this have if I am watching a program, recording another, I'm running the signal finder and the signal on the transponder for #1 or #2 has a momentary dip. Won't this delay the re-tuning unacceptably long? For istance.

[anudanan]

 

Translated into my words: instead of taking a lock on a group of tuners that share one cable, make just one group, of all tuners, and use only one lock. That would make stuff a bit simpeler, but we need to think about the consequences:

- is it acceptable that no single tuner can do tuning whenever one other tuner is tuning

- can't this create a deadlock

 

What consequences will this have if I am watching a program, recording another, I'm running the signal finder and the signal on the transponder for #1 or #2 has a momentary dip. Won't this delay the re-tuning unacceptably long? For istance.

 

That answer from you is the right answer to my last question about the knowledge of cables for enigma in post #327. My idea was also to have one lock for all tuner without a knowledge of the cable situation. That makes it easier, but your written consequences are correct.

Edited by anudanan, 22 October 2018 - 18:01.

[Huevos]

 

Knowing about external links is complicated. What about having just one thread that can write it’s commands to just one diseqc/jess/unicable sequence thing in the first place... I guess nobody notice the possible delays... (just thinking easy and maybe later arrange multiple ‘cables’ as maybe the ui should help here...by forwarding a cable number to e2... but mayby this is not required af all when just one diseqc instance already does the job)

 

Translated into my words: instead of taking a lock on a group of tuners that share one cable, make just one group, of all tuners, and use only one lock. That would make stuff a bit simpeler, but we need to think about the consequences:

- is it acceptable that no single tuner can do tuning whenever one other tuner is tuning

- can't this create a deadlock

 

What consequences will this have if I am watching a program, recording another, I'm running the signal finder and the signal on the transponder for #1 or #2 has a momentary dip. Won't this delay the re-tuning unacceptably long? For istance.

 

We shouldn't keep retrying on the same tuner. On failure we should move on to the next tuner in the queue. Only return to the first tuner if all the tuners waiting have had a retune attempt.

[littlesat]

I never talked about delays and timings....????

Edited by littlesat, 22 October 2018 - 22:04.

[Rob van der Does]

I never talked about delays and timings....????

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

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

So at the end it tuned... after ‘tons’ of retunes...?
Wierd as I can imagine the lnb may need Some time to proces a control word... and when it needs time a ‘simple’ delay between them should solve it... do you have a scope to see the real ‘diseqc’ like controls?

Each hardware (lnb! Might require a different delay... couldn’t we consider to add this delay in unicable.xml when we know it for a specific lnb and add a delay in the manual config... than random and repeat stuff might not be required...

[littlesat]

You have too much time 09 oct is too long ago! In between
I know more...

Edited by littlesat, 23 October 2018 - 09:03.

[Huevos]

I am going to retest with Athoik patch one.

 

Going to test with the cable out so I can see if/when/how the queue rotates when not signal is available, and if it does cause a blockage as suggested by Erik.

Edited by Huevos, 23 October 2018 - 09:33.