Do you have any ETA when deinterlacing will be implemented?
No, because driver is not implemented and DRMPRIME Kodi render doesn't support deinterlacing yet. I would say not so soon.
Posts by jernej
-
-
riku lumpi another LE developer helped fix IR keymap persistence over reboots. It turns out that 4.20 kernel changed udev behaviour a bit. Now IR configuration should work just as described in LE tutorial.
Lirc driver is included, yes.
AA666 I can include first patch (do you plan to send it to Linux?) but I don't like to merge second one. Reason is that Pine64 doesn't have IR soldered. This is job for DT overlay, which can be done with dtoverlay and configfs functionality included in kernel, but I can't give you any tutorial at this time.
roel I uploaded libretech_h3 image.
-
I just uploaded new update with following improvements:
- included repository with PVR and other plugins
- H265 decoding improvements
- IR fixups (persistence over reboots, Kodi detection)
- Beelink X2 permanent MAC address
- included USB DVB drivers
-
just one short question, what was now the problem? how did you fix it?
I noticed that eventlircd doesn't start due to missing uinput device. I enabled it in kernel config.
my test procedure:
1. Set up my mobile phone to act as a Xbox remote.
2. execute following command through ssh:
Codeir-keytable -c -w /usr/lib/udev/rc_keymaps/xbox_3603. tested buttons up, down, etc. in Kodi
Above worked on internal IR.
-
same message in log, no luck with irw and Kodi GUI
Test this: libreelec-h3.arm-9.1-devel-20181227000522-86dd2d6.tar I found the issue and it works for me now. I guess I'll post new updates tomorrow due to many issues solved.
-
riku Don't worry, I'm just glad that we pinpointed the issue (hardware). Is your secondary H3 board also OrangePi PC? As I wrote before, I have plenty of different H3 boards (but no OPi PC) and CEC doesn't work on all of them (tested on same TV and kernel). I suspect that HW designers didn't test that and it may or may not work.
-
Dont ruin your christmas over the IR issue, for the moment a mouse on a too short wire has to solve the immediate need for control
Don't worry, if I don't feel like solving problems I won't. But currently I want to tackle them
Please try this update: libreelec-h3.arm-9.1-devel-20181226213819-4693356.tarI enabled LIRC interface in kernel. Maybe this will solve it.
-
i have noticed however this odd error on startup "bad crc while load from fat" it anyways work the /storage without any problems from fat... ??!?! look picture
That's normal. That just means that U-Boot will use default settings which is exactly what is wanted. If you would save U-Boot environment, this message wouldn't appear. Granted, it's more scary than it should be. It should be something like "Using default envitonment"...
Can you test with another H3 board?
lumpi I tried another thing for IP address changes. Please update with this: libreelec-h3.arm-9.1-devel-20181226203321-a85ff24-beelink_x2.tar
I'll check IR settings again, maybe I missed something.
-
Orange pi pc
There is a lot of information search in google orange pi pc s/pdif output
Sorry to disappoint you, but unless you edit DTB file yourself that won't be supported. DT overlays aren't supported currently, but maybe something can be done with configfs on linux if you want to play with it. DTB files are overwritten during LE update.
-
jack82 which board? Currently it's supported only with Beelink X2.
-
Ok, that is very strange. Can you burn clean image and do this before first boot? Just to rule out any issues with saved settings.
-
if you can yes, i can change kernel if needed but i need the atm using one, and point to some guide how to compile it for libreelec i can try it out and mess with code
To force fixed resolution, you just have to edit one text file, nothing more:
1. Insert your LibreELEC SD card into PC and open FAT32 partition
2. open extlinux/extlinux.conf file for editing
3. Append "drm.edid_firmware=edid/1920x1080.bin" to the line which starts with "APPEND"
4. save the file
-
lumpi Can you test this update: libreelec-h3.arm-9.1-devel-20181226132840-f58e089-beelink_x2.tar
MAC shouldn't change anymore after reboots.
-
jernej is there any way i can help you on this, what logfiles need etc, how i debug it?
on older release(kodi16) it works, so there is something about this now.
Big difference with old OpenELEC port and this one is kernel. Here is mainline kernel which reads EDID and adjust resolution accordingly. If it can't read it, 1024x768 is used as safe fallback (that is hardcoded in kernel). Old BSP kernel (3.4) didn't use EDID at all, it used predefined resolution from fex file. But that caused more issues than it solved. Not all people have board connected to 1080p display.
I really don't want to go with old path and predefined resolutions because current solution works 99% of the time. However, I can give you instructions how to tell kernel to use 1080p no matter what EDID indicates.
BTW, OrangePi PC doesn't have ESD protection on HDMI port. Is there a possibility that electrostatic discharge happened on HDMI connector? I saw destroyed HDMI port on OrangePi Plus that way before.
-
No, not really. Which board you said you have? I just tested my OrangePi Plus2e on Panasonic plasma TV (1080p) and it works as expected.
-
i might just go with opipc internal ir, i think it can put on work, but it involves getting whole distribution recompiled to get proper libs installed..
Why do you think so? I tested IR few days back and button presses were recognized correctly.
-
besides things like missing dvb/wlan drivers and repos, but that's known
I didn't dive into kernel config yet. If there is some USB driver which you would like to be enabled, just say so (but it must be included in kernel already).
plus the mac keeps on changing...
That is easy, one line fix which will be included in next update, but since I don't have that board, you'll have to confirm if it works.
CEC seems to be a bit fragile
That's true. Be aware that Allwinner never officially supported HDMI CEC on H3. I noticed that CEC on same kernel worked with one board but not another during tests. Possible explanation could be that because there was no official support for it, HW designers couldn't test it and it may not work. Even worse, CEC pin could be unconnected or connected to GPIO for software simulation of CEC protocol.
Looking at build/beelinkx2.fex at master · armbian/build · GitHub I would say that board has CEC pin connected to GPIO port. Bad news is that CEC won't work for you for now. Good news is that kernel contains code for simulating CEC over GPIO, but I have no idea how to use that in universal way (not to break other images).
The remote I couldn't get to work with lirc
Take a look at this tutorial: Infrared Remotes [LibreELEC.wiki]
-
riku can you test this image: libreelec-h3.arm-9.1-devel-20181225182605-cdd7be0.tar ?
It has potential fixes for tearing (if it really is) and EDID. Other than that, I don't really know what could it fix it. If tearing persists, please upload sample video which demonstrates the problem.
