242 replies to this topic

[Dimitrij]

and which "ü" causes it?
have 33 lines with this letter in timers.xml

This timer not save as enigma crash

[paneologist]

box got stuck again, with develop image:

 stb1debuglog6.txt   252.6KB   0 downloads

and lsof if of interest:

 stb1lsof.txt   15.54KB   1 downloads

 

and got the timer-related crashes (after every timer? or whenever this cleanup is being done).

-rw-r--r--    1 root     root       48.2K Aug 13 11:08 enigma2_crash_1691917689.log
-rw-r--r--    1 root     root       46.6K Aug 13 11:19 enigma2_crash_1691918368.log
-rw-r--r--    1 root     root       61.7K Aug 13 11:32 enigma2_crash_1691919134.log
-rw-r--r--    1 root     root       59.8K Aug 13 11:47 enigma2_crash_1691920048.log
-rw-r--r--    1 root     root       55.4K Aug 13 12:21 enigma2_crash_1691922099.log
-rw-r--r--    1 root     root       59.8K Aug 13 12:32 enigma2_crash_1691922748.log
-rw-r--r--    1 root     root       48.2K Aug 13 12:35 enigma2_crash_1691922954.log
-rw-r--r--    1 root     root       29.1K Aug 13 13:51 enigma2_crash_1691927484.log
-rw-r--r--    1 root     root       58.5K Aug 13 13:59 enigma2_crash_1691927940.log
-rw-r--r--    1 root     root       21.3K Aug 13 14:03 enigma2_crash_1691928180.log
-rw-r--r--    1 root     root       25.3K Aug 13 14:59 enigma2_crash_1691931540.log
-rw-r--r--    1 root     root       19.7K Aug 13 15:45 enigma2_crash_1691934300.log
-rw-r--r--    1 root     root       19.7K Aug 13 16:03 enigma2_crash_1691935380.log
-rw-r--r--    1 root     root       19.7K Aug 13 16:29 enigma2_crash_1691936940.log
-rw-r--r--    1 root     root       19.7K Aug 13 16:33 enigma2_crash_1691937180.log
-rw-r--r--    1 root     root       19.7K Aug 13 16:59 enigma2_crash_1691938740.log
-rw-r--r--    1 root     root       19.7K Aug 13 17:01 enigma2_crash_1691938860.log
-rw-r--r--    1 root     root       19.7K Aug 13 17:03 enigma2_crash_1691938980.log
-rw-r--r--    1 root     root       19.7K Aug 13 17:31 enigma2_crash_1691940660.log
-rw-r--r--    1 root     root       29.3K Aug 13 20:46 enigma2_crash_1691952360.log
-rw-r--r--    1 root     root       26.3K Aug 13 21:40 enigma2_crash_1691955600.log
-rw-r--r--    1 root     root       26.2K Aug 13 22:03 enigma2_crash_1691956980.log
-rw-r--r--    1 root     root       22.5K Aug 13 22:10 enigma2_crash_1691957400.log
-rw-r--r--    1 root     root       26.6K Aug 13 22:40 enigma2_crash_1691959200.log
-rw-r--r--    1 root     root       26.4K Aug 13 23:10 enigma2_crash_1691961000.log
-rw-r--r--    1 root     root       26.1K Aug 13 23:45 enigma2_crash_1691963100.log

any way to fix that?

Edited by paneologist, 14 August 2023 - 13:12.

[paneologist]

some crashes look like this:

 enigma2_crash_1691922954.log   48.18KB   3 downloads

../../git/lib/base/ebase.cpp:155 ASSERTION notifiers.find(fd) == notifiers.end() FAILED!

[Old Satterhand]

Hi, I'm 'new' here and have read this topic because I have (had) the same issue.
For me it only happened when switching or reverting to a DVB-C channel.
I have a setup with a VU+ Ultimo 4K and 1 FBC DVB-S2 slot and 1 FBC DVB-C slot, correct installed.

I think I found a workaround.
I noticed that deleting epg.dat was a temperal 'solution'
As the epg file grows, the chance of getting the spinning wheel again became greater.(> 25 MByte)

To make a long story short, I managed to get rid of the problem by disabling the last 4 virtual DVB-C tuners.
I did not see the spinning wheel for a week now. The epg.dat has a normal size now (10-20 Mbyte)

I realise it is only a workaround, but I seldom need more than 4 DVB-C tuners.

