Intel NUC NUC5CPYHMy old Dell Zino media PC seemed to lose all audio for some reason, which is a bad problem for a media PC. I bought a cute as a bug less than half the size Intel NUC NUC5CPYH to replace it: I bought the max memory (8G) and a 2TB 2.5 inch disk to go in it and installed fedora 26 from a live USB as the OS. Aside from being half the size, it is also a lot quieter. If I get about a foot away I can hear a slight whir if there isn't any other noise in the room, but it is close to totally silent. The rpmfusion repos have kodi pre-packaged, so it was easy to install and tweak for auto start up on boot following the instructions at HOW-TO:Install Kodi on Fedora 26 using RPMFusion packages. That all worked, but kodi insisted the timezone was UTC. Everything else on the computer was aware I had configured the zone for eastern time, but kodi insisted on UTC. After many ridiculous attempts to fix it (like embedding the TZ variable in the systemd service configuration), I finally tried changing the obviously irrelevant and nonsencical setting named "timezone country" from blank to United States. Magically, kodi automatically set timezone to eastern time once I changed the country setting. I have no idea where this logic came from. Timezones often span countries and countries often have many timezones. Why a country is involved in this at all is a mystery I cannot fathom. But at least it knows the timezone now :-). Next I wanted to recover all the media files from the old Zino. After desperately trying to get Windows to share the dadgum disk in some form, I finally said to heck with this and booted the old Zino with the fedora 26 live USB I used to install on the NUC. Then all I had to do was mount the partition with the files and use rsync. This seemed to work fine, though I had to leave it running for several hours (if I had one of those docking ports where you can insert an internal drive and talk to it via USB, it probably could have gone lots faster, but I don't have one). I used a Harmony remote with the old Zino to control the media software, so my next step is trying to get IR remote control working with the replacement box. Unfortunately, I picked the weekend they are moving the kodi forums to a new server, so lots of my google hits aren't responding very well :-). I did see a lot of references to ir-keytable, which turns out to be located in the v4l-utils package on fedora, so I installed that and was able to observe some key codes show up when I pressed some buttons. Unfortunately, lots of buttons on the remote have no effect, so I'm in the process of loading various remote definitions into the remote using the harmony software, then trying out the new remote to see if I can find the one with the most working keys :-). ...been fooling around with stuff a lot. Managed to make the IR stop working completely for a while (especially when trying to use lirc rather than evdev). Eventually told the Harmony to use the "Microsoft" "Windows Media Center" which printed a confusing warning I ignored. I also used the Harmony software to associate a function with every button so every button would be possible to program. Finally the MythTV web page User Manual:IR control via evdev had a lot of useful information to get things setup. This is finally working (a bit). Up/Down/Left/Right seem to be functioning as expected, but KEY_EXIT isn't acting like typing ESC on the keyboard to get me out of the current mode, and KEY_OK isn't acting like KEY_ENTER, etc. Unfortunately 100% of all the documentation for writing kodi keymap files is totally wrong about how to discover key IDs (at least any docs that aren't on the kodi forums). One page told me to turn on debugging and look in the log after pressing a key. That sounds painful, but possible. However no debug info about keys wound up in the log. Grrrr... I may have to invert this and modify the keymap loaded via ir-keytab to change the key code generated by different button pushes so they look like what kodi expects by default (swap enter and OK, for instance). This is complicated by having no idea what the heck legal names are available for keys. Ha! Vast amounts of research have found irrecord -l prints a list of KEY_ names. Also discovered you can obtain key names from strings - /usr/bin/ir-keytable | fgrep KEY_, so perhaps I am getting close. Success at last! Here's the summary of what (as best as I can recall) got this all working:
The editing of /etc/harmony probably requires a bit more explanation. The file just contains scan codes the kernel generates for IR remote buttons followed by key names to generate (as though they were typed on a keyboard) when it sees that code. I describe above how to find all the key names you can use, the tricky part is discovering which keys kodi uses to do what you want. This was a bit of trial and error. You can run ir-keytable -t at the command line to press buttons and have it print which key codes are generateds. When I tried this, the default definition generated KEY_OK when I pressed the OK button on the harmony, but kodi didn't seem to respond to KEY_OK, so I tried KEY_ENTER instead, and that acted as expected. So editing the file just means changing the keys generated by the IR codes. After you make changes, you can run the command from the rc.local file to load the new key table for testing. Hey! I finally found this chart with the kodi keyboard controls, which should simplify figuring out which remote buttons should generate which keys. Loading the device definition into the harmony was a bit tricky as well. The software spits out some kind of nonsensical warning, but if you just ignored it and tell it to go ahead and use the damn device definition, it works OK. You also need to go into the Buttons section and make sure you have every button programmed for the device, otherwise you'll be left with buttons you can't use for anything (I just picked random un-used codes when there wasn't any mapping that made sense). I have a feeling I may be discovering new keys I want to change for a while, but all the basics are now working. (Note that none of this uses lirc, it is all done with the kernel drivers which make IR remotes look like keyboards to the system.) |