342 replies to this topic

[athoik]

This one doesn't seem right. Most probably the tuning is the new try and tune failed is the old event, that happens to processed after the new tune stated.

<  1349.154> [eDVBChannel] OURSTATE: tuning
<  1349.154> [eDVBServicePMTHandler] tune failed.

So, maybe the tune failed event, changes something that makes new tune to choose a code path that never completes tune?

[Huevos]

This one doesn't seem right. Most probably the tuning is the new try and tune failed is the old event, that happens to processed after the new tune stated.
 

<  1349.154> [eDVBChannel] OURSTATE: tuning
<  1349.154> [eDVBServicePMTHandler] tune failed.

So, maybe the tune failed event, changes something that makes new tune to choose a code path that never completes tune?

 

Sounds about right, because enigma is trying over and over in that log. So if this is the case it would definitely be a bug in enigma. And as soon as you cancel one recording the other recording goes from being zero length to actively recording.

[Huevos]

And I'll tell you something else that I said further back in the thread. I checked with my analyser and the SCRs are active and tuned to the correct transponders.

 

I can retest this if necessary.

Edited by Huevos, 6 October 2018 - 17:47.

[Huevos]

So IMO something internal in the code believes the LNB is not tuned when in fact it is.

[athoik]

There is a bug somewhere for sure! So we need to look in the right direction, the retune is there, but most probably a racing in re-tune code, makes it unusable then multiple re-tunes occur together.

Look on the "< 1349.154> [eDVBServicePMTHandler] tune failed.", you will find out that in lib/dvb/pmt.cpp is shown when state == iDVBChannel::state_failed.

Why do we need m_last_channel_state variable in lib/dvb/pmt.cpp?

Is there somewhere a code in enigma2 that changes m_last_channel_state to a value different than -1?

(PS. Of course that variable is not the problem, but it's part of the problem, since it's shown on the path).

Edited by athoik, 6 October 2018 - 18:21.

[Huevos]

There is a bug somewhere for sure! So we need to look in the right direction, the retune is there, but most probably a racing in re-tune code, makes it unusable then multiple re-tunes occur together.

Look on the "< 1349.154> [eDVBServicePMTHandler] tune failed.", you will find out that in lib/dvb/pmt.cpp is shown when state == iDVBChannel::state_failed.

Why do we need m_last_channel_state variable in lib/dvb/pmt.cpp?

Is there somewhere a code in enigma2 that changes m_last_channel_state to a value different than -1?

(PS. Of course that variable is not the problem, but it's part of the problem, since it's shown on the path).

I can't see one. That variable only exists in pmt.h and pmt.cpp. And only place that writes to it in line #883 in pmt.cpp.

 

If you want to build and output any debug let me know.

[Erik Slagter]

I have got the diseqc delays plugin. None of the delays are relevant to unicable.

Can you list them? Maybe some of the names are misleading in this regard.

[Erik Slagter]

Above you can see two tuners trying to tune, the tuner 0-A succeeds with status 1f, the tuner 1-B fails with status 7.
Then tuner B, tries several times, and it never tunes. It always fails with last status reported from tuner 7.
So the real question here is: Why tuner never got LOCK? Why re-tune failed?

In case you wonder what 7 or 1f is:
7 = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI
1f = FE_HAS_LOCK | FE_HAS_SYNC | FE_HAS_VITERBI | FE_HAS_CARRIER | FE_HAS_SIGNAL

