Posts by smp

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.

@a9d1af5b6d

Try this LE9 RPi2 build with Linus Torvalds' softirq patch and kernel 4.9.73. Works great, no issues even when recording.

Quote from a9d1af5b6d

when I watch Live-TV while recording (the same channel, like timeshift) there are audio drop-outs.

I noticed the audio dropouts with kernels 4.14/4.15 but didn't want to post about it in this thread because this issue is unrelated to softirq. There is no such problem with kernel 4.9 (with patched and unpatched softirq).

I did some basic performance testing with different kernels but with otherwise identical builds. For some reason kernels 4.14/4.15 generally perform much worse than 4.9 in LE and have all sorts of audio issues (the dropouts sometimes happen even when there's not much network or i/o activity).

I now tested the patch from Linus Torvalds with kernel 4.9.75 and 4.14.10 and it works great, no issues whatsoever. I can only test on RPi3.

Quote from polo_joe

Linus provided a further patch. Please test

This looks very good. No video corruption, same effect as reverting 4cd13c21b207e80ddb1144c576500098f2d5f882.

I tried to increase the buffer size even further

stream = DVB_USB_STREAM_BULK(0x82, 128, 8192)

No improvement as well.

No improvement whatsoever with the buffer increase patch.

Ok, I compiled an RPi2 build with dvbsky buffer patch, no reverted commits, kernel 4.9.73. VDR works. Testing right now.

Quote from milhouse

Presumably the VDR issue is unrelated to the kernel patch.

This must be somehow related, I never had an issue with VDR before. No clues in kodi.log or "dmesg | grep dvb". The tuner seem to be enabled but VDR backend just doesn't start.

I will try it with my own build.

Quote from milhouse

Please test and report results - thanks!

VDR server does not start with that build.

Quote from mvestola

But now I upgraded to image provided by milhouse (this one: LibreELEC-RPi2.arm-9.0-Milhouse-20180102133316-#0101z-g866291e.tar

You can now use Milhouse' nightly builds - the ksoftirqd patch is included since build #0104.

Can you upload the recording somewhere? I will test it on my hardware.

This commit broke the DVD playback for me:

06:22:58.511 T:1942380560  NOTICE: VideoPlayer::OpenFile: smb://SMP-PC/MEDIA3/TEST_DVD/VIDEO_TS/VIDEO_TS.IFO
06:22:58.517 T:1629184912  NOTICE: Creating InputStream
06:22:58.528 T:1942380560  NOTICE: m_playbackStarting
06:22:58.528 T:1942380560  NOTICE: StereoscopicsManager::IsPlaying
06:22:58.563 T:1629184912   ERROR: Error on dvdnav_open
06:22:58.563 T:1629184912   ERROR: CVideoPlayer::OpenInputStream - error opening [smb://SMP-PC/MEDIA3/TEST_DVD/VIDEO_TS/VIDEO_TS.IFO]

The build host is Linux Mint 18.2 / Core i5-3450 / 8Gb RAM. I build only RPi2 images, so no idea if the issue is present in Generic x86,etc.

If I remove LTO support from kodi/package.mk - DVDs work fine.

Can anyone confirm the issue? The weird thing is that the current Milhouse builds don't have this issue but I can reproduce it 100% when building using normal LE build method or using Milhouse' scripts.

Thank you jahutchi for this.

I tested on RPi3 with kernel 4.14.10 and I can confirm that reverting commit 4cd13c21b207e80ddb1144c576500098f2d5f882 completely fixed the issue.