Nightly images for A64, H3, H5, H6 and R40 boards

  • You mean from the same site nightly images can be downloaded? Yes, they should work (in your case ARMv7), but I never tested. Building on your own is always an option.

  • Note that repo might have a slightly older versions of addons. iptv.simple was recently updated, so even if it is in repo, check version and compare it to that from nightly image download page.

  • Note that repo might have a slightly older versions of addons. iptv.simple was recently updated, so even if it is in repo, check version and compare it to that from nightly image download page.

    I have compared it and current versions on the nightly image download page and in repo are both 7.6.0.1. So, should the current nightly image LibreELEC-H3.arm-10.0-nightly-20210412-142b163-orangepi-plus2e.img see it in repo? I can see it my current system...

  • Hi Jernej! I have formatted the SD card and installed fresh LibreELEC-H3.arm-10.0-nightly-20210412-142b163-orangepi-plus2e.img and latest PVR Simple client v.7.6.0.1 from repo as you suggested. Even though the performance (menu navigating) became even better, the bug still persists. 😢


    Again I can replicate it easily. I have to start playing any HD orig channel and then turn on GUI menu and start navigating in it fast (while the channel's video playback is at the background). The best way to cause this issue is to just start scrolling the channels list up, or down.

    First it cause's video playback image corruption (see attachment) then, when I stop the channel and then I turn on any HD (even not orig) channel the video playback would lag. Only reboot would restore playback to normal.

    What do you mean without compression? I can't imagine uncompressed full HD - bitrate would be enormous.

    I have chatted with my IPTV provider support and they say these HD orig channels are really without compression. If you need minimum 3-5 Mbits connection for usual HD (25-30 FPS) and FHD (50 FPS) channels, for HD orig you need about 20-30 Mbits. I have stable 51 Mbits connection. May I send you a generated link again with pastekodi after I have reinstalled the Kodi? Perhaps, you can find there new key for solution? Or maybe I have to try how it works from eMMC? But I remember my board worked worse on eMMC, rather then from SD card...


    Many thanks for your support!

  • levitsky86 pastekodi should generate URL - that should be enough. Script already uploads logs for you. What do you mean without compression? I can't imagine uncompressed full HD - bitrate would be enormous.


    Timpanogos Slim I found and fixed HEVC problems here: Allwinner: Fix HEVC decoding by jernejsk · Pull Request #5312 · LibreELEC/LibreELEC.tv · GitHub

    OK, i might have time for testing again soon. Been busy for the last couple weeks.

  • levitsky86 Can you confirm that streams use H264 codec (press "o" during playback)? If it possible, try seeking for few seconds back or forward. I have one H264 sample with broken frame which cause similar issue and picture is fixed only when seeking back or forward...


    Timpanogos Slim No worries.

  • Can you confirm that streams use H264 codec (press "o" during playback)? If it possible, try seeking for few seconds back or forward. I have one H264 sample with broken frame which cause similar issue and picture is fixed only when seeking back or forward...

    Thanks for your feedback, Jernej! Yes, I confirm all of my IPTV channels (HD, FHD, HD orig) use H264 codec. I have just checked that (pressed "i" that turns on info panel). Interesting thing is that seeking back, or forward causes this issue instead of being fixed! The video starts to either lag, or to produce corrupted image (as above). The solve method is to stop playing and then turn this channel on again. If this doesn't help, the reboot is the only way...

  • Jernej, I have installed your update, turned on debug logging and run dmesg through SSH, but I've got only multiple strings like these:


    [ 375.661840] timestamp is corrupted for references!

    [ 375.661845] timestamp is corrupted for references!

    [ 375.694128] timestamp is corrupted!

    [ 375.694205] timestamp is corrupted for references!

    [ 375.701908] timestamp is corrupted!

    [ 375.734150] timestamp is corrupted!

    [ 375.742902] timestamp is corrupted!

    [ 375.774053] timestamp is corrupted!

    [ 375.780702] timestamp is corrupted!

    [ 375.780716] timestamp is corrupted!

    [ 375.780766] timestamp is corrupted for references!

    [ 375.780771] timestamp is corrupted for references!

    [ 375.813840] timestamp is corrupted!

    [ 375.813925] timestamp is corrupted for references!

    [ 375.819440] timestamp is corrupted!

    [ 375.819495] timestamp is corrupted for references!

    [ 375.819500] timestamp is corrupted for references!

    [ 375.853835] timestamp is corrupted!

    [ 375.853913] timestamp is corrupted for references!

    [ 375.859572] timestamp is corrupted!

    [ 375.894088] timestamp is corrupted!

    [ 375.900549] timestamp is corrupted!


    Have I done something wrong?

  • Have I done something wrong?

    Nope, exactly what I was looking for. Same issue as I have with my corrupted sample. Problem is that I'm not sure how to fix it. Today I tried few things with my sample but none worked.

  • Understood. I don't know weather it can help, but as I mentioned above this thing appear when I start to scroll the channels list fast while the video playback is at the background, first I notice some lags and then even this image corruption appears. If I scroll channels list easily (one by one, or only 3-5 channels) this doesn't happen.


    In other words it's very like as the hardware is not capable to hold that stress load during such moments...

  • In other words it's very like as the hardware is not capable to hold that stress load during such moments...

    Nope, that's not it. In short, driver is fed by invalid data, which cause instability. Why invalid data is sent is another story, but anyway, driver should react properly on such frames. Fixing that is not straightforward due to some HW quirks. Be patient, it's my intention to solve it, but I can't give you any timeline.

  • I see, Jernej! Thanks for your time and support! Please explain wether I can continue to install nightly updates on that image you made with some output, or should I better format and do a clean install?

  • Monoscopic mode not working? Although I select it, it has no effect.

    Orange Pi PC LibreELEC-H3.arm-10.0-nightly-20210416-8f3d105

  • Please explain wether I can continue to install nightly updates on that image you made with some output, or should I better format and do a clean install?

    The only difference between my test image and nightly from that day are just two lines of debug output. You can treat them same. Clean install is recommended every now and then, when bootloader is updated.


    Monoscopic mode not working? Although I select it, it has no effect.

    I'm not even sure what it does. Something with 3D mode? If so, that's completely untested and unlikely it will get better anytime soon. I have no 3D display nor do I plan to obtain it.