Posts by pila

    This is frustrating issue to google, since ALL hits are related to people having wrong time and date at the RPi LE. Mine have perfect time and RTC. So, I would like to make them able to serve NTP time to other devices, should a need arise.

    I need a solution for ntpd working on LE7. I can not save ntpd.config and it does not exist. So, if someone could help me activate ntpd server on LE7, it would be great!

    For LE9, it may be better to change over using timedatectl. It seems to me that LE9 is by default using ntp and not timedatectl. So, NTP could still be used there normally, I guess. I will not completely switch to LE9 for 6+ months, to this is only a secondary issue.

    I use LE7 on all my RPis. Just installed LE9 to RPi4. On, LE7, I would invoke "System Info" with a certain key of my remote whe the main Menu is displayed. Not, this does nothing. I copied my config to LE9 and all other keys seem to work as on LE7. I am primarily interested to see the Temperature. If I could burn it into main skin, I would like that even better.

    I am thinking: at LE9 the skin is changed and there lies some catch. I did install Confluence, so I do have the same looking skin on LE9.

    I am unable to find what to assign to my remote key. I do not have a problem redefining a key on my remote, I just need to be told what to stick to it to display System Info while in Kodi in Main menu.

    It looks to me like I need (to add to) global:

    <info>ActivateWindow(SystemInfo)</info>

    but it makes no change. Plus, I did not have this in LE7 and key <info> calls System Info with no problem.

    Something is wrong with the HDMI signal with latest Beta1. TV returns to RPi4 connected HDMI1 automatically after power up. Previous versions did not have this problem. Now RPi4 acts like CEC is turning the port on its own.

    At RPi4 I have had LibreELEC-RPi4.arm-9.1.001 installed. I just upgraded manually to latest LibreELEC-RPi4.arm-9.1.501. CEC is turned off (I verified).

    Description: I use HDMI2. (RPi4 is connected to HDMI1 with main menu screen of Kodi being pasive). Turn off TV with HDMI2 active. Turn TV back on to the same HDMI2 port. HDMI2 source is displayed. After few seconds, HDMI1 port on myTV activates on its own and switches to RPi4 HDMI1. I must manually select HDMI2 to return to where I was.

    I can see and verify my remote is not sending any codes and can not cause this problem. My remote turns on TV on HDMI2 and waits. When picture (HDMI2) displays, TV is switched to RPi4 HDMI1 on its own in a second or two. Like CEC is requesting activation of that port.

    But, if I turn TV off with RPi4 HDMI1 port active, I can normally turn TV on and remote will switch it to HDMI2 after few seconds.

    If I am at HDMI2 and restart RPi4, it will not switch to HDMI1 when LE9 boots.

    Seems like a bug. Can it be at least manually overriden? I would prefer answer than blindly trying to reconfigure HDMI port on my RPi4.

    The master location for hostname is /storage/.kodi/userdata/addon_data/service.libreelec.settings/oe_settings.xml .. but you'll only see the xml node for hostname if it has been manually added or changed via the GUI. Other services read the hostname from this location to set /etc/hostname (which is a symlink to /storage/.cache/hostname) at boot time.

    I just had to change hostnames on several RPis with LE, this wouuld be impossible to guess and nothing normal would work. As usuall, chewitt is right! Thanks for taking the time :)

    Hello Complex_Username,

    According to the code, you can pass parameters to sshd of LibreELEC with the SSH_ARGS variable of /storage/.cache/services/sshd.conf, which is writeable. Eg, to have sshd listen on port 789, set SSH_ARGS="-p 789" in /storage/.cache/services/sshd.conf, and then restart sshd (with systemctl restart sshd, or with reboot).

    Works perfectly (LE 7) and there is even a line to turn on and off password access, should one need that (as I did).

    autostart.sh did not work for me. But, as my script runs every 5 minutes, it checks if /storage/.cache/services/sshd.conf contains my argument, and if not, adds it and restarts sshd.

    Try setting SSHD_DISABLE_PW_AUTH="true" in /storage/.cache/services/sshd.conf and run "systemctl restart sshd.service" to bounce the daemon and reload the new config.

    Thanks, I belive that will do it!

    I have had today another shock when I discovered that the stupid chinese ZTE modem/router at that location does not provide port forwarding from a port X to a port Y (just forward port X to the IP address), I was lucky enough to find excellent #5 post setting ssh port and noticed that settiong there. Thanks for confirming it.

    Stupid problems: I live on an island and when the sun hits us, my provider damage data (entire summer). So, I may have problems connecting using anything "longer" (such as the ssh key) as it may get damaged. That was not enough, but they have internal routing error which breaks their routing wihtin their network so I can not use VPN whenever we get address from a range 109.227.*.*. So, a RPi will be fixing these problems until they sort them out. ssh is for me to manage it remotely.

    I connect to a remote RPi 2 with LE7 using ssh. Everything is well. I can connect using pwd and ssh in using the secure way. Pwd access is then turned off. RPi is programmed to control the modem to ensure that the Internet is always working.

    But, I would like to be able to enable password login and disable it should the need arise. It is a remote headless device. So, I must do it from the terminal over ssh.

    Login via ssh and do the following:

    If I may improve a bit on your excellent answer :). As I am lazy, I do it like this:

    Code
    connmanctl config "$(connmanctl services | awk '/^\*/ {print $3}')" --ipv4 manual 192.168.1.8 255.255.255.0 192.168.1.1

    This finds the entry starting with * and sets the IP address to 192.168.1.8 with gateway set to 192.168.1.1. Adjust these two as you need them.

    update to LE8.2 - 7.0 is heavily outdated

    I have about 30 computers. I do not fix which is not broken. Computers should serve me, not the other way around :)

    Outdated is a term good for shirts and hairstyles. Newer in computers most often means only more new problems if nothing gets fixed from the older version. I do not see any good in newer LE versions. And this is my profession for many years now.

    So, this will not work in LE7? I now have WG++ running on a server in a VM which is there for some other good reasons.

    Any way to get WG++ v2.1.5 to run on RPi LE 7? Problem is Mono and I can not find later version for LE v7. This would likely work for later verions of LE, ssh and then:

    Code
    wget http://addons.libreelec.tv/8.2/RPi2/arm/tools.mono/tools.mono-8.2.107.zip

    How to get such a version working in RPi LE 7?

    HiassofT guide from the seond post is the single best thing on the topic I havew found. Thanks.

    I am using v7 since it works and I do not fix what is not broken. For last years I used RPi with an inexpensive IR set wihich included USB receiver and remote - IRF Media Media Center PC (W-01RN). Instead of the chinese remote, I actually use Logitech 600/650 remotes as I do for last 10 years. Good thing is I can get 45 distinct commands I needs from this combo. Bad thiing is: it uses Blue to turn the mouse off, uses Red instead of Record button, there are no Exit and Back separate keys, There are no EPG and Info keys, plus... So I had to be creative.

    The only thing I did not fix perfectly was finding out how to make an Exit button go to the Kodi Home screen and stop everything else, wherever I might be in Kodi. Best I managed was to use an extra code and map it to the <rootmenu> and then use that code to try exiting,b ut it does not work perfectly. List of actions in Kodi is exntesive but usefull since no description of what is where can be found. Just the list of names.

    What may be of interest here? Recently I switched to TSOP IR receiver. I just plasecd

    dtoverlay=lirc-rpi

    into config.txt and learned LIRC all the codes from my Logitech (as it was setup fir IRF) and all works perfectly.

    To test the new method, I replaced the above line with

    dtoverlay=gpio-ir

    and after a reboot, all is working perfetly again. I did not try generating any new config, I am still using evveryhting else as setup for the old method. But, this seems like a good way to start working with the new method. When I kill lirc and Kodi, I get normal responses from ir-keytable as expected.

    But, I must say that I am not exactly clear on which combo this scenario is using. I am still currently using LIRC but with dtoverlay=gpio-ir. Seems to me like old method was simpler to implement.

    As nobody knows the answer... I was going to try uisng just plaing naked IR Receiver Modules for Remote Control Systems that I bought before, but was lazy and did not know how to select a remote using IR diode as a sensor alone.

    So, I connected IR TSOP to GPIO pins, learned RPi all the commands from my remote and now I do not have any problems. All works perfectly well.

    But, without learning it all the commands, I was not able to break free form it picking up RC6 remote and thus clashing with a Pansonic TV and QNAP server remote sensors.

    When my RPi reboots, its Remote control sensor needs to be first sent the command to turn the mouse off (Blue key). Restarting Kodi does not influence this, just the RPi rebooting.

    Instead of me having to press a Blue key on the remote each time after a reboot, how could I make this done from a script, likely. autostart.sh.

    I do not know if this key is interpreted internally by the Remote Control sensor's electronics itself so it may not be even possible to influence it without actually sending the needed IC signal from the remote.

    Most likely cause: You have filled up your MicroSD card with some garbage (possibly recordings) you are not aware of, e.g. recording without share mounted. When you mount, you will not see that garbage. Unmount everyhing, then check folders in /storage and empty them. 16 gb or 64gb is not a problem, I use only 8 gb cards.

    As for monitoring the free memory, this may not be a good way to monitor for this particular problem. Currently, I have one active recording, and free gives:

    Code
    total       used       free     shared    buffers     cached
    Mem:        754656     729016      25640       7624       1808     503888
    -/+ buffers/cache:     223320     531336

    So if I monitor the first row it will go to just 24k and work perfectly. If I monitor without buffers/cache, it will remain very high. If someone has a better idea, I am open.

    Over time we found some memory fragmentation issues that affect long-uptime systems. Check free RAM, and if that's the issue, start planning an update to 9.0 as that's when it'll be resolved.

    OK, that seems very plausible since it typically takes several months for a problem to develop, and my script runs every 12 minutes. I thought the same as I have similar problem with my router, also in about 90 days time. But, for now, I want to resolve it on the current version. I dislike upgrades if I I do not have clear reasons.

    What to monitor? I am perfectly happy to monitor something and reboot if it gets over certain amount.

    Largest memory spent and only above 1mb are:

    top

    Mem: 270904K used, 483752K free,

    527m 71.3 0 0.8 /usr/lib/kodi/kodi.bin --standalon

    287m 38.8 1 0.0 {tvheadend} /storage/.kodi/addons/

    ps does not show me memory, but I could use top like this:

    top -n1 | grep kodi.b[i]n

    top -n1 | grep tvheade[n]d

    or is it better to monitor just the free memory, so if it drops below something, reboot.

    top -n1 | grep fre[e] | cut -d" " -f4

    or probably better:

    mem_free=$(( $( free | awk 'NR==2 {print $4}' ) / 1024 )); echo $mem_free

    What should I set for a reboot limit? 100kb? Or is this not a good tactics to capture this problem?

    Or simply do a preemptive RPi reboot say once monthly. But, I would prefer to know exactly why I am doing it than to simply reboot without learning anything.