(Solved) What causes this kind of crash?

Hi there,

what causes this kind of crash

crash.log: http://ix.io/1c66 ?

kodi.log: http://ix.io/1c67

Is it a hard- or software problem?

Afterwards, either no contact with vdr server via vnsi or keyboard does no longer respond. I have to reboot every day and recordings now show visual artifacts.

System is a brand new RPI 3B+ with stock power supply, 32GB SanDisk SD-card, Hauppauge WinTV soloHD and external WD HDD, Belkin F4U040 USB-Hub and of course LE 9.0

Any information missing for you?

dmesg: http://ix.io/1c6s

The power supply was sold as an official device. It also bears the raspberry logo so I think it's true.

Yes, that was the complete dmesg. In the past I tried disconnecting every device one after another. Among them was the Hauppauge. But since I saw the next morning that the RPI had crashed I did not suspect the TV card.

In order to provide the 'missing part' in the dmesg I rebooted again with all external devices disconnected but TV and network and to my surprise, UI was again frozen and didn't react to the remote via CEC.

I could ssh into the RPI and the dmesg is here http://ix.io/1c6l

I will have a look tomorrow as to what happened overnight.

Could this maybe come from the TV via HDMI cable although as said I also had disconnected that to no avail in the past?

Okay, bought a new TV stick (WinTV-dualHD) and the crashes and the artifacts are gone (at least until now) but my dmesg is still flooded with:

"dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 14 instead of 15. 188 bytes lost"

Google search told me that flooding the system with such an amount of error messages can make the system instable (still turning off the keyboard as in my case after quite some time). The recommendation is to disable debugging at compile time by using

CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=n 

with v4l. Obviously, I cannot do that.

Any idea how to stop this via a /proc /sys or module setting?

Solved!

The culprit was the 'DVB drivers from the latest kernel'. I switched back to the LE Standard Driver and the kernel ring buffer (dmesg) was no longer swamped with errors. Sigh!

I think that this also was the reason for the instability as I did not see any artifacts or breaks. So beware of the new drivers at least if you have an Hauppauge WinTV soloHD or WinTV-dualHD.