[littlesat]

I understand that previously we had a streamproxy for transcode for broadcom (VU+) transcode and with the proxy it worked fine and then we tried to get this in the code without streamproxy. But it seems the drivers from VU+ for example respond a bit unexpected so we indeed can get some unexpected behavior where we need to work-a-round.

 

Maybe doing a lot of revert stuff, bring back the streamproxy etc... will be a big step back... but a work-a-round as solution.... -or- we need to find all the troubles the drivers give us and find a good solution alias work-a-rounds for that.

[WanWizard]

I've discussed this with Erik, he's back from holiday since yesterday, and awaiting delivery of a new build system. He's promised to look into it after it arrives, currently he can't test.

[paneologist]

just an update from my site.

with state of the nightly build of yesterday and today.

Those crashes, regarding the "ü" in a timer and "../../git/lib/base/ebase.cpp:155 ASSERTION notifiers.find(fd) == notifiers.end() FAILED!" seem to be gone.   thanks

 

but the main issue happens more often than ever.

I really would like to have a working box and working recordings again. I already considered to switch to openATV until this issue is resolved. But I really really don't want to. I want to stay with openPLi, because I want a stable box... And I have no experience with openATV...

I've got the same opinion as WanWizard, better to find and fix the cause than a dirty fix. But as a interim solution, would something like that be possible:

	if(safeguard <= 0)
		eWarning("[eFilePushThreadRecorder] thread could have not been stopped!");
	kill();

that way, I would still have those events in the log as I currently always run enigma2 with debug logging.

maybe  possible to supply a custom ipk with a code like that?

Edited by paneologist, 16 August 2023 - 11:45.

[Old Satterhand]

 

I really would like to have a working box and working recordings again.

 

Please try the following steps:

 

• delete epg.dat in the root of the HD.
• switch off the STB to prevent E2 saving a new epg.dat .
• Switch off half of your virtual tuners.
• Report the results

If you need more tuners during testing you can add one by one, until.....

[WanWizard]

jbut the main issue happens more often than ever.

I really would like to have a working box and working recordings again. I already considered to switch to openATV until this issue is resolved. But I really really don't want to. I want to stay with openPLi, because I want a stable box... And I have no experience with openATV...

 

Oh, I which I could reproduce it, as easy it is for you, it remains impossible for me...

 

maybe  possible to supply a custom ipk with a code like that?

 

Here you go.

I've also extended the safeguard loop, to see if eventually the SIGUSR1 comes, like @abu's log shows. According to the libc documentation, signals can be deferred, but are never lost.

Attached Files

•  enigma2_3.9+git20835+ee42d8e-r0.0_vuduo4kse.ipk   5.58MB   2 downloads

[paneologist]

Please try the following steps:

 

• delete epg.dat in the root of the HD.
• switch off the STB to prevent E2 saving a new epg.dat .
• Switch off half of your virtual tuners.
• Report the results

If you need more tuners during testing you can add one by one, until.....

 

I try that. But iirc, the problem existed before I set up unicable/jess and had therefor less tuners. Shutdown enigma2, deleted epg.dat, rebooted, disabled the 2nd FBC twin-tuner.

 

maybe  possible to supply a custom ipk with a code like that?

 

Here you go.

I've also extended the safeguard loop, to see if eventually the SIGUSR1 comes, like @abu's log shows. According to the libc documentation, signals can be deferred, but are never lost.

 

 

thank you. will install that afterwards/tomorrow.
 

btw. noticed something on the console:

 

