Will the H6 get RGB LCD support ?
While in theory should be easy to add, there is no plan to do that. Mostly because no LE developer has such HW. Doing any kind of development without HW is hard and wastes a lot of time.
Posts by jernej
-
-
mike2002 offbeat Thanks! Issue identified: libdrm: update to 2.4.105 by heitbaum · Pull Request #5301 · LibreELEC/LibreELEC.tv · GitHub
Nightly images will be unusable for a few days until issue gets resolved. Decoding works if libdrm is downgraded to 2.4.104, but that's not a proper solution.
-
That is why I was wondering if they will continue to publish tanix nigtly,
Yes, Tanix TX6 nightly images will continue to be published for foreseeable future.
-
Just start with the tanix image from the 21st. Since then, no more nightly have been posted to test?
I just checked and there is today's nightly image.
The image of belkin does not start.
Do you mean Beelink? Most probably your board is too different to that.
Anyway, Q+ is not supported, because no developer has it.
-
Does this setting correspond to every single video playback? I see I have to disable it on every channel separately.
I don't know, to be honest. I just know that I need to fix some corner cases with this functionality...
-
Kristian Test images are updated to beta2. This time I actually test them and they work as well as before.
-
Sorry Jernej, but I can't find it! Which settings menu should I search? I've got "System", "LE", "Player", "PVR"...
Not in general settings, but settings which can be opened during video playback.
-
levitsky86 I know another issue with interlaced content, which probably affects you. Before I fix it, there is no point of providing logs. However, please check if disabling deinterlacing helps in any way. Check in settings menu, right from pause, stop, rewind buttons.
-
mo123 I know there is enough documentation and source code to implement this, but I would need to study how it works. It may or may not be easy to implement, but my focus are Allwinner SoCs, which I know well and although they work pretty well by now, there is still much to improve.
-
There are experimental images (not in LE master branch) for AW, while AFAIK it doesn't work for RK. Both, AW and RK, platforms needs HDMI and I2S driver improvements in order to make it work. HDMI driver is common between these two, but I2S driver is not.
Note that AW experimental images are reportedly broken - I have to update them and re-test.
-
By HD audio you mean passthrough?
-
No, just put it in /storage/.update and reboot - it will be updated during next boot.
-
Now here is no image corruption, but the images freezes. Stop and play channel solves it.
How often freeze happens? Same amount as image corruptions before?
The second time I had frozen not only image but the whole Kodi that had self rebooted after a while.
Please enable debug logs in options and when crash happens, upload crashlog(s) from /storage/.kodi/temp and provide link
-
levitsky86 -=guybrush=- Please test this update: LibreELEC-H3.arm-10.0-devel-20210425125640-5701db2-h264-fix.tar
I think you should not see corruption anymore.
-
Better don't compare it to Rockchip, Amlogic or Allwinner - they needed 4+ years and are partly not even there yet
I tend to disagree (except about AML part)
AW and RK support deinterlacing while RPi does not. RK is also almost on pair regarding HDR. In short, each platform has features that are not necessarily implemented on others. But I agree that RPi development progresses much faster. -
I did exactly as the Official guide says, but the TrueHD and DTS-HD are not working at all.
High bandwith PT won't work - at least two drivers need to be extended and ALSA config must be changed accordingly. I created hackish experimental implementation for Allwinner, but I don't have knowledge about Rockchip internals to do the same for RK.
-
offbeat Thanks for detailed analysis. Enabling performance governor on H6 is not a good idea because H6 generates a lot of heat even on lower frequencies (many are not happy with that). You can of course enable it locally.
There is a reason why Allwinner port is marked as "stable beta" in LE10 release announcements. There is plenty of corner cases which needs to be fixed, but I'm actually quiet happy that it works as well as it does. Decoding using request API in ffmpeg is known to be suboptimal. We didn't rewrite it just yet, because kernel will in near future receive some uAPI updates which would allow even more efficient decoding. As mentioned before, GPU frequency switching doesn't work on H6 for some unknown reason, which nobody can figure out. However, maybe default frequency can be raised same way it is done for A64 (via DT)? This would be acceptable until dynamic switching is figured out.
Note that I don't know for any peripheral which would rely on CPU clock directly. You can always check how clocks are related and configured in /sys/kernel/debug/clk/clk_summary. VPU, DRAM and GPU have their own, dedicated PLLs, which makes them independent from rest of the system.
P.S. Testing it was a pain, the way ffmpeg is packaged in LibreElec is sooo confusing, binary programs aren't included in base build at all and ffmpeg-tools addon uses completely different build options, without any hardware decoding patches...
I actually use separate distro (Arch for ARM) when developing ffmpeg/Cedrus or other, mostly display related features. I apply all relevant LE patches to kernel and then netboot it. This allows much quicker turnaround time. However, I test Kodi only with LE.
-
I have one more question. I see there are settings for buttons repeat time in CEC adaptor. Should they be set to the corresponding brand's TV remote model, or not? I am just trying to figure out why I have problems with CEC on my old Pioneer Kuro plasma TV. I've got multiple CEC100 errors when CEC adaptor (in Kodi) and HDMI control (in TV) are enabled (see the attachment).
It's first time I see this kind of error. But then again, CEC behaves differently on different devices. I have experience only with my LG B8 TV, where CEC behaves normal. Just experiment...
offbeat Reason why OSD helps is probably because EGL provides vsync... I don't know. Maybe windowing/gbm: Add display clock by popcornmix · Pull Request #19601 · xbmc/xbmc · GitHub will help. IDK.
First of all, there is a BIG difference between my scenario and his. I'm not talking about iptv so connection bandwidth isn't an issue for sure. I'm talking about DVB-T broadcasted contents.
That difference is not really important. Check test image I posted and see if dmesg is flooded with same type of lines levitsky86 reported. If it is, stream gets corrupted and decoder for some reason can't cope with such corrupted stream.
Do I need to open the box to physically see the components or can it be done without disassembling? I have ssh access in both.
Opening the box is the easiest way. dmesg output from Android would probably tell what storage is used.
