Of course it's not certain yet (freezing is accidental), but it looks good!
It has only one flaw. This is LE11 and updating or installing LE add-ons fails.
How can I compile LE10 with the necessary changes?
Note: I am able to perform a normal compilation (eg with git checkout 10.0.0).
LuRu I think I found important difference. While it's true that wireless power supply is a mess, really important bit is CPU voltage range. I copied over One Plus values and my OPi3 seems to be much more stable. Please test this update:
That sounds promising!
As soon as I get home today, I'll try it right away. If it's okay, I'll get back to you in a few days. If it's not okay, I'll see it today or tomorrow at the latest.
BTW: I've done some attempts in the meantime (especially on the weekend), but I haven't been successful.
I have made considerable progress !
It was like this: At first I made one desperate attempt. I took a new SD card and wrote the LE image for the Orange Pi One Plus on it.
I inserted the card into the Orange Pi 3 and turned on the power. LE and Kodi started normally. I made some settings and installed (among other things) the PVR IPTV Simple Client add-on and my IPTV add-on. I used it for a few days, waiting for a total freeze to occur again. It didn't happen!
So it looks like the freeze problem is probably related to either USB3 or WiFi / BT. To rule out at least one of these, I decided to run at least USB3 (the absence of USB3 bothered me much more than the absence of WiFi and BT). So I found the source file sun50i-h6-orangepi-one-plus.dts and tried to compile it into sun50i-h6-orangepi-one-plus.dtb. But I couldn't. I was still getting the error message "FATAL ERROR: Unable to parse input tree".
So I did it differently. I took the sun50i-h6-orangepi-one-plus.dtb file located in the /flash folder and converted it to the sun50i-h6-orangepi-one-plus.dts file. There I enabled USB3 and did the conversion back to sun50i-h6-orangepi-one-plus.dtb.
I replaced the original file in the /flash folder and turned on the device. It worked - USB3 started working.
I used the device with the modified DT file again for a few days - it never froze!
Then I took the next step. I returned to the original SD card I had earlier in Orange Pi 3. There I replaced the original sun50i-h6-orangepi-3.dtb file with the modified sun50i-h6-orangepi-one-plus.dtb file. After switching on the device, the expected is confirmed: no total freezing.
Result: It seems that the total freezing of the Orange Pi 3 is related to either WiFi or BT. However, it is not enough if I use the original file sun50i-h6-orangepi-3.dtb and disable WiFi and BT in the settings of the LibreELEC add-on.
How do I proceed to find the real cause of the freeze?
Note: I'm still talking about "total freezing". So I say a state where the board did not respond to anything (except turning off the power or pressing the power button). This never happened while testing the device with a modified DT file. However, sometimes (always during IPTV playback) there was a temporary freeze (the image stopped and after a while Kodi restarted spontaneously). This is probably related to the mentioned ffmpeg. Interestingly, this crash never occurred on an Orange Pi 3 board with the original sun50i-h6-orangepi-3.dtb file.
I made an aluminum case for one of my media centers. It has a built-in LCD display and several buttons connected to the GPIO. I was looking for how other users are solving the problem of controlling Kodi via GPIO. I found some options, but I didn't like anything. That's why I decided to create my own add-on for this purpose. I named it GPIO keyboard.
My add-on works on the principle of keyboard emulation. Pressing the button calls up a normal keyboard shortcut. For this to work, I had to create one more add-on. This is actually a python-evdev library, modified into a Kodi add-on form. This (binary) add-on is named the same as the original library, thus python-evdev (id = "script.module.evdev"). The python-evdev library is very powerful, and I think its use in Kodi add-ons could be much greater.
The GPIO keyboard add-on allows you to configure up to 16 buttons. Each button can have two functions (short or long press).
I made both add-ons in two versions. One is for Orange Pi boards (Allwinner), the other for Raspberry Pi 4.
There is no dedicated support area for Raspberry Pi created here, so I publish it together in the Allwinner space.
The GPIO keyboard add-on depends not only on the python-evdev add-on, but also on the Orange Pi Tools (or Raspberry Pi Tools) add-on.
Allwinner_addon_service.gpio-keyboard-001.zip
RPi4_addon_service.gpio-keyboard-001.zip
This is fixed in the fresh mc 4.8.27. Expect a system-tools REV 125 update soon.
Great news. Thank you.
I have released new versions of add-ons. See the initial post of this topic for more information.
This solved the problem.
I'm glad it helped. I had the same problem some time ago.
Try mc -u.
Thank you for the advice. It really helps.
What is the reason I have to disable subshell now, while before it was not necessary?
I recommend your attention this post.
Midnight Commander (part of virtual.system-tools) has not been working for several weeks. It starts, but then it freezes.
The last functional version was 9.80.11.121 (at least according to my tests).
Note: I run LibreELEC on the Allwinner platform, but I think it's the same on RPi4.
no need, just remove quiet from extlinux.conf. If you want terminal on serial, also add systemd.debug-shell=ttyS0
I had the quiet parameter removed before. Now I have also added systemd.debug-shell=ttyS0, so the serial console is fully functional.
So now I can use a serial console to communicate with the LE in a similar way as via an SSH connection.
Once it freezeed, I found that the system was not responding to the serial console either. Like when it's off.
From what we know until now, it won't hurt to do the test.
That's right, a memory test can't hurt. So I prepared an SD card with the Debian operating system. I found only one software for memory testing, a memtester.
I did some tests, but all the results were OK. Debian worked well, there was no freezing.
Then I did the same and with the same result with the Ubuntu operating system.
So there is no indication that my board is defective.
Nevertheless, I decided to buy another piece of the same board to see if the board was defective or not.
I am aware that in one case I will have two good boards, which, however, cannot be used with LibreELEC ...
Thanks for the answers, but it's sad for me.
So I won't do a memory test yet.
I understand that it will be difficult to find. No crash log because there is no crash ...
However, such an unreliable system is unusable for normal operation.
In my case, the problem may not be related to ffmpeg. I just restarted the system and then I didn't do anything.
Unfortunately, this freezing also occurs when watching IPTV.
Just for the purpose of this testing, I made a new SD card and did not install any add-ons at all (except for the screensaver).
So this is an almost pure "factory" state as when it was first run.
The course of the test was that I enabled the debug log and rebooted.
The screensaver started automatically and the photos show that the freeze occurred at 06:50, while the last entry in the kodi.log was at 06:32:37.
I was surprised that the serial console log contains only the system boot and then nothing.
Would it be possible to make some debug image that would write in detail to the serial console?
I have had a problem with LibreELEC / Kodi installed on the Orange Pi 3 board for a very long time (from the very beginning).
The problem is that the whole system freezes. In this state, the board stops responding to any command, does not respond to the ping, the SSH session is interrupted and the image on the monitor freezes.
The board responds only to the power button and, of course, to the power off. This problem occurs intermittently, usually within one hour of startup.
I needed to find out whether the cause of the described problem is the nature of HW or SW.
First, I tried to replace everything that could be replaced (SD card, cable, power supply). Unfortunately, no change.
Then I tried to install Kodi in Armbian OS. It was unusable (very slow, just an old version of Kodi).
Finally, I installed the Android 7 OS on the SD card and then Kodi. This is a combination you can live with, at least on a small monitor.
I let it run for a week and everything was fine. The problem did not occur. I am aware that this is not entirely sufficient proof that the board is OK. But I only have one piece.
What should I do ?
I found out that there is an bug in the OPi.GPIO library (and therefore also in the virtual.opi-tools add-on). There does not work properly callbacks when mode == GPIO.BOARD.
Links to download the corrected version are in the initial post of this topic.
Great!
I compiled a devel build with the above modification and it works.
Thank you very much for your support!
Thank you for the answer. I have three different boards:
1) Orange Pi PC (H3, 1GB DDR3 SDRAM)
2) Orange Pi Lite 2 (H6, 1GB LPDDR3 SDRAM, no Ethernet)
3) Orange Pi 3 (H6, 2GB LPDDR3 SDRAM)
I use them all for LibreELEC, but due to the specification, my favorite is the Orange Pi 3. This is the board on which I performed the described debugging.
So I made another debug version and found out even more information.
The problem is in the function
struct gpios *new_gpio(unsigned int gpio)
{
struct gpios *new_gpio;
new_gpio = malloc(sizeof(struct gpios));
if (new_gpio == 0)
return NULL; // out of memory
new_gpio->gpio = gpio;
if (gpio_export(gpio) != 0) {
free(new_gpio);
return NULL;
}
new_gpio->exported = 1;
if (gpio_set_direction(gpio,1) != 0) { // 1==input
free(new_gpio);
return NULL;
}
if ((new_gpio->value_fd = open_value_file(gpio)) == -1) {
gpio_unexport(gpio);
free(new_gpio);
return NULL;
}
new_gpio->initial = 1;
new_gpio->bouncetime = 0;
new_gpio->lastcall = 0;
if (gpio_list == NULL) {
new_gpio->next = NULL;
} else {
new_gpio->next = gpio_list;
}
gpio_list = new_gpio;
return new_gpio;
}specifically in section
new_gpio->gpio = gpio;
if (gpio_export(gpio) != 0) {
free(new_gpio);
return NULL;
}
/************* /sys/class/gpio functions ************/
int gpio_export(unsigned int gpio)
{
int fd, len;
char str_gpio[4];
if ((fd = open("/sys/class/gpio/export", O_WRONLY)) < 0)
return -1;
len = snprintf(str_gpio, sizeof(str_gpio), "%d", gpio);
if(OPiGPIODebug)
printf("\n /sys/class/gpio/export %d \n",gpio);
write(fd, str_gpio, len);
close(fd);
return 0;
}So now it looks much clearer.
There is no sys/class/gpio directory in LibreELEC (maybe just for Allwinner?).
For comparison - in the case of Raspberry Pi this directory exists ...
Can this be fixed?
I understand that I have provided little information.
I made a debug version and now I have some information.
This problem is in the following function:
int add_edge_detect(unsigned int gpio, unsigned int edge, unsigned int bouncetime)
// return values:
// 0 - Success
// 1 - Edge detection already added
// 2 - Other error
{
pthread_t threads;
struct epoll_event ev;
long t = 0;
struct gpios *g;
// check to see if this gpio has been added already
if (gpio_event_added(gpio) != 0)
return 1;
// create epfd if not already open
if ((epfd == -1) && ((epfd = epoll_create(1)) == -1))
return 2;
if ((g = new_gpio(gpio)) == NULL)
return 2;
gpio_set_edge(gpio, edge);
g->bouncetime = bouncetime;
// add to epoll fd
ev.events = EPOLLIN | EPOLLET | EPOLLPRI;
ev.data.fd = g->value_fd;
if (epoll_ctl(epfd, EPOLL_CTL_ADD, g->value_fd, &ev) == -1) {
remove_edge_detect(gpio);
return 2;
}
// start poll thread if it is not already running
if (!thread_running) {
if (pthread_create(&threads, NULL, poll_thread, (void *)t) != 0) {
remove_edge_detect(gpio);
return 2;
}
}
return 0;
}Specifically, where after executing g = new_gpio(gpio) the result is NULL.
But I still don't know why this only happens in the LibreELEC OS, while in Armbian it works properly.