Posts by ghtester

Did you reboot RPi afterwards?

Kodi does not search for latest available RPi's firmware releases so it depends on LE build you have installed. If you use a stable but old LE release (9.2.6), also the RPi bootloader offered is obsolete.

See for instance here:

Post

RE: Boot from SSD instructions

Nothing special should be necessary if your RPi 4B does not have a very obsolete bootloader.

Just write a LE image to your external SSD, connect it to RPi 4B and try to boot.

if it won't work, try the same with SD card ( this should definitely work ), then check the VL805 USB firmware & RPi bootloader versions and upgrade them to latest available (check the release notes here).

How to check the CURRENT versions: rpi-eeprom-update

VL805 release should be: 00138a1

BOOTLOADER should be: Thu Apr 29…

ghtester

April 3, 2021 at 3:20 PM

Quote from dippes

Yes everything up to date.

No it is NOT - at least your bootloader is a bit outdated, the latest stable release is dated 2021-04-29 and beta 2021-05-19 (rpi-eeprom/release-notes.md at master · raspberrypi/rpi-eeprom · GitHub).

It looks your portable SSD is not detected, it could be due to incompatibility with RPi's bootloader or due to insufficient power.

Please note that RPi 4B has a quite low power limit on USB ports (even though you have a good power supply) so an external power for attached external disks is a good option.

Also try connecting the SSD to USB 2 ports.

Try to connect the dongle(s) with an USB extension cable(s) or with an USB hub. Perhaps there's a high-frequency noise from RPi (or from the USB3 key) which breaks the dongle's wireless communication so it may be better if you move them as far as possible from RPi's board. Also try to replace batteries with fresh ones.

OK, so it looks that OpenVPN does not set the variables as expected by the update-resolv-conf.sh script or the script does not see the enviroment's variables. So you need to check the OpenVPN documentantion if the expected variables are still valid and set:

foreign_option_1

foreign_option_2

foreign_option_3

foreign_option_4

script_type

I suppose if you put at start of the update-resolv-conf.sh script something like that:

echo $foreign_option_1 > /tmp/testfile.txt

echo $foreign_option_2 > /tmp/testfile.txt

echo $script_type >> /tmp/testfile.txt

Then try to connect VPN and then check the /tmp/testfile.txt, it will be perhaps empty and you need to discover why.

Maybe the first line of script should be #!/usr/bin/env sh instead of #!/usr/bin/env bash ?

As I don't use OpenVPN and don't have installed that Add-on, I can't test nor say more...

Also check this thread, maybe the solution is there: Creating "update-resolv-conf.sh" equivalent to plug openvpn DNS leaks

Quote from svenfoo

Could the decoding artifacts be caused by under-voltage?

In your case it's not likely (if the all facts described earlier are true). I suppose it's the driver issue.

OK, it's a bit complex for me to understand what's wrong with the script. But you may try to edit the update-resolv-conf.sh to this simplified form below and give it a try.

#!/usr/bin/env bash
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up  /storage/.kodi/userdata/addon_data/service.vpn.manager/update-resolv-conf.sh
# down  /storage/.kodi/userdata/addon_data/service.vpn.manager/update-resolv-conf.sh

# Licensed under the GNU GPL.  See /usr/share/common-licenses/GPL.
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
# foreign_option_4='dhcp-option DOMAIN-SEARCH bnc.local'
resolvpath=/run/connman

case $script_type in
up)
  mv $resolvpath/resolv.conf /tmp/.
  for optionname in ${!foreign_option_*} ; do
    option="${!optionname}"
    part1=$(echo "$option" | cut -d " " -f 1)
    if [ "$part1" == "dhcp-option" ] ; then
      part2=$(echo "$option" | cut -d " " -f 2)
      part3=$(echo "$option" | cut -d " " -f 3)
      if [ "$part2" == "DNS" ] ; then
         echo nameserver $part3 >> $resolvpath/resolv.conf
      fi
      if [ "$part2" == "DOMAIN" ] ; then
         echo domain $part3 >> $resolvpath/resolv.conf
      fi
      if [ "$part2" == "DOMAIN-SEARCH" ] ; then
         echo search $part3 >> $resolvpath/resolv.conf
      fi
   fi
  done
  ;;
down)
  mv /tmp/resolv.conf $resolvpath/.
  ;;
esac
exit 0

This is just a part of the file which does not say much. Put the whole file to pastebin.com and share a link here.

With LE 10 Nightly (Index of /) when the display is connected only to HDMI1 on RPi 4B, both audio & video works fine on it.

The same happens when the display is connected only to HDMI0.

When both HDMI0 and HDMI1 ports are occupied (by active HDMI devices), Kodi displays video on HDMI0 only and audio can be switched to any HDMI output.

I don't use VPN so I don't have personal experience and I did not have to struggle with DNS settings. But when I quickly look at your log & resolv configuration in my LE 10 Nightly, at first I would check the /storage/.kodi/userdata/addon_data/service.vpn.manager/update-resolv-conf.sh file, especially line 66 which needs to be modified somehow to fix the syntax error reported above in the log.

I suppose this script should perhaps modify the /run/connman/resolv.conf file, generated by Connection Manager by default, which contains a current DNS server's IP address. So you should update the script to do what is expected.

I am afraid nobody can tell you the release date of LE 10 stable. AFAIK, RPi 4B has a priority but a lot of things has changed from LE 9.2.6 and it will take some time to finish that hard work. My personal estimate is several months.

FYI: LE 10 Nightly - Live TV - Subtitles not displayed on some TV channels

It's really strange. Do you have a customized bootloater config / did you also changed it when replacing bootloader versions? What's your current?

Are you sure the SD card / USB key imaging was done properly?

Also this is strange:

Quote from greycat

I tried the 10 beta, and it could boot properly. But it's too unstable (I'm getting no wired ethernet, CEC doesn't work reliably, reboot via menu gives a kernel panic...) so it's not a solution I can live with.

I am running LE 10 Nightly builds but never had an issue with wired ethernet nor kernel panic when rebooted from menu.

Didn't you try to overclock your RPi?

If not, I am out of ideas and perhaps there could be really a compatibility issue with RPi 4B v1.4 but I am afraid it won't be ever analyzed in LE 9.2.6. Move to LE 10 Nightly builds and you won't be sorry. Despite there are some issues, in general it works fine and the progress is every day.

Make sure you are using HDMI0 output (next to the power connector).

Also try with another HDMI device (a PC display with FHD resolution if possible) to test if there's any change.

No problem.

RPi 4B is a fair-priced, great piece of HW with many use cases for a long time due to excellent support from vendor & community.

But using RPi as desktop - it depends on RAM size you have. I own two RPi 4B but only 1 GB and 2 GB models. Both are not very suitable for a "full" desktop so at least 4 GB model would be much better.

In every case - a boot from some SSD HDD connected through USB3/SATA adapter instead of SD card is necessary.

With a good power supply and with a good cooling (there are several great ALU cases) it can be running permanently for sure.

Do not underestimate the required power supply performance, otherwise you will notice strange functionality problems that can result in data loss.

RPi 4B itself in fact needs 2x more current than you expect.

Furthermore, in the case of rotary HDDs, it is necessary to take into account the peak power consumption at power-up, which is usually above the (quite low) limits of the RPI 4B USB ports. An USB "fork" cable (with a power plug, which can be easily made) or an USB hub with external power is then a must.

I have no experience with DVB-C but Astrometa tuner (15f4:0131) works fine on RPi 4B-2GB / LE 10 Nightly builds / Tvheadend Server 4.2-4.3 / Tvheadend HTSP Client / DVB-T2 so I believe it should work with DVB-C as well.

Reboot your RPi, connect to LE through SSH console, copy & paste and put here output of:

lsusb > /tmp/info.txt
echo >> /tmp/info.txt
dmesg | grep DVB >> /tmp/info.txt
echo >> /tmp/info.txt
ls /lib/firmware/dvb-demod-* >> /tmp/info.txt
echo >> /tmp/info.txt
ls /storage/.config/modprobe.d/ >> /tmp/info.txt
echo >> /tmp/info.txt
ls /dev/dvb/ >> /tmp/info.txt

paste /tmp/info.txt 
#

Unfortunately it's not possible here due to different drivers used in latest LE version.