242 replies to this topic

[WanWizard]

Why?

 

This is a delay loop, to take the fact that triggering the SIGUSR1 signal is executed asynchronously.

 

The loop counts down to 0 after which it terminates, unless m_stopped is set by that signal, in which case that if stops the loop earlier.

 

Adding "safeguard == 1" to this if doesn't change anything, the loop is terminated anyway when safeguard goes from 1 to 0.

[WanWizard]

Dimitrij,

 

The direct cause of the loop not terminating is the fact the signal isn't send or caught. i.e., this messaage (https://github.com/O...ilepush.cpp#L37) isn't in the debug log.

 

Which means either the signal isn't send, or something is blocking the signal to stop the filepush and terminate the running thread.

 

I see the same signal is used in both eFilePushThread and eFilePushThreadRecorder, could it be that if one triggers, the other one doesn't work anymore?

[Dimitrij]

 

Adding "safeguard == 1" to this if doesn't change anything, the loop is terminated anyway when safeguard goes from 1 to 0.

That's right, the loop ends(safeguard  0), but not run force  killl().

And we get enigma freeze.

 

 

I see the same signal is used in both eFilePushThread and eFilePushThreadRecorder, could it be that if one triggers, the other one doesn't work anymore?

Everything can be. Eric talked a lot about this topic and came to the conclusion that different receivers process signals and stop the flow in different thread.

Edited by Dimitrij, 9 August 2023 - 05:26.

[paneologist]

 

you may be right. and I crowed to soon.
It happened again. Just installed "enigma2-plugin-extensions-multirc", rebooted (unintentially while a recording was made), looked into openwebif, looked through timers and recordings and.. spinner.

 

Please disable automatic timeshift (which is also a recording), and see if that makes a difference.

 

I have a feeling that nobody here that don't experience this issue uses timeshift? @Abu, do you?

 

I really doubt it has to do something with timeshift. most times it happens when the box is in standby, running epgrefresh. as it did this morning. log attached:  stb1debuglog2.txt   5.06MB   1 downloads

 

@paneologist,

 

willing to install a test image?

yes

 

[Abu Baniaz]

I don't use timeshift. I'll try the tests tomorrow (next day off). It was basically record about 30 channels on a barebones image using universal LNBs and it locks up. Nothing extra installed. No defaults changed, no restores.

[littlesat]

most times it happens when the box is in standby, running epgrefresh

 

Interesting...  In standby and with epgrefresh the box is tuning/playing services as far I know while not showing them by simulating a kind of recording (EPGRefresh.RecordAdapter.play). The big question for now is this a trigger/condition? Then maybe we should resolve it here... within this plugin... or the way how the plugin is zapping in standby by doing 'fake dummy' recordings. Sorry I did not check the details for now how the plugin is doing this...

 

I never use here epgrefresh, maybe that is also why I never get into this issue.

Edited by littlesat, 9 August 2023 - 12:28.

[paneologist]

 

most times it happens when the box is in standby, running epgrefresh

 

Interesting...  In standby and with epgrefresh the box is tuning/playing services as far I know while not showing them. The big question for now is this a trigger/condition? I never use here epgrefresh, maybe that is also why I never get into this issue.

 

forget to mention, epgrefresh is set to use "fake recordings"

[littlesat]

And we push files here and we do fake recordings.... That creates ??!! to me. Maybe it is the way of how the fake recordings are done....

I hope we finally find a direction here.

Edited by littlesat, 9 August 2023 - 12:30.

[WanWizard]

forget to mention, epgrefresh is set to use "fake recordings"

 

I checked on my box, I just have the box tune and zap. So that is a difference.

 

That's right, the loop ends(safeguard  0), but not run force  killl().

And we get enigma freeze.

 

That might well be the cause of the freeze, but not the root cause of the problem, which is "why doesn't sending the SIGUSR1 signal not set m_stopped and terminate the loop before safeguard is zero?"

 

So I am reluctant to change this, as it will bury the underlying problem, which will undoubtly bite us later, bugs always do...

[WanWizard]

And we push files here and we do fake recordings.... That creates ??!! to me.

 

I looked in the code:

 

a "fake recording" is not a recording at all, it is starting a stream that doesn't go anywhere. It might very well be this code isn't ok anymore with the changes made to streaming, the code calls methods deep in Enigma directly...

 

See https://github.com/O...ecordAdapter.py

[littlesat]

 it is starting a stream that doesn't go anywhere

Indeed it is not a recording and it streams to nothing.... I think it might be likely we find the trigger... and I was already afraid of it in an early stage (but with a different reason).

[Dimitrij]

Let's just apply and test it

+	kill();
-	if(safeguard > 0)
-		kill();
-	else
-		eWarning("[eFilePushThreadRecorder] thread could not be stopped!");
}

see others images

void eFilePushThreadRecorder::stop()
{
	/* if we aren't running, don't bother stopping. */
	if (m_stop == 1)
		return;
	m_stop = 1;
	eDebug("[eFilePushThreadRecorder] stopping thread."); /* just do it ONCE. it won't help to do this more than once. */
	sendSignal(SIGUSR1);
	kill();

always run kill()

Edited by Dimitrij, 9 August 2023 - 13:49.

[WanWizard]

No, because it doesn't fix the problem, it buries it.

[Dimitrij]

OK.

Continue without me.

[WanWizard]

How difficult is it to understand that your suggestion doesn't fix the problem, but hides it?

 

And that "other images" often have this kind of stupid "fixes" which is why we are critical about just copying someone elses code?

[Dimitrij]

 

And that "other images" often have this kind of stupid "fixes" which is why we are critical about just copying someone elses code?

This is not a copy of someone else's code, but a return to the state before these problems appeared.

That's all.

[Stan]

 Yes... this part of code is already full of workarounds or "stupid fixes" as you call them. And in this case, they are not coming from other images.

[WanWizard]

@dimitrij,

 

You wrote "see other images" to which I assume OE-A.

 

You don't know what the problem is, so how can you call it a fix? You just throw some code it that masks the error... The user doesn't see it anymore, so problem solved? No, it is swept under the carpet.

 

And that code you quoted does exactly the same, so it is not a fix, it just leaves the root cause of the problem where it is. Bad coding practice imho, similar to puting a blanked try/except everywhere, without testing specific exceptions.

[Dimitrij]

This issue is three years old.

I followed the situation closely.

Nothing has changed in three years and hardly anything will change at all.

The receiver must be de-energized!

Do you think this is normal?

And you're telling me that I'm trying to come up with a workaround?

Edited by Dimitrij, 9 August 2023 - 16:54.

[littlesat]

I would say first confirm if it is really related to the fake recording alias dummy streaming of the epgrefresh plugin and if so resolved that. I think for now reverting is not an option as it worked as it for years. I never get the described interlock here, but I also never used epgrefresh.