342 replies to this topic

[Erik Slagter]

[RecordTimer] add 1 sec. for start timer if otner timers start same time

 

Are you sure this works... I also have issues with timers starting on the same time (without jess/unicable).... and this ‘work a round’ looks really simple

 

I don't think we should walk this path.

[Huevos]

 

[RecordTimer] add 1 sec. for start timer if otner timers start same time

 

Are you sure this works... I also have issues with timers starting on the same time (without jess/unicable).... and this ‘work a round’ looks really simple

 

I don't think we should walk this path.

 

I think everyone agrees with this sentiment, but until there is an alternative what can we do?

 

Also just delaying the SEC command is not going to work. If you delay the first command by one second, and then delay the second command by one second, both commands will still arrive at the LNB at the same time.

[WanWizard]

That can only be solved by processing them serially instead of in parallel. 

[Erik Slagter]

And that is exactly what happens! Look at the code if you guys don't believe me.

 

The Unicable and JESS code don't control the SEC mechanism of the tuner directly, they add commands to a queue which is then processed, one-by-one (!) by another piece of the enigma code.

 

It is impossible for commands to get interleaved with the commands of another instance.

 

Also, mostly there is only a single command, that's how Unicable and JESS are designed, all the information is inside a single command.

 

So that leaves us with a possible timing issue and timing issues are resolved with the SEC timeout configuration.

 

The fact that I've never seen this issue proves my point.

Edited by Erik Slagter, 29 September 2018 - 09:17.

[littlesat]

The issue is actually there is no feedback from the lnb or switch that says command accepted and adapted you’re free to give me a next command as it is a one way communication... so you somehow always need to pause and hope...
So the pause is somehow mandatory..
Maybe we should consider somehow to add the timeout in unicable.xml and for the manual configurable add the feature... and give it eg a default on 1 sec when not defined... but I’m also afraid there is a bit more to do... the multiple tuners on one cable ‘issue’

Edited by littlesat, 29 September 2018 - 10:07.

[WanWizard]

@Erik,

 

If that is already the case, it shouldn't be too difficult to add a delay before processing the next command in the code, ideally based on both a config item (diseqc delay yes/no) and the unicable/jess code puting a "delay command" in the queue?

[Erik Slagter]

The issue is actually there is no feedback from the lnb or switch that says command accepted and adapted you’re free to give me a next command as it is a one way communication... so you somehow always need to pause and hope...
So the pause is somehow mandatory..
Maybe we should consider somehow to add the timeout in unicable.xml and for the manual configurable add the feature... and give it eg a default on 1 sec when not defined... but I’m also afraid there is a bit more to do... the multiple tuners on one cable ‘issue’

No it's not "mandatory". The standard does not mention it, so it's not mandatory. But for some hardware it may be required for proper functioning.

[Erik Slagter]

If that is already the case, it shouldn't be too difficult to add a delay before processing the next command in the code, ideally based on both a config item (diseqc delay yes/no) and the unicable/jess code puting a "delay command" in the queue?

Which I am already telling over and over, is functionality that is already included, for ages. You just need to install the "DiSEqC delay" plugin which let's you control the various delays. The in enigma is already there. If that appears to be the solution, someone could make a specific plugin for this case.

[Huevos]

 

If that is already the case, it shouldn't be too difficult to add a delay before processing the next command in the code, ideally based on both a config item (diseqc delay yes/no) and the unicable/jess code puting a "delay command" in the queue?

Which I am already telling over and over, is functionality that is already included, for ages. You just need to install the "DiSEqC delay" plugin which let's you control the various delays. The in enigma is already there. If that appears to be the solution, someone could make a specific plugin for this case.

 

Which DiSEqC delay relates to SCR commands that are sent from different tuners over the same cable?

 

https://github.com/O....py#L1088-L1105

[Dimitrij]

		list = [
			(_("Delay after diseqc reset command"), config.sec.delay_after_diseqc_reset_cmd),
			(_("Delay after diseqc peripherial poweron command"), config.sec.delay_after_diseqc_peripherial_poweron_cmd),
			(_("Delay after continuous tone disable before diseqc"), config.sec.delay_after_continuous_tone_disable_before_diseqc),
			(_("Delay after final continuous tone change"), config.sec.delay_after_final_continuous_tone_change),
			(_("Delay after last voltage change"), config.sec.delay_after_final_voltage_change),
			(_("Delay between diseqc commands"), config.sec.delay_between_diseqc_repeats),
			(_("Delay after last diseqc command"), config.sec.delay_after_last_diseqc_command),
			(_("Delay after toneburst"), config.sec.delay_after_toneburst),
			(_("Delay after change voltage before switch command"), config.sec.delay_after_change_voltage_before_switch_command),
			(_("Delay after enable voltage before switch command"), config.sec.delay_after_enable_voltage_before_switch_command),
			(_("Delay between switch and motor command"), config.sec.delay_between_switch_and_motor_command),
			(_("Delay after set voltage before measure motor power"), config.sec.delay_after_voltage_change_before_measure_idle_inputpower),
			(_("Delay after enable voltage before motor command"), config.sec.delay_after_enable_voltage_before_motor_command),
			(_("Delay after motor stop command"), config.sec.delay_after_motor_stop_command),
			(_("Delay after voltage change before motor command"), config.sec.delay_after_voltage_change_before_motor_command),
			(_("Delay before sequence repeat"), config.sec.delay_before_sequence_repeat),
			(_("Motor running timeout"), config.sec.motor_running_timeout),
(_("Motor command retries"), config.sec.motor_command_retries) ]

[athoik]

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?

[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

Edited by Huevos, 30 September 2018 - 22:58.

[Huevos]

JESS standard:

 

Collision handling (receiver):
Remote tuning is a multi-master system, therefore data collisions may happen. Due to the hardware
of the distribution network (diode isolated splitters) no easy and safe collision prevention is
possible. The receivers can only "blindly" send out the tuning commands and have to check
whether the tuning command was processed or not. The method how to detect non-successful
tuning is described in EN50494.
In case of any non successful tuning command, the receiver repeats the command in pseudostatistic
intervals. Timeslots of 1.0 seconds are repeated, within these slots the repeat should
be started by random. The commands are sent out endlessly until the correct signal is received.
This repeat function must also be started if no signal is received at power-up of receiver.

Note for channel search: For channel search the command should not be sent more then 5
times. After that, a "not successful" message should be displayed.

 

 JESS Standard.pdf   78.99KB   3 downloads

[Huevos]

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.

[littlesat]

The delay in recordtimer solves also a different issue.... I had many times that one recording was 0 bytes even on dvb-c.... and Erik I wrote mandatory ‘somehow’......!

Edited by littlesat, 1 October 2018 - 06:07.

[Dimitrij]

This delay will be useful when using the softcam(oscam and etc).

[littlesat]

....

Edited by littlesat, 1 October 2018 - 12:12.

[Huevos]

Littlesat, the Unicable problem is a tuning issue. The debug logs prove it. It would be interesting to see your debug logs to see if the same problem is the cause.

 

If so I don't understand why because nothing is sent up the cable as there is nothing to switch.

[littlesat]

I'm afraid there are somehow two issues... and the work-a-round at least 'solved' one of them. The other issue created a file (just confirmed) but it has black screen as the picture was most likely not encrypted.

Edited by littlesat, 1 October 2018 - 13:38.

[Huevos]

So the recording that didn't work, is the duration zero length?