Posts by ghtester

    This is not the MyGica T230 or C or C v2 .

    I wrote about MyGica T230A witch idVendor=0572, idProduct=689a

    In fact it is T230C2 as you can see for instance here: DVB-T USB Devices - LinuxTVWiki

    Although the same device ID does not always mean it's the same hardware inside (Astrometa for example), I would say MyGica is not so bad regarding this matter..

    Again, there's no need of urgent patching, this tuner works fine on latest LE versions.

    In LE 9.80 nightly, which I am currently using, there are only kernel drivers. Although it's not yet 100% rock stable and it may depend on which USB port is used (2.0 or 3.0), overall it works quite fine.

    In LE 9.2.6 official it was also working fine, as far as I can remember, at least with CrazyCat drivers.

    Edit: Ahh, the idProduct=689a is really different... :( A fake or a quite new product???

    I see that Geniatech does not offer any Linux drivers but you may perhaps try to contact the Support or visit a forum ( Get Support from the MyGica official website ). So far I did not find any mention regarding to T230A under Linux. Maybe it will be necessary to grab the firmware from Windows driver, it also depends on HW difference from previous T230x sticks so more changes in driver sources could be a must...

    Exactly. There'll be additional work to do if he won't give it up... Perhaps another way could be through irexec which I am using for several IR buttons to do everything I need and this could be configured easily (don't know if it's a good idea for a whole keyboard but it could work fine at least for some important buttons). Did not test that but I suppose this could work when there's a scan code mapping done to KEY_A etc. properly (or if it's send as fixed values by this driver). But maybe I don't understand the mce_kbd's difference...

    echo /usr/bin/irexec -d /storage/.config/lircrc >> /storage/.config/autostart.sh

    /storage/.config/lircrc :

    begin

    prog = irexec

    button = KEY_A

    config = kodi-send --button=a

    end

    begin

    prog = irexec

    button = KEY_B

    config = kodi-send --button=b

    end

    ...

    ...

    OK, thanks for a correction, sorry, my fault as I have looked at my LE 9.80... And as I am using my proprietary mapping files originally copied from previous LE version (and then renamed) for a long time and everything still works fine, I did not notice the change.

    So SilkBC just need to use the files which can be found in the /usr/lib/udev/rc_keymaps/ folder and does not have .toml extension in LE 9.2.x. The name is not important and can be changed but the file structure is more important and should match the LE version.

    I have nothing in my /storage/.config/rc_keymaps folder; what *should* be in there? My actual MCEUSB remote "just works" without any files needing to be in there.

    Yeah so in your case you are in defaults so the current settings should be based on /etc/rc_maps.cfg and /usr/lib/udev/rc_keymaps/libreelec_multi.toml default files located in read-only filesystem. If you read the wiki as recommended by HiassofT, I think you'll understand how it works.

    I would copy libreelec_multi.toml file to /storage/.config/rc_keymaps/ folder and rc_maps.cfg to /storage/.config/ folder where you can modify them to override defaults.

    At least you need to change the line in /storage/.config/rc_maps.cfg from

    * rc-rc6-mce libreelec_multi.toml

    to

    * rc-rc6-mce /storage/.config/rc_keymaps/libreelec_multi.toml

    Then use ir-keytable -a /storage/.config/rc_maps.cfg -s rc0 command to update the configuration (always stop kodi and eventlircd before using systemctl, then start them again in reverse order). Everything should work as before. Then update /storage/.config/rc_keymaps/libreelec_multi.toml file to change scancodes <--> commands assignment, apply ir-keytable -a /storage/.config/rc_maps.cfg -s rc0 again and you irw should show you the results.

    In case you don't receive scan codes, you have to enable additional IR protocol, for instance to add mce_kbd (but consider HiassofT's advice above):

    ir-keytable -p lirc -p nec -p rc-6 -p mce_kbd -s rc0

    Also you may need to use another suitable template instead of libreelec_multi.toml for your preffered IR protocol, check the /usr/lib/udev/rc_keymaps/ folder and use the best file for you.

    Edit: See below the HiassofT's correction - I did not notice that there's a change between your LE 9.2.6 and my 9.80 Nightly build so the mapping files you'll find won't have the .toml extension. Everything else should be the same regarding the described steps.

    Edit2: Corrected the path for rc_maps.cfg file.

    I don't know your IR devices and there're missing important details (even the LE version you are running) and I have no idea what do you have connected to LE. But if you have attached more IR devices at the same time, you need to specify the right parameters which may be different from defaults.

    At first, run ir-keytable without parameters, it should list all recognized IR receivers. You should see there, among others, something like:

    Found /sys/class/rc/rc2/ with:

    ...

    Enabled kernel protocols: lirc nec

    ...

    Found /sys/class/rc/rc0/ with:

    ...

    Enabled kernel protocols: lirc rc-5
    ...

    You can also see the device names there.

    Then you run again for instance ir-keytable -t -s rc2 and push buttons on your IR remote control. If it has the appropriate protocol enabled, you'll see the scancodes received from rc2 device.

    You need to have the /storage/.config/rc_maps.cfg configured properly and each active device should have there specified the correct path to mapping file which should be stored in /storage/.config/rc_keymaps/ folder.

    For instance mceusb * /storage/.config/rc_keymaps/myIRremote

    In the mapping file myIRremote you need to configure the assignment between scancodes and commands (that irw displays when the mapping is correct).

    When you change the mapping file, you need to update the configuration, for instance:

    ir-keytable -a /storage/.config/rc_maps.cfg -s rc0

    Just FYI - on RPi 4B due to much better hardware this issue does not exist anymore, IR works fine on GPIO with LE regardless of USB data transfers.

    Regarding to RPi 0-3 I think IR remote controls based on RC5/RC6 protocol could work even through GPIO receiver during long USB transfers but it might not be easy to discover the protocol type at first sight so the supported USB IR receiver is the best choice.

    Well as far as I can remember, I started having this issue as well after upgrading to LE 9.2.6 (even I did not change the HDMI port).

    In my case I am turning on/off the display by relay (through GPIO pin on my RPi 4B) and there was a python script switching the relay ON after LE startup. It was working fine in previous LE versions but now it's too late to 'handshake' with display booting at the same time so the display did not receive HDMI signal anymore.

    I have solved it through config.txt - putting there a command for setting the appropriate GPIO pin earlier so the display is ready before Kodi starts. This works fine.

    OK, so after some testing I have found an incompatibility with Kodi / LE 9.80 nightly and ESP32CAM. On LE 9.2.6 it partially worked but unreliably.

    I have tested the same with another camera based on mjpg_streamer and it works fine.

    Also I have discovered that UVC drivers are working fine so it's possible to stream or make a pictures from an UVC compatible USB webcam connected locally.

    I am sorry but it's another story - maybe we should not mix more different questions to the same thread.

    I don't know (yet) the kodi2mqtt add-on (and it looks it's not an official add-on in LE?) but make sure you have installed / configured all (possible) necessary prerequisites, maybe you should look into kodi2mqtt documentation or visit some related forum thread.

    In this case you don't have (at least) the path to the paho.mqtt.client (which is IMHO the important prerequisite) module specified so that's why you can't run the test script.

    USB booting on the RPi4 may require a firmware update first...

    Yes you are right but the firmware is a part of OS (lies on partition on SD card / USB flash), bootloader is inside of RPI's eeprom. If you replace the SD card, you also replace the firmware. That's why I mentioned the bootloader needs to be upgraded to latest version first (and perhaps configured properly but a default should be OK), this is an essential task (ther're also some updates related to SD cards compatibility so it's good to upgrade anyway). As soon as this is done, he can boot directly from USB mass storage device with LE 9.2.6 image which already contains the proper firmware.

    The 'simplest' option for me was to install Raspberry Pi OS (formerly Raspbian) onto an SDcard, and update both kernel & USB firmware to enable USB booting.

    Yes that's true, the Bootloader EEPROM and VIA USB3 Firmware (which by the way shoud be also at latest version 00138a1) can be updated from running LE but in this specific case when LE can't boot I would also go through Raspberry Pi OS placed on the same SD card using the official Raspberry Pi Imager to check if the SD card is working ever with his RPi 4B.

    I would also try to use some USB mass storage instead of SD card - I have experienced some SD cards (despite NOT cheap) were not fully compatible with RPi 4B.

    When booting from USB, it's just necessary to put dtparam=sd_poll_once=on to /flash/config.txt (otherwise there're SD card related errors filling log).

    Also make sure you have the latest (at least stable) bootloader version installed ( rpi-eeprom/release-notes.md at master · raspberrypi/rpi-eeprom · GitHub ).

    Well, forget the libraries and double check your configuration again instead.

    Why don't you try the same (earlier working on RPi OS) display settings in LCDd.conf?

    I see you changed the Speed parameter from 19200 Bd to 115200. Some displays have the DIP switch to select the preferred speed so if you did not set that properly, the garbage on your display is the logical result.

    OK, I understand. So please don't mix too many things together and focus on LE.

    I think LCDproc works on LE as same as on Rpi OS if properly configured, just the config file location / driver folder location is different. I can recommend to do / check these steps in LE:

    1) Put the appropriate necessary options to /flash/config.txt and check if the display is properly attached, check if there's no HW / SW conflict on UART

    2) Install the LCDproc add-on and configure it in GUI to select the correct driver. Then reboot LE and check if the LCDd is running with proper parameters using ps | grep LCD

    3) Edit the appropriate LCDd.conf config file located in accordance with ps | grep LCD output to put necessary preferrences to correct display section

    4) Reboot LE again and then install and configure the XBMC LCDproc add-on properly.

    I don't have any experience with Cfontz display as I am using hd44780 connected through i2c but I believe it should work fine as well.

    You can also run the LCDd in foreground to test quickly with any preferred config file but make sure you don't run more instances at the same time.