Posts by chewitt

re-reading and noticing "failed: Host is down" .. is the "server" pi on a static DHCP reservation? .. or did the IP change?

NB: I use hostnames for mounts/sources and static IPs or static DHCP reservations for anything client devices need to access.

For kicks you could try this image on a spare SD card LibreELEC-AMLGX.arm-9.80-nightly-20200324-aeb6e84-box.img.gz - It won't be great for playback (still a bit experimental) but might help set the u-boot environment up better. I've had issues with other Beelink firmware; to make things boot quicker some of the normal wait points in the boot sequence are time-reduced which makes it harder to release the reset button at the right point to trigger the u-boot recovery mode (which is how the toothpick method works).

Read Compile [LibreELEC.wiki] .. checkout the "libreelec-9.2" branch and "PROJECT=Generic ARCH=x86_64 make image" to compile. Once you have a working image you need to edit packages/x11/driver/xf86-video-nvidia-legacy/package.mk and bump the driver (change version and remove the SHA256 hash) and re-run the build command. If you're lucky it will download/build/update the legacy driver. Test the image .. but don't get hopes up. You may actually be better off with an older driver version, but the best way to achieve that is to clean install and test older LE releases (9.0.2, 8.2.5) which will have older drivers embedded. NB: If you find that works you won't be able to simply revert the version in the current LE 9.2 package to much older versions as at some point the old driver will lose ABI compatibility with newer x11.

The board will likely be more stable without hdmi_enable_4kp60=1 but mostly it only enables 4K modes you don't need.

Can you create a sample file .. 100MB or so of the movie from a scene where you see skipping? - we are always on the search for bad media and/or things that stress playback for the Pi Foundation developers to look at.

Only PCM output is supported at the moment.

Nice. I recommend you upload the documents to GitHub or a maker website and share the link. Don't wait to be asked!

RPi4 does not support WOL because the board is completely unpowered when "off" so the Ethernet device is not awake to receive the WOL packets being sent. The exception is when using POE (Power Over Ethernet) as the HAT is both powered and responsible for powering the board (so can turn it on).

Nothing looks wrong with the .mount file. What OS/distro (and version of Samba) is the pi "server" running? LE or something else? .. If not LE, share the smb.conf for the server so we can see what SMB dialect(s) are being set (or defaulted).

Kodi web interface is on port 8080, e.g. http://192.16.2.20:8080 <= replace with whatever the IP is of the LE device. There's a remote control in the web interface so you can navigaate around. If you don't understand how to use Kodi read Official Kodi Wiki

I use Ethernet .. because I rip discs with a high quality level and WiFi is rarely a reliable medium for streaming large files. I like reliable.

WiFi issues are always part environmental in addition to hardware/software. I can't explain why your pi does not reach AC speeds. I'm not sure anyone else can either. I don't expect WiFi performance from an RPi4 though; the design priority on a pi board is basic connectivity so that kids can do "online" things and develop fun stuff.

The crash logs stop at the point where Kodi creates an OpenGL context so it's reasonable to assume there's an issue with the driver. The 8300 is on the "supported" list for the 340.xx driver but I doubt it's been properly QA tested in years - the focus is always on newer cards. You could try self-building with the latest driver bump (we are using 304.107 so it's a macro change) .. I'm not sure you'll get too much interest from staff on chasing support for super old kit as the 8300 was launched 13-years ago and an RPi3 beats it hands-down on playback performance.

Chorus2 is the Kodi web interface (can be changed for others, hence known by skin name). RPi hardware has never been known for high performance WiFi so I'm not expecting it to be brilliant. If the changes made didn't change anything .. next step is to disable the onboard WiFi and use an external device with a proper antenna. Before you ask .. I have no recommendations on hardware (other than to use Ethernet because wireless sucks).

erbas experiment with the images in Index of / too .. I lost track of what Oleg is doing with boot scripts in his images and it's another point of reference on any issues that you see.

I flagged it to one of the kernel maintainers (Neil) who supports LibreComputer.

1. Yes, Chorus contains a web-based "remote" which can be used to navigate the GUI to access the LE settings add-on. You'll need to be on the network first for that to work of course.

2. Run this command and reboot: echo "options cfg80211 ieee80211_regdom=FR” > /storage/.config/modprobe.d/cfg80211.conf .. this will change the wireless regulatory domain to French specs which should better match the radio properties of the router, which may help. Wireless radio properties are not as simple as "n vs. ac" but that's the limits of configuration. LE10 in the future will move the config of regulatory domain to the GUI. Bonne chance!

Does it work if you change "python" to "/usr/bin/python" ?

If your (unknown) LE device supports WOL packet wake-up then you can use that option. If the (unknown) device does not .. there is no magic feature for turning boxes on. ESP would be cool, but we've been trying that for years while drunk and still can't get it to work

Two important points:

a) LE add-ons are compiled and packaged for LE - so I wouldn't expect them to run anywhere else. We do not publish a repo installer (the files are embeded into LE images) and even if you managed to get past that; when it doesn't work we have no interest in trying to fix anything.

b) The Chrome browser only exists for x86_64 hardware so there is no Chrome add-on in the Pi add-on repo anyway.