After trying pretty much everything else (replacing the power supply for example), I eventually replaced the Raspberry Pi, and voila, everything works nicely. It looks a lot like this was indeed a hardware issue. I still don't know what exactly is broken since the hardware worked flawlessly with version 9.x. But I'm a happy user of version 10.0.1 with the new Raspberry Pi 4B board now. Thanks for your patience and support.
Posts by svenfoo
-
-
Can you give me any advice on how to proceed? Could the decoding artifacts be caused by under-voltage? I'd go ahead and order a replacement power supply then, but is there any chance that this will actually fix the problems that I described?
-
Quote
When the video is corrupt, and you bring up OSD, is that clean, or have corruption?
The OSD is clean. I can see that the video below is corrupted, but the overlay is rendered cleanly.
-
That may not prove anything. Most notebooks' USB-C power supplies only provide limited power at 5V. They use the smart capability of USB-C to change voltage and may then switch up to much higher voltage and current. I don't think that the Pi does this smart voltage changing, and so it might still be constrained by limited power availability unless the 5V capability of your other supply at least matches that of the Pi power supply. Certainly your screens shots suggest a hardware or power related issue.
You are right. According to the specs the Lenovo USB-C power supply only provides 2A at 5V. My USB-C 130W powerbank specifies 3A/5V so I tried that today, but the problem doesn't go away. I am perfectly willing to accept that it's an issue with the power supply. However the fact that the same hardware on the same power supply doesn't show any such issues running LE 9.2.x makes me wonder if it can possibly be a hardware problem.
-
This feels like a hardware issue. Did HW h.264 decode on that board work with LE9/Kodi 18?
Just swapped the SD card to go back to LE 9.2.6 and played the same movie. The info display says the decoder in use is ff-h264-mmal (HW). That means it's using the hardware decoder, doesn't it?
-
Thanks for pointing me to vcgencmd.
Code# vcgencmd get_config over_voltage over_voltage=2So that seems to have been picked up correctly. And unfortunately it doesn't solve the problem.
-
Eventually cashed out a few bucks for a small mixer with USB sound card (Behringer Xenyx 302USB) Now I can connect several devices to my active speakers without fiddling with cables and the audio quality from the Raspberry Pi is so much better.
Thanks again for pointing out that the audio quality of the analog jack is limited and that there's not much that can be done about it other than avoiding to use it.
-
Quote
Your link is wrong, but if you are saying it fails with standard big_buck_bunny_1080p_h264.mov then that is a file that is tested regularly and plays fine.
I am sorry, I don't know how I managed to mess up the link. The link should work again now, I edited the post. But yes, it's the standard file.
QuoteCan you try adding "over_voltage=2" to config.txt on boot partition and test again?
Tried that, and it doesn't seem to make a difference. I've verified that /flash/config.txt has the entry. Can I somehow verify that it is being picked up by the boot-loader? Couldn't find CPU voltage under /sys.
To rule out problems with the power supply, I replaced the 3A USB C power supply with the USB C charger from my notebook. Doesn't make any difference either.
-
Sure. I copied "Big Buck Bunny" to the SD card. That movie has less artifacts than most other H264 encoded movies I tried. It doesn't make any difference though if it's played from SD card or from a network share. The artifacts appear at the very same frames, it's all very reproducible. The first artefacts appear about 10 seconds into the movie. The scene with the bird starting at 0:16 is rendered cleanly again, the next scene switch at 0:23 starts with artifacts. I've taken the attached picture at around 0:26:
I've uploaded the first minute of the file here, of course after verifying that the cut version shows the artefacts as well:
-
I've been using LibreElec / Kodi on a Raspberry Pi 4 for quite a while now, and of course I am looking forward to the upcoming 10.0 release. Today I tried 10.0 Beta 3, using a fresh SD card as recommended in the release notes. Everything worked nicely, the user interface is rendered smoothly and system information shows that the CPU load is minimal, looks even better than with 9.2.x.
However there's a problem with playback of H264 video. I've also tried mpeg4, that seems to work fine. But any H264 encoded movie, or stream (I tried Vimeo), comes out totally garbled. In some films some i-frames seem to render okay, but most of the time the picture is so garbled that it's almost inconceivable. Here's an example picture, most of the time it looks even worse:
The Raspberry Pi is attached via HDMI to a projector with 1080p resolution. Needless to say that the same movies and streams play back nicely using the 9.2.x release.
I've attached a debug log and the kernel output, let me know if any other details are needed:
-
Well, it really happens with all the files I tried and I tried a few different formats. Same with any Video add-ons I tried (Vimeo, for example). What would be the appropriate forum, "General Support" ?
-
Tried the 10.0 Beta 3 on Raspberry Pi 4, using a fresh installation as recommended in the release notes. Looks good at first sight, but any video will come out garbled. I can basically see the decoder tiles. I understand that RPI4 support is considered alpha, but is it expected that video playback is completely broken or am I just missing a setting, a firmware update, anything else to fix video playback?
In case you are wondering, the hardware is fine, it works nicely with 9.2.x.
-
Thanks for the advice. The HiFiBerry audio HAT has some nice features, in particular it promises a higher volume level. However I'd also have to get a new case then to make it fit, which makes it quite an investment.
Found some documentation of the config.txt parameters and it suggests audio_pwm_mode=2 to improve the sound quality and to reduce hissing. Will give that a try before investing into more hardware.
-
What are you suggesting to use then for audio output if not the jack output? I have connected a projector over HDMI and it only has a tiny speaker. From the location of the projector I can't easily get the audio to the speakers. The audio jack has worked nicely for me so far, what would be an alternative?
-
Are there any differences in the other log file in terms of installed add-ons? Or is this just one of those runs that go bad?
No differences whatsoever. The second log is taken from the same installation, just a few minutes later. As I said this seems to happen randomly, maybe in one out of two or three boot attempts.
-
A clean installation should not have that happen. Something you installed must be hard at work int the background.
Provide your kodi.log file so we can have a starting peek.
Here's a log from a good run, CPU load on the idle system is around 30%
Here's a log from a bad run, the load stays around 130% and the menus are sluggish even:
Both logs uploaded using the logfile uploader add-on.
-
Does this always happen or do you only experience this occasionally? I am making similar experiences, also running LibreElec 9.2.x on a Pi4. Menus are slow to open, everything is lagging. When this occurs the kodi process is constantly consuming about 130% CPU time, even on an idle menu screen with no video playback. This can then be fixed with a reboot. The chance of running into this problem after boot is about 50%, so it usually takes one, two or even three reboot attempts to solve it. When the load settles to about 20% to 30% after the reboot, then everything is fine and will stay fine, until the next reboot ...
-
I can confirm that ScummVM add-on version 2.0.0.6.1 from the libreto repository does not start on the Raspberry 4.
There's a linker error when trying to launch the add-on:
Codegame.libretro.scummvm.so: undefined symbol: _ZN3 GUI13OptionsDialog5cleanEv
