LibreELEC crashes in the middle of the 4k movie on Raspberry Pi4

  • (I'm not challenging your testing chops, I'm asking about video encoding.) If I were testing an XML reader, I know a half-dozen things I could do to poke a stick between the spokes and make it invalid/illegal to trip up a parser. Is it possible to create a set of bogus movie files that are syntactically invalid in interesting ways to incorporate them into a test suite?

  • On average, three quarters of a software program is already expected to making that application 'foolproof'. You can do only so much, and a 100% bugfree application will never happen. Kodi uses a 3rd party tool ffmpeg for decoding videos. Team Kodi didn't create it, but we use it because it helps us play Kodi on just about every electronic gadget there is. There isn't much else to choose AFAIK.

    Dear Klojum

    Thank you for this comment. Now let me try to talk seriousely.

    First of all, let's split in the context of the conversation between:

    1. dealing with content bugs

    2. errors in the sw code itself

    Now, lets talk about it.

    1. Dealing with content bugs.

    Yes, the majority of the code of any program is dealing with exceptions. That's why when you mentioned that "KODI follows the books" I was not impressed. The reliable software has to overcome issues. Let me give you an example. Once I was in the car navigation cartography. And we were testing a new system from BMW/Siemens. At one crossing (where it was supposed just to drive straight) it kept on telling "please turn left and then turn right". It was really a puzzle. The crossing was just a cross! We struggled for several days until our chief engineer decided to zoom to the level of 1:1, literally. ANd then he saw that the cross was not a cross: two roads were connected like the Z letter, and its size was less than 1mm in real life! So small!!! But of course for this system it was a "turn left and then (1mm later) turn right", as it followed the books.

    We tested it on all other navi systems and they did not even notice it. Not because they were stupid, but because they were on the market for many years and they were smart.

    Sorry, currupted files happen. Not only because of Russians, but also – as we found with you – because of HDD (although I never have seen it myself).

    You have to cope with it. You have to mature the system. It's not the question of punishing those who happen to get some russian-made video, its just the question when you do it.

    2. Errors in KODI itself

    In my case the Raspberry crashes on this corrupted file and the OS reboots.

    Whatever happens with the tool you use, It's YOUR OS which crashes.

    Sorry, this is your bug, which you have to repair.

    I hope I explained my two points. But if not, I am here to comment further.

  • 1) I'm not a Kodi developer, so whatever is (im)possible in terms of error-skipping voodoo I can't tell you. The ffmpeg boys might have a clue.

    2) "Our" OS... is a standard vanilla Linux kernel with just a couple of bells and whistles to run Kodi. Why it is tripping so heavily in your case, I have no clue at this time. I cannot recreate the problem/bug here no matter how many times I play a 4K video.

    For now I've seen only 1 debug log file, and a couple of "metoo" posts. The more log files we have, the more we can perhaps pinpoint the issue.

  • Actually it's not the OS crashing and rebooting, it's kodi crashing and the OS (LibreELEC) automatically restarting it.

    And while I agree that an application crash isn't the nicest way to handle a corrupted file there's not much we can do about it ATM. So far we only know that it's crashing with some (probably not quite legal) file and maybe with some unknown kodi samples.

    So, to be able to move forward with this we need a sample file so we can reproduce and analyze the issue.

    so long,

    Hias

  • I resolved the issue: I've just recompiled the file from the original disk, and now it works.

    It was nice talking to you, thank you! Looks like you guys are happy with how your sw works, and I cannot do much about it. It was my first interaction with an open source project, sorry if I couldn't manage my expectations.

  • i think your issue is the pi is underpowered.

    Under powered RPIs will show a yellow bolt in the top right corner. I don't think that is the case.

    I resolved the issue: I've just recompiled the file from the original disk, and now it works.

    'Recompiled' as in copied it again from a Bluray disc? Okay. I'm glad it all now works.

    Looks like you guys are happy with how your sw works, and I cannot do much about it. It was my first interaction with an open source project, sorry if I couldn't manage my expectations.

    We are happy with the basics, Kodi itself is already some 15 yrs old. But it can always be improved and extended. Open source software via f.e. Github offers any programmer to add to the application. Those additions and/or changes will be reviewed and added when accepted.

  • We are happy with the basics, Kodi itself is already some 15 yrs old.

    15 years! Well, then I would expect something usable... Pity. Yesterday I got into another issue which will probably put an end in my usage of KODI: the quality of video on 4k is terribly low. It's not b/w yet, but a kind of greyish. Pity, I liked the idea of KODI, but what is the point in the great organization capacity of KODI, if it simply cannot show a movie!?
    I am really sorry for this project. As a real user who does not want to code himself and who loved the idea of KODI, I installed the Pi4, and I expected it to work. It does not. The quality issue really made me sick.
    15 years...unbelievable...

  • As far as I can tell the issue is not happening on the LE Virtual image when testing in a VM. I'm assuming some hardware-specific behavior. I was able to reproduce the behavior on my Odroid N2 with CE though. I already posted in a related thread on the CE forums: Chapter skip on 4k Remux causes Kodi crash - Kodi - CoreELEC Forums .

    We are happy with the basics, Kodi itself is already some 15 yrs old.

    I don't see this as a valid statement. This has nothing to do with being sophisticated or an extension. Supporting some specific device, providing some picture mode or something similar can be considered a "feature". Not crashing when fed with some 4K movie that should follow a specific specification, albeit deviating for like one frame is not. That's just error correction in a way that has existed for decades.

    Even the first CD players on the market had to implement some ECC (error correcting codes) algorithms because if you had a little dirt on your disc it would not be a "self-inflicted corner case that is far too uncommon to be handled". It's just that digital data is far from error-free, that you even said yourself.

    Nonetheless, I really appreciate the project and I don't want to make it seem rude if it's not fixed right away. But I will be happy to help in resolving the issue if I can help and I expect nothing more but the developers to look into it sometime appropriate. Bugs are reported so they can be fixed, so more people are happy about the product, which is nice for everyone I guess.

    Not fixing them doesn't add anything to it.

    Yesterday I got into another issue which will probably put an end in my usage of KODI: the quality of video on 4k is terribly low. It's not b/w yet, but a kind of greyish. Pity, I liked the idea of KODI, but what is the point in the great organization capacity of KODI, if it simply cannot show a movie!?

    What do you mean? I request you stay serious and objective so we can find out what the issue is and perhaps it's just some configuration issue. I have yet to compare my Kodi playback with Blu-Ray Player footage.

    By the way, as some seem to make that assumption, bare downloading, possessing and even copying movies is legally unproblematic in some jurisdictions like Switzerland if you do this within a closed circle of friends. So it should not be an argument against fixing bugs (or exceptions/ unexpected behavior) either.

  • This video freezes my KODI and RPI4, sometimes the entire system reboots:

    jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv

    It is referenced here in KODI wiki.

    The last log file lines on the terminal screen during freeze:

    2019-12-11 22:48:23.901 T:3011290448 DEBUG: Previous line repeats 3 times.

    2019-12-11 22:48:23.901 T:3011290448 DEBUG: CMMALRenderer::RenderUpdate - vsync 15810 (+1)

    2019-12-11 22:48:23.928 T:2627339120 DEBUG: ffmpeg[9C9A0370]: [hevc] av_rpi_zc_ref: *** Not one of our buffers: NULL

    2019-12-11 22:48:23.968 T:3011290448 DEBUG: Previous line repeats 4 times.

    2019-12-11 22:48:23.968 T:3011290448 DEBUG: CMMALRenderer::RenderUpdate - vsync 15814 (+1)

    2019-12-11 22:48:24.003 T:2627339120 DEBUG: ffmpeg[9C9A0370]: [hevc] av_rpi_zc_ref: *** Not one of our buffers: NULL

    2019-12-11 22:48:24.233 T:3011290448 DEBUG: Previous line repeats 17 times.

    2019-12-11 22:48:24.233 T:3011290448 DEBUG: CMMALRenderer::RenderUpdate - vsync 15830 (+1)

    2019-12-11 22:48:24.292 T:2627339120 DEBUG: ffmpeg[9C9A0370]: [hevc] av_rpi_zc_ref: *** Not one of our buffers: NULL

    2019-12-11 22:48:24.423 T:3011290448 DEBUG: Previous line repeats 8 times.

    2019-12-11 22:48:24.423 T:3011290448 DEBUG: CMMALRenderer::RenderUpdate - vsync 15840 (+2)

    2019-12-11 22:48:24.438 T:2627339120 DEBUG: ffmpeg[9C9A0370]: [hevc] av_rpi_zc_ref: *** Not one of our buffers: NULL

  • I could not reproduce the crash on my Odroid N2 with your footage. Are your sure you're experiencing the same issue?

    Also, I don't see any error lines there, just verbose output. Do you have a full crash log?

    Is this the only file that crashes on your system that is publicly available?

  • What do you mean? I request you stay serious and objective so we can find out what the issue is and perhaps it's just some configuration issue. I have yet to compare my Kodi playback with Blu-Ray Player footage.

    I have asked it in a separate discussion alsready. People say that its because I use 4k HDR and KODI does not support it...
    So, it's nothing we can do now.
    It means that the KODI becamse just a nice administrative system for me, but I have to watch thevideo via my TV's player, which apparently supports this HDR...

  • I think it's more like a freeze than a crash. The RPI4 becomes so "slow", that you are not able to interact with it. You can't use the KODI UI, and you can't use the terminal to issue a command either. And after some time the system reboots. It seems to me, that it's the problem of the underlying OS and RPI4 HW.

    I will carry out more test on the weekend, and will try to find other 4K H265 video files to reproduce the problem.

  • I'm having the same problem om my RPI4 4GB system. I'm using the jellyfish sample: Jellyfish Bitrate Test Files as linked to in the Kodi wiki. That sample is stored on a WD Elements 4TB HDD, connected to the rpi4 via one of the USB 3.0 ports. There is one other USB2.0 port occupied with a Logitech unifying receiver.

    ---------

    Update:

    New log where I waited for a long time before issuing a reboot command:

    Paste.ee - View paste 4kKTs

    Note that I could not use pastebin since the log is too large.

    Screen goes blank but Kodi seems to keep on running.

    Actions:

    • Browsed to movies, selected the jellyfish movie
    • Upon starting, the screen went blank immediately around this moment: 2019-12-28 14:37:37.116 T:2530202480 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
    • The log kept on going, so the Kodi was still up
    • Waited for a moment, and then pressed the 'stop' button on my TV remote, which is connected via CEC to the Kodi. The log shows it recognized the stop button and the video stopped playing!

    The screen remained black however, and the kodi web interface was unresponsive. I did issue a reboot command from SSH. It took a while but eventually the system rebooted. I think it is very strange that CEC seemed to keep on working, but no video output was sent to my TV. Checked the temperature using /opt/vc/bin/vcgencmd measure_temp but nothing strange came up (running steadily at 47 degrees Celsius.

    ---------

    Previous log

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Note that the screen went blank here:

    2019-12-28 14:01:30.523 T:2564035440 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

    After that I issued a shut down command from the kodi web interface, so I guess the last lines do not really matter a lot.

    Edited 4 times, last by charliemka: Added HDD explanation (December 28, 2019 at 4:07 PM).

  • update: solved

    Ok, the dmesg output helped in troubleshooting the issue. For me h265 plays smoothly after setting the following parameters in config.txt:

    config_hdmi_bo ost=8
    force_turbo=1

    gpu_mem=512

    (remove the space in bo ost, it’s a censored word...)

    Perhaps not all three settings are required, but at least force_turbo must be set to 1. Got the solution From a post here: [Guide] Kodi on Raspbian Buster - Page 6 - Raspberry Pi Forums


    ———-

    Original reply:

    increased gpu_mem to 512. It seemed to go better, but eventually Kodi started hanging again. I did notice the following in dmesg right after the screen went blank:

    [ 116.700030] [vc_sm_ioctl_alloc]: failed to allocate memory on videocore (status: 0, trans_id: 53)

    [ 116.700050] [vc_sm_ioctl_alloc]: failed to allocate "CGPUMEM" data (-12) - type 1, base 17121280 (17121280), num 1, alignment 4096

    Edited 2 times, last by charliemka: Solution (December 29, 2019 at 10:12 AM).

  • Hi,


    Setting force_turbo=1 helped a bit, it solved the out of sync audio problem with some hevc movies.


    The gpu_mem=512 crashed the hevc movie playback with every movie I tried, so I reverted back to 320.


    I have carried out extensive tests with different downloaded hevc movies and with the Big Buck Bunny test video converted to hevc with different quality/bitrate settings. Based on the tests I think the RPI4 can play hevc videos smoothly with video bitrates below 80 Mbps, above 80 Mbps the playback stutters. Somewhere above 100 Mbps the RPI4 gets unresponsive and freezes.

    Unfortunately lots of movies are converted/remuxed with parts or the whole movie above 80 Mbps, and the RPI4’s SoC is not capable / not powerful to play them.