RPi3 Success - resolved video stuttering issues at last!

DavidLewis · January 12, 2018 at 2:56 PM

Hi everyone. It's my first post - thank you to the team for maintaining LibreELEC to such a high standard!

I've recently overcome a long-standing issue I've had with Kodi on Raspberry Pi 3, so I thought I'd post in the hope that it's helpful to other people. It's quite a long post containing all the details, so that hopefully it will be picked up successfully by people searching with similar issues...

I've been running Kodi on RPi for years - first using XBMC on an original Pi1 Model B, then using OSMC on that Pi. Then I changed to a Pi3 using OSMC (Kodi 16 at that time) then i changed to LibreELEC (still on Kodi 16) and now I'm fully up-to-date on Kodi 17. Throughout that time, I have been through a number of TVs and AV Receivers, and I have amassed experiences and settings that I have often carried forward to the newer version. Examples are:

Choice of skin - I always used Amber due to it being recommended as lightweight and suitable for the low-powered original Pi1.
Remote control settings (key mappings, LIRC config, etc.) - I've always used a homemade GPIO IR receiver and a Harmony remote, which originally seemed to need much tweaking to make it work reliably.
Setting up NFS file shares - NFS was supposedly faster than SMB on the low-powered Pi1.
Various HDMI-related settings in the config.txt file

It's that last item I want to share in more detail. I have always left the Pi powered on 24/7, but not the TV. The Pi1 running XBMC seemed to have a problem detecting that my TV had been turned on, so I ended up with a slew of HDMI configuration lines in config,txt, including HDMI_FORCE_HOTPLUG. This successfully fixed that problem.

When I bought a new Sony AV receiver (with HDMI ports!) I realised that the video was a bit jerky / stuttery when watching some files. By that time I was running OSMC on a Pi3. After many hours of reading, investigations, and help from the guys in the OSMC forum I fixed that behaviour by using HDMI_EDID_FILE to use an edid.dat file that I created when my TV was connected *directly* to the Pi3, not through the AV receiver. It turned out that the EDID information passed to the Pi through the receiver was different to that passed directly from the TV, with the result that the Pi was preferring an interlaced (1080i) video mode, which caused noticeable stuttering in panning scenes. Even after this fix, MMAL acceleration was never able to play stutter-free video for me, so I had to use OMXplayer even though MMAL was the recommended option for the Pi3. I never got to the bottom of that one.

I recently bought an Optoma 1080p projector which I connected to an active HDMI splitter between the AV receiver's single HDMI output and the TV. This worked well, except that the projector takes a few seconds to sync with any frame rate change, during which it displays only a swirling pattern of dots. This is rather distracting, and for some reason the projector attempted an annoying re-sync often during movies - even when there was a sudden scene change during the action. I did some more investigation (spent many hours researching and experimenting), changed some more HDMI settings, and created and compared some more EDID files (from the TV, the receiver, the projector, and all combinations of those connected with and without the HDMI splitter). I couldn't find anything obviously amiss, and the swirling circles kept appearing. Disappointing

So then I decided to start again from scratch. I did a totally clean install of LibreELEC on a blank SD card. I stuck with the Estuary skin, the default remote key mappings, pointed to my libraries on SMB shares, and didn't bother with any (well, not many) lines in config.txt - not even HDMI_FORCE_HOTPLUG and certainly no EDID files. And I'm pleased and amazed to report that the whole system works *perfectly* now! There is no video stuttering, I'm using MMAL acceleration (the default), the picture always appears when I turn on the TV and / or projector, etc.

I guess the bottom line is that Kodi on the Raspberry Pi has been improved so much over the years that many of the detail workarounds and configuration changes that used to be necessary are no longer required. And those of us who have carried over our hard-discovered settings are, by now, maybe doing ourselves no favours by continuing to use them. So if you are having (or have always had) problems similar to mine, I would recommend finding a spare SD card and trying out a completely clean default installation. I should have done that a long time ago

Thanks for reading this far, and if you're a developer or contributor: well done and thanks again

David

zksHGItCVxPBhrEx7B9x · February 22, 2019 at 8:54 PM

Interestingly I also had many problems of comparable severity as the OP's. Even frequent crashes/hangups. Wifi refusing to connect. After restoring from a manual SD-Card backup I had made when I first installed LibreElec 9, almost all problems suddenly have disappeared, and I can also say "the whole system works perfectly now" (Amazon Music being the only exception).

I didn't do much to reach the "f*cked-up" state. Just create advancedsettings.xml with the well-known type of cache settings (because Amazon Music only plays with stutter). And I also changed these settings back and forth, to see if it's them who make problems, but to no avail. In my opinion it is not plausible that these settings caused the problems. But nonetheless the problems appeared only after several weeks of usage. So if LibreElec does not "modify itself" (I have turned automatic updates off for exactly these kinds of insecurities), it must be the hardware that has deteriorated. But why did it work then after restoring the original software state?

Maybe one crash caused filesystem corruption (thus causing all subsequent crashes?), but that is hard to believe to me. Even on Windows I have hardly ever experienced true FS corruption. And I have had *many* Windows crashes in my life...

What I did for restoring the backup, however, was using a brand-new SD card. I have the suspicion that it might have been the card. These cards sometimes get pretty hot and inside my Pi's housing this might have caused damage to the card itself (on the CPU I have a big heat sink of course). Maybe not damage in the sense of actually corrupting data, but rather something like much longer response times and such. Who knows.

Yes, a lot of speculation, but like the OP I wish that anyone is saved a little time when solving these kinds of issues.

FeFiFoFum · March 29, 2019 at 5:50 AM

Thanks for this post, I'll be trying this tonight myself.

Hopefully it behaves well at just 1080p.