root@stb1:/media/hdd# file enigma2_3.9+git20835+ee42d8e-r0.0_vuduo4kse.ipk
file: File 5.39 supports only version 16 magic files. `/usr/share/misc/magic.mgc' is version 14 (No such file or directory)

is that on purpose?

Edited by paneologist, 16 August 2023 - 15:32.

[WanWizard]

This is a develop version of enigma, you were running a develop image, right? And no idea what you want to do with that "file" command.

[paneologist]

This is a develop version of enigma, you were running a develop image, right? And no idea what you want to do with that "file" command.

yes, that's right.

 

just wanted to mention, that the file command on the stb doesn't work at all. I normally use it quite often to determine types of a file.

It works on my xtrend et10000  with release openpli-8.3 tho.
I think it worked on the Vu+ with the release version too, but not 100% sure.

[Dimitrij]

Need latest develop image

enigma2_3.9+git20835+ee42d8e-r0.0_vuduo4kse.ipk --> need only /usr/bin/enigma2

I wouldn't overwrite normal e2 binary. Just copy it to /tmp and make it executable "chmod 755 /tmp/enigma2"

Start the new binary "ENIGMA_DEBUG_LVL=4 /tmp/enigma2  >> /tmp/debug.log 2>& 1"

[WanWizard]

just wanted to mention, that the file command on the stb doesn't work at all. I normally use it quite often to determine types of a file.
t works on my xtrend et10000  with release openpli-8.3 tho.
I think it worked on the Vu+ with the release version too, but not 100% sure.

 

I have in general no issues with file.

 

You have to be careful with ipk files, most assume they are standard tarballs, but opkg uses "ar", so perhaps that is why file fails to see the inside...

[paneologist]

 

 

I really would like to have a working box and working recordings again.

 

Please try the following steps:

 

• delete epg.dat in the root of the HD.
• switch off the STB to prevent E2 saving a new epg.dat .
• Switch off half of your virtual tuners.
• Report the results

If you need more tuners during testing you can add one by one, until.....

 

didn't work. box got stuck twice.

 

installed the custom ipk.

 

the "file" command doesn't work at all. regardless on which file I use it:
 

 

# file /etc/inittab
file: File 5.39 supports only version 16 magic files. `/usr/share/misc/magic.mgc' is version 14 (No such file or directory)

ok solved:

 

root@stb1:~# opkg search /usr/share/misc/magic.mgc
file - 5.39-r0.8
root@stb1:~# opkg install --force-reinstall file
Downloading http://downloads.ope...mv7ahf-neon.ipk.
Installing file (5.39) on root
update-alternatives: removing /usr/bin/file as no more alternatives exist for it
Configuring file.
update-alternatives: Linking /usr/bin/file to /usr/bin/file.file
root@stb1:~# file /etc/inittab
/etc/inittab: ASCII text

but how can that be? was /usr/share/misc/magic.mgc replaced by any other package? wouldn't "opkg search" find that package too...

[WanWizard]

No idea.

[paneologist]

No idea.

never mind. working now. but opens the question, if any other files are incorrect, despite flashed an image and updated with opkg....

had two crashes - I didn't even notice - after rebooting again -  "../../git/lib/base/ebase.cpp:155 ASSERTION notifiers.find(fd) == notifiers.end() FAILED!"

 enigma2_crash_1692256651.log   45.35KB   1 downloads  enigma2_crash_1692257859.log   49.2KB   1 downloads

[WanWizard]

I've long since given up understanding what is going on, on your box...

 

What I do see:

[eFilePushThreadRecorder] stopping thread: 100
[eFilePush] SIGUSR1 received
[eFilePushThreadRecorder] read got interrupted by signal, stop: 1
[eDVBRecordFileThread] waiting for aio to complete
[eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
[eDVBRecordFileThread]   1:      6
[eDVBRecordFileThread]   2:      6
[eFilePushThreadRecorder] THREAD STOP

[eFilePushThreadRecorder] stopping thread: 250
[eFilePush] SIGUSR1 received
[eFilePushThreadRecorder] read got interrupted by signal, stop: 1
[eDVBRecordFileThread] waiting for aio to complete
[eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
[eDVBRecordFileThread]   1:     14
[eDVBRecordFileThread]   2:     14
[eFilePushThreadRecorder] THREAD STOP

is that the SIGUSR1 now arrives, albeit very late.

Is that my enigma2 binary for both? The last one is (given the 250 counter value). If so, it could very well be caused by the forced kill() that was added. Erik said a few days ago that is was definitely not the solution.

[paneologist]

Is that my enigma2 binary for both? The last one is (given the 250 counter value). If so, it could very well be caused by the forced kill() that was added. Erik said a few days ago that is was definitely not the solution.

I think I installed it in between.
And I also have my eyes open for "thread could not be stopped! Killed anyway." - didn't get it yet

Edited by paneologist, 17 August 2023 - 10:37.

[WanWizard]

No, because if both log, the SIGUSR1 signal arrived and terminated the thread cleanly.

 

What is weird, is that in both cases it arrived exactly when the failsave loop was finished, i.e. after 100 and 250 waits. Which sort of confirms my suspicions that something is blocking signals.