242 replies to this topic

[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"

 

Maybe try option "PiP"?

 

That works without making the box stuck.
but isn't run automatically, because box gets stuck by recording sometime before each night.

 

Based on a suggestion from Erik, a new enigma version for test. This one has changes outside the thread in an attempt to make sure the SIGUSR1 arrives and is not blocked.

installed
 

[paneologist]

seams promising. Ran epgrefresh two times with fakerecording (5 and 10 seconds on channel) and now a third time (120 seconds). box didn't get stuck. yet.
 

That hardly ever changes, very occasionally there is an update of the bootloader, but that's about it.
 
The last driver set for the Duo 4K SE is from october 2021 ( https://github.com/O...xy-vuduo4kse.bb ) so that is the same as in 8.3-release.

I meant some code, that's "burnt" on a chip, which doesn't get changed/updated by software

Edited by paneologist, 19 August 2023 - 10:33.

[littlesat]

…

Edited by littlesat, 19 August 2023 - 11:12.

[paneologist]

managed to get a stuck again. while zapping (with timeshift). epgrefresh ran meanwhile.

2023-08-19T14:43:18+02:00 stb1.swabian.net enigma2: [eDVBServicePlay] timeshift
2023-08-19T14:43:18+02:00 stb1.swabian.net enigma2: [Navigation] playing:  1:0:19:287B:800:2:11A0000:0:0:0:
2023-08-19T14:43:18+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] read got interrupted by signal, stop: 0
2023-08-19T14:43:18+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] stopping thread: 100
[...]
2023-08-19T14:43:22+02:00 stb1.swabian.net enigma2: [gRC] main thread is non-idle! display spinner!
[...]
2023-08-19T14:43:38+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] stopping thread: 1
2023-08-19T14:43:38+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] thread could not be stopped!
2023-08-19T14:43:38+02:00 stb1.swabian.net enigma2: [eThread] Destroyed thread without joining it, this usually means your thread is now running with a halfway destroyed object

:-(

 

 stb1debuglog8.txt   5.18MB   0 downloads

[paneologist]

and one more, also while zapping. no epgrefresh this time.

 

Attached Files

•  stb1debuglog9.txt   222.78KB   1 downloads

[WanWizard]

I'll pass it back to Erik.

[Abu Baniaz]

Sorry, not been able to contribute to the tests properly.  I am not using FCC, timeshift or Picture in Picture. I was just recording many channels. My setup is currently using universal LNBs.

 

I am unable to get the lockup. I have tried following:

No EPG readers enabled

now/next only,

now/next and freesat,

now/next, freesat and openTV EPG (but did not zap to 11778)

 

I can record over 20 channels without a lockup, just lots of the "[eFilePushThreadRecorder] read got interrupted by signal, stop: 0" which @Wanwizard said is okay as it is waiting.

[littlesat]

Is timeshift now still involved…?

Edited by littlesat, 20 August 2023 - 07:59.

[paneologist]

bo got stuck this morning in standby - so without timeshift.

either after a timer or while epgrefresh

 stb1debuglog10.txt   346.65KB   1 downloads

[Erik Slagter]

 

 

        /* this works around the buggy Broadcom encoder that always returns even if there is no data */
        /* (works like O_NONBLOCK even when not opened as such), prevent idle waiting for the data */
        /* this won't ever hurt, because it will return immediately when there is data or an error condition */

void eFilePushThreadRecorder::thread()
{
#ifndef HAVE_HISILICON
	ignore_but_report_signals();
	hasStarted(); /* "start()" blocks until we get here */
#endif
	setIoPrio(IOPRIO_CLASS_RT, 7);
	eDebug("[eFilePushThreadRecorder] THREAD START");

#ifdef HAVE_HISILICON
	/* we set the signal to not restart syscalls, so we can detect our signal. */
	struct sigaction act;
	act.sa_handler = signal_handler; // no, SIG_IGN doesn't do it. we want to receive the -EINTR
	act.sa_flags = 0;
	sigaction(SIGUSR1, &act, 0);
	hasStarted();
#endif

	/* m_stop must be evaluated after each syscall */
	/* if it isn't, there's a chance of the thread becoming deadlocked when recordings are finishing */
	while (!m_stop)
	{
#ifndef HAVE_HISILICON
		/* this works around the buggy Broadcom encoder that always returns even if there is no data */
		/* (works like O_NONBLOCK even when not opened as such), prevent idle waiting for the data */
		/* this won't ever hurt, because it will return immediately when there is data or an error condition */

		struct pollfd pfd = { m_fd_source, POLLIN, 0 };
		poll(&pfd, 1, 100);
		/* Reminder: m_stop *must* be evaluated after each syscall. */
		if (m_stop)
			break;

		ssize_t bytes = ::read(m_fd_source, m_buffer, m_buffersize);
		/* And again: Check m_stop regardless of read success. */
		if (m_stop)
			break;
#else
		ssize_t bytes = ::read(m_fd_source, m_buffer, m_buffersize);
#endif
		if (bytes < 0)
		{
			bytes = 0;
#if HAVE_HISILICON
			/* Check m_stop after interrupted syscall. */
			if (m_stop) {
				break;
			}
#endif
			if (errno == EINTR || errno == EBUSY || errno == EAGAIN)
			{
#if HAVE_HISILICON
				usleep(100000);
#endif
				continue;
			}
			if (errno == EOVERFLOW)
			{
				eWarning("[eFilePushThreadRecorder] OVERFLOW while recording");
				++m_overflow_count;
				continue;
			}
			eDebug("[eFilePushThreadRecorder] *read error* (%m) - aborting thread because i don't know what else to do.");
			sendEvent(evtReadError);
			break;
		}

#ifdef SHOW_WRITE_TIME
		struct timeval starttime = {};
		struct timeval now = {};
		gettimeofday(&starttime, NULL);
#endif
		int w = writeData(bytes);
#ifdef SHOW_WRITE_TIME
		gettimeofday(&now, NULL);
		suseconds_t diff = (1000000 * (now.tv_sec - starttime.tv_sec)) + now.tv_usec - starttime.tv_usec;
		eDebug("[eFilePushThreadRecorder] write %d bytes time: %9u us", bytes, (unsigned int)diff);
#endif
		if (w < 0)
		{
			eWarning("[eFilePushThreadRecorder] WRITE ERROR, aborting thread: %m");
			sendEvent(evtWriteError);
			break;
		}
	}
	flush();
	sendEvent(evtStopped);
	eDebug("[eFilePushThreadRecorder] THREAD STOP");
}

void eFilePushThreadRecorder::start(int fd)
{
	m_fd_source = fd;
	m_stop = 0;
	run();
}

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();
}

