Posts by smp

Quote from libreelec-cro

I have dvb tevii 650 usb , only with this tar file is scanned correctly 16 east channels.

Kernel 4.8.13 and Kodi 17.3

I restored the file - the dropbox link should work now.

Quote from libreelec-cro

I need this libreelec tar:

LibreELEC-RPi2.arm-8.0.2-k48

I already deleted it. Why do you need it?

Quote from velqn

is there a way to get the SMB chunk size fixed in the latest stable 8.2.3 LibreELEC

I built a 8.2.3 image with modified SMBFile.h (chunk size set to 64K). I did not test it and have no idea if this change has a positive (or any) effect on Kodi 17.

LibreELEC-RPi2.arm-8.2.3-smb-64k.tar

Try the current Milhouse build. And check out the last few pages of that thread regarding the changes of the SMB chunk size.

Quote from augenweide

But I dont see continuity errors in the tvheadend webinterface.

Then It's an unrelated issue.

Quote

I have a PCIe DVBSky T9580 V3

I don't think that PCIe cards are even affected by the kernel softirq problem.

Quote from Bertel

Which would indicate that my system is not overclocked

Your log file suggests otherwise:

arm_freq=1000
sdram_freq=500
core_freq=500

Are you using pi2 or pi3?

Default arm_freq for pi2 is 900, core_freq is 250.

For pi3 default value for arm_freq is 1200, core_freq is 400.

Also from your log file:

18:53:01.854 T:1961745360  NOTICE: ARM mem: 864MB GPU mem: 160MB MPG2:0 WVC1:0

160 mb for GPU mem is too low. This will cause issues with HEVC decoding. You definitely need to add or edit the gpu_mem_1024 value in config.txt.

Update: I just tested with gpu_mem_1024=160 on my pi3. With that setting Kodi crashes immediately after I start the playback of a HEVC file.

Quote from Bertel

Sadly nothing has changed in regard to my problem with playback. Some files still crash the system

Try to temporarily remove all overclocking.

Also, set the the gpu_mem_1024 value in config.txt to 256.

Quote from Bertel

What could I have overlooked?

added screenshot showing update file in folder

I'm not really sure, It looks fine to me. Maybe berryboot has something to do with this.

Create a backup in case you will need to go back to LE 8.

Download the latest Milhouse build. Copy the .tar file to storage/.update and reboot.

LE9 is in pre-alpha.

As far as I can tell from that log you are using Raspberry Pi2 and trying to play HEVC 10-bit videos. You need LibreELEC 9 / Kodi 18 to play 10-bit HEVC on RPi2.

1080p/24 HEVC work rather well on an overclocked RPi3. On RPi2 you will probably get a lot of frame drops. 720p should be OK.

A small sample of the problematic file could be useful.

Quote from the_bo

Are you able to use adv (x2)

Yes. There is no reason not to use advanced x2.

Quote from HiassofT

have you tested if you get the same results if recording to a USB HDD instead of sdcard?

I actually get the same results even if there is no recording going on (~1 or 2 ActiveAE errors per hour in kodi.log and rare short audio dropouts). Recording just makes the issue far more obvious and easy to reproduce.

Tested kernels 4.11.9 and 4.10.14. With both I had audio dropouts / ActiveAE errors in kodi.log when recording to an sdcard.

Absolutely no issues with kernel 4.9.75 + Linus softirq patch. Not a single audio dropout, no ActiveAE errors in log.

Quote from smp

Will test 4.12 now.

Same issue with kernel 4.12.14. Will test 4.11 now.

Quote from jahutchi

did you see continuity errors such as these in your tvheadend log?

I don't use tvheadend, I use VDR. There are audio dropouts and tons of ActiveAE errors in kodi.log when there is any network activity or during recording to an RPi's sdcard. I just tested a build with kernel 4.13.16 and the issue is there too. Will test 4.12 now.

Quote from jahutchi

So I would suggest this further regression has occurred since 4.11.12.

I will compile and test a couple of RPi2 builds with kernels 4.12 and 4.13. Thankfully the issue is very easy to reproduce.

Quote from jahutchi

there has been a further regression in later kernels 4.14/4.15?

I'm afraid so. But unlike the softirq problem this does not affect the recorded stream, this is a playback-only issue. Also, I don't know when this started - I did not test kernels 4.10/4.11/4.12/4.13.