That is plain weird. It suggests a signal is seen but can't be locked to. OTOH it suggests the '7' options are simply always on, because the tuner can't detect them (or the driver doesn't export this information).

 

And like you said, the first try failing can be explained, the next not. Unless not only the first tuner but all tuners are retried, then you get the same collision over and over again.

[Erik Slagter]

Sounds about right, because enigma is trying over and over in that log. So if this is the case it would definitely be a bug in enigma. And as soon as you cancel one recording the other recording goes from being zero length to actively recording.

I am also getting this feeling...

[littlesat]

Thinking about e2 retunes... maybe there could also be something driver related or the driver gives incorrect values. What if when we retune do ignore an error?

[Huevos]

 

I have got the diseqc delays plugin. None of the delays are relevant to unicable.

Can you list them? Maybe some of the names are misleading in this regard.

 

def InitSecParams():
	config.sec = ConfigSubsection()
	config.sec.delay_after_continuous_tone_disable_before_diseqc = ConfigInteger(default=25, limits = (0, 9999))
	config.sec.delay_after_final_continuous_tone_change = ConfigInteger(default=10, limits = (0, 9999))
	config.sec.delay_after_final_voltage_change = ConfigInteger(default=10, limits = (0, 9999))
	config.sec.delay_between_diseqc_repeats = ConfigInteger(default=120, limits = (0, 9999))
	config.sec.delay_after_last_diseqc_command = ConfigInteger(default=100, limits = (0, 9999))
	config.sec.delay_after_toneburst = ConfigInteger(default=50, limits = (0, 9999))
	config.sec.delay_after_change_voltage_before_switch_command = ConfigInteger(default=75, limits = (0, 9999))
	config.sec.delay_after_enable_voltage_before_switch_command = ConfigInteger(default=200, limits = (0, 9999))
	config.sec.delay_between_switch_and_motor_command = ConfigInteger(default=700, limits = (0, 9999))
	config.sec.delay_after_voltage_change_before_measure_idle_inputpower = ConfigInteger(default=500, limits = (0, 9999))
	config.sec.delay_after_enable_voltage_before_motor_command = ConfigInteger(default=900, limits = (0, 9999))
	config.sec.delay_after_motor_stop_command = ConfigInteger(default=500, limits = (0, 9999))
	config.sec.delay_after_voltage_change_before_motor_command = ConfigInteger(default=500, limits = (0, 9999))
	config.sec.delay_before_sequence_repeat = ConfigInteger(default=70, limits = (0, 9999))
	config.sec.motor_running_timeout = ConfigInteger(default=360, limits = (0, 9999))
	config.sec.motor_command_retries = ConfigInteger(default=1, limits = (0, 5))
	config.sec.delay_after_diseqc_reset_cmd = ConfigInteger(default=50, limits = (0, 9999))
	config.sec.delay_after_diseqc_peripherial_poweron_cmd = ConfigInteger(default=150, limits = (0, 9999))

From NimManager. These are what the plugin provides access to.

 

config.sec.delay_after_enable_voltage_before_motor_command let's us set sufficient time for the LNB to boot from cold where the LNB/switch is not using a power inserter or PSU.

Edited by Huevos, 7 October 2018 - 09:35.

[Huevos]

Ok. Solo4K. First observation is this STB supplies voltage to the LNB 24/7. The LNB is powered before enigma starts to boot. When the box is in standby the LNB is also powered. Only time power stops is on a reboot. But power returns before enigma boots.

[Huevos]

And I'll tell you something else that I said further back in the thread. I checked with my analyser and the SCRs are active and tuned to the correct transponders.

 

I can retest this if necessary.

Ok, have rechecked this and it is wrong. Whatever is being sent to the LNB is not tuning it. I can see the occasional blink on the spectrum display but nothing more.

[Huevos]

Then after 4 minutes of retries 1 of the SCrs  has become active and 1 recording has started to gain length.

 

The other 2 SCRs are not visible on the spectrum and those recordings continue at zero length.

[Huevos]

Ok, now I am 10 minutes into the recording and the other 2 SCRs have appeared on the display and all 3 recordings are increasing in length.

[Erik Slagter]

Thinking about e2 retunes... maybe there could also be something driver related or the driver gives incorrect values. What if when we retune do ignore an error?

We see this issue on more then one vendor's receiver.

[Huevos]

So the test was record 3 services. First recording started 4 minutes late. Other 2 started 10 minutes late.

 

Debug log just shows continual retries just as previous logs.

[Erik Slagter]

config.sec.delay_after_enable_voltage_before_motor_command let's us set sufficient time for the LNB to boot from cold where the LNB/switch is not using a power inserter or PSU.

I see several items that might help, even though their name doesn't directly suggests so.

 

Beware that "voltage" means "voltage change" here and not "power on".

[Huevos]

Thinking about e2 retunes... maybe there could also be something driver related or the driver gives incorrect values. What if when we retune do ignore an error?

You can't ignore the error. The LNB is not tuned.

[Erik Slagter]

 

And I'll tell you something else that I said further back in the thread. I checked with my analyser and the SCRs are active and tuned to the correct transponders.

 

I can retest this if necessary.

Ok, have rechecked this and it is wrong. Whatever is being sent to the LNB is not tuning it. I can see the occasional blink on the spectrum display but nothing more.

Maybe you saw the result of a previous tuning command (i.e. the user band was already tuned).

 

BTW please don't use "SCR" for user band. This misnomer is a result of the original code supplier (dvbadenin) that didn't really understand all of it and has remained in since then.

 

SCR = Single Cable Reception = Unicable or JESS (or any other similar system)

UB = User Band, the band, either frequency or index, a tuner has been allocated to use from the switch (which I think you're referring here to).

Edited by Erik Slagter, 7 October 2018 - 12:14.