errno == EAGAIN

			if (errno == EINTR || errno == EBUSY || errno == EAGAIN)
			{
#if HAVE_HISILICON
				usleep(100000);
#endif
				continue;

 

What's the purpose of this? I see some code being disabled on HISIL platforms???

[Dimitrij]

This OpenViX filepush.cpp

[Erik Slagter]

Is timeshift now still involved…?

 

Good question.

 

Although I am using timeshift too and I am not experiencing the problem.

 

Wanwizard has found a note (on Linux system calls) with a warning that a race condition is possible whenever

- a thread is created

- the thread itself is started

- the thread itself is blocking certain signals (block = defer, not ignore or drop)

- the parent sends the signal

 

In this case the signal may arrive at the thread before the thread block is in place and active.

 

The interesting thing is that when the signal is delivered to the thread (with no active block mask installed yet), you'd say all of enigma should get killed, as I think enigma itself doesn't have a handler for it and the default action is "terminate".

 

Anyway it suggests that the parent should (temporarily!) install a signal blocking mask (for SIGUSR1), then create and start the thread and the thread will inherit the mask. After the thread has started, the parent can revert the signal blocking mask. This would eliminate the window for the race condition. On the other hand, this also adds complexity and possibilities for hangs. How log do we wait for the thread to start? What if it doesn't start at all? How do we know, in a reliable way, that the thread has finished installing it's signal handler?

 

Obviously it's not possible to have the parent install the signal handler for the thread (which would be the best way to go).

Edited by Erik Slagter, 20 August 2023 - 09:50.

[Erik Slagter]

This OpenViX filepush.cpp

 

Question remains, what is the difference. I see my own code, with added #ifdef's for HiSil...

[Dimitrij]

 

Question remains, what is the difference. I see my own code, with added #ifdef's for HiSil...

 

I don't know the details, just look at the history of the file, but this code works flawlessly.

Yes, you don't want workarounds, but sometimes you can't do without it.

[littlesat]

They try to exclude broadcom from the Erik’s changes instead of trying to resolve the issue..: do they also still use streamproxy for transcode….?

[Huevos]

They try to exclude broadcom from the Erik’s changes instead of trying to resolve the issue..: do they also still use streamproxy for transcode….?

Actually the issue was resolved by Simon Capwell's commits. For some reason PLi reverted them and went another way and has been and still remains broken for more than a year.

 

As usual PLi always knows the best way how not to fix something and replaces working code with better but broken code.

[WanWizard]

So, what was exactly the issue? What exactly did Simon fix? I would like to understand the root cause of the problem, so I can understand the fix too.

What exactly was reverted, as I don't see any revert in git history?

[Huevos]

So, what was exactly the issue? What exactly did Simon fix? I would like to understand the root cause of the problem, so I can understand the fix too.

What exactly was reverted, as I don't see any revert in git history?

Ok, I am slightly mistaken due to the 3 years that have elapsed since this issue was first fixed by Simon. Simon sent the pull requests to OpenViX and provided the links to PLi, but Erik decided he was going to fix it another way. At ViX we gave Erik's commits a chance. 17 commits in total because nothing worked and I suspect in the end he just gave up. All of this between Nov 2000 and Jan 2021. In the end I gave up reporting the problems and reverted ViX to Simon Capewell's fully working commits.

 

You can see the PLi ten-page thread here:

https://forums.openp...es-in-filepush/

[paneologist]

I found a workaround:

wrote a script that rings my phones, when the box gets stuck I get awake and restart the stb.

 

jokes aside (but really did that, so I won't miss too much recordings): I'll promise, if my current 3 major issues get resolved (and my bank account is balanced again) I'll make a nice donation to this project. Don't want to add pressure, but still a reward.

[Huevos]

 

This OpenViX filepush.cpp

 

Question remains, what is the difference. I see my own code, with added #ifdef's for HiSil...

 

The difference is it doesn't freeze enigma, requiring a restart.