Posts by chewitt

It was a group decision in OE days to discontinue them and there are no plans to reinstate i386 builds. It's still possible to re-add support and self-build a working i386 image though, e.g. GitHub - maideii/LibreELEC.tv-Intel-i386: Just enough OS for KODI appears to have done the core mods for i386 builds with an Intel GPU and it looks reasonably up-to-date, so if you clone his branch you should be able to run "PROJECT=Generic ARCH=i386 make image" and get something that works (self-build instructions are in the wiki). If you have AMD or nVidia GPU's there are probably some missing commits, but nothing hard to track down; from memory you can crib nVidia bits from my appletv-7.0 branch.

RTL871X: ERROR invalid mac addr:00:00:00:00:00:00, assign random MAC

The connection manager (connman) caches configurations in a structured format keyed on the connection type and MAC of the interface so ^ that's the problem. It doesn't forget.. it's just (correctly) presented with a new randomly generated MAC on each boot.

echo "options 8812au rtm_initmac=00:e0:4c:37:67:35" > /storage/.config/modprobe.d/8812au.conf
or
echo "options 8812au mac_addr=00:e0:4c:37:67:35" > /storage/.config/modprobe.d/8812au.conf

^ this is a complete guess based on 60 seconds of non-specific Googling, so I make no guarantees it will work. It is technically possible to change the MAC via ethtool commands, but really it should be done at driver load time which is what we're trying to achieve.

I don't have the code knowledge to spot if this is an issue with the driver code or not, but the lack of general comments in Google search makes me suspect it's a manufacturing issue where a blank/null MAC address is set in the device. You can argue whether that's a fault as it wouldn't cause an issue in Win/macOS, but it does here. It probably indicates a cheap device where the manufacturer hasn't been assigned unique hardware ID ranges for their devices.

We know who creates the chip. They don't respond to emails in English or Chinese. Neither Amlogic or Rockchip (where we have direct contacts) have any record of an authorised hardware manufacturer using the chip (else they would require accreditation and would have driver sources in their code archives). I'm sure sources will leak eventually, but until that happens we are out of luck.

Make sure you follow instructions correctly. You do not copy the contents of the zip file to the SD card. You copy the contents of the folder within the zip. It's subtly different, but one results in a working "recovery" SD card that will install to eMMC (WP2 has no NAND) and the other does not.

No logs = no problem.

Mount the second partition of the pi's SD card from another Linux distro (macOS and Win can only read the first partition, not the second) to delete the folder. Then eject and reinsert the card, reboot the pi and webgrabplus is gone.

Can't connect to Tvheadend IP sounds similar, and there are a few other threads in Kodi forums that sound the same, but none of them have a conclusion. As it's tvheadend that doesn't start, look at the tvheadend server log for clues.

rm -rf /storage/.kodi/addons/whatever.webgrabplus.is.called

^ will remove the add-on, there is never (or very very rarely) a need to reinstall the entire OS

please run "journalctl -b 0 --no-pager | paste" and share the URL please, we'd like to see details of the device/driver being used

LE settings will list what's supported by the graphics stack. Xorg is full featured whereas devices that run on the framebuffer (e.g. RPi) have a limited set of keyboard options.

btw, connman stores SSID and password info base64 encoded

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "DynamicTwinView" "False"
    Option         "NoFlip" "false"
    Option         "NoLogo" "true"
    Option         "ConnectToAcpid" "0"
    Option         "ModeValidation" "NoVesaModes, NoXServerModes"
    Option         "HWCursor" "false"
EndSection

Section "Screen"
    Identifier     "Default Screen"
    Device         "Generic Video Card"
    Monitor        "Generic Monitor"
    DefaultDepth    24
    Option         "DPI" "100x100"
    Option         "UseEvents" "1"
    Option         "AddARGBVisuals" "1"
    Option         "AddARGBGLXVisuals" "1"
    Option         "UseDisplayDevice" "TV"
    Option         "UseEDID" "FALSE"
    Option         "TVOutFormat" "SVIDEO"
    Option         "TVStandard" "NTSC-M"
    Option         "TVOverScan" "0.80"
    Option         "NoLogo" "True"
    Option         "Coolbits" "1"
    SubSection     "Display"
        Depth       24
        Modes      "720x480" "640x480"
    EndSubSection
EndSection

^ The above is based on the composite output config I used to ship in AppleTV builds. You will need to change the TVStandard option to match your TV and store the file as /storage/.config/xorg.conf and "systemctl restart xorg" to effect the change.

TVStandard    Description
"PAL-B"    used in Belgium, Denmark, Finland, Germany, Guinea, Hong Kong, India, Indonesia, Italy, Malaysia, The Netherlands, Norway, Portugal, Singapore, Spain, Sweden, and Switzerland
"PAL-D"    used in China and North Korea
"PAL-G"    used in Denmark, Finland, Germany, Italy, Malaysia, The Netherlands, Norway, Portugal, Spain, Sweden, and Switzerland
"PAL-H"    used in Belgium
"PAL-I"    used in Hong Kong and The United Kingdom
"PAL-K1"    used in Guinea
"PAL-M"    used in Brazil
"PAL-N"    used in France, Paraguay, and Uruguay
"PAL-NC"    used in Argentina
"NTSC-J"    used in Japan
"NTSC-M"    used in Canada, Chile, Colombia, Costa Rica, Ecuador, Haiti, Honduras, Mexico, Panama, Puerto Rico, South Korea, Taiwan, United States of America, and Venezuela
"HD480i"    480 line interlaced
"HD480p"    480 line progressive
"HD720p"    720 line progressive
"HD1080i"    1080 line interlaced
"HD1080p"    1080 line progressive
"HD576i"    576 line interlace
"HD576p"    576 line progressive

ping codesnake

Kodi Krypton uses a completely different video caching process to older Jarvis releases. The positive of this is that untold playback gremlins are resolved and the codebase is considerably cleaner. The negative is that caching takes a lot longer and this impacts the channel zap speed. There is basically nothing you (or we) can do without reverting/modifying very large chunks of code; which probably breaks more than it fixes. The issue has been communicated at loud volume and with crystal clarity to the required Kodi developers and Kodi Leia should make a great leap forwards (or backwards, depending on your point of view) for this issue. Leia is tentatively scheduled towards year end.

xrandr --output HDMI1 --mode 3840x2160 --rate 60.00

^ something like that

You need to figure out what package installs the host XML::Parser module on your distro, then the build will continue.

autostart.sh is run at the start of userspace boot and the script will execute fully before boot continues; i.e. if you don't want to block boot you will need to (background)& tasks in the script. NB: If you background things there is no guarantee your tasks have finished before Kodi starts. It provides lots of possibilities for fixing and breaking things

The calibrate system in Kodi is a bit dumb because it only calibrates the current refresh rate, e.g. the Kodi GUI default at 60Hz. If you have "adjust refresh rate" enabled and play a DVD at 23.98 (23.976) Hz this will not be calibrated. If you play PAL content at 25Hz (doubled to 50Hz) it will not be calibrated. You need to manually step through each supported refresh rate (or the rates your media will need) and calibrate them all. The fact that you will make the same adjustment in all refresh rates is the dumb part, but at least you only need to do it once..