cp /storage/.config/samba.conf.sample /storage/.config/samba.conf
nano /storage/.config/samba.conf
<make changes, save, exit, etc.>
rebootIn LE the /etc/ path is inside a read-only file so cannot be edited, but renaming the samba.conf.sample file and editing does the same thing.
Did you interrupt syslinux and type the command? (correct) .. or boot into the installer and type the command? (wrong)
No idea on the boot/reset issue. You need to force recovery boot if the device has been running CE else the u-boot bootscripts are looking for the wrong files; but your description says you've seen the Kodi home screen which would mean you've gotten beyond that issue and first-booted the box into LE.
You can use the same video= line but chage the resolution to 720p. Kodi can only handle progressive output so will ignore 1080i resolutions.
Otherwise it's pretty much impossible to "guess the issue" without UART logs from the box.
Upstream u-boot has no support for Amlogic proprietary restore image formats and sequences.
No idea what the issue is, but if the nightly works, use it, you'll find it's quite stable (Kodi is overdue a move to Beta).
Removing "quiet" and adding "ssh" to the APPEND line in uEnv.ini will result in console output on-screen (although it tends to dump text to screen faster than most eyeballs can track anything) and forces SSH to start so if boot has reached userspace (maybe) you might be able to connect to the box and poke around to look for issues. Something else to try is adding "video=HDMI-A-1:1920x1080M@60" (all on the same line) to force DRM output to 1080p; in case it's trying to use a 4K mode and disagreeing with the TV panel in some way.
Kodi displays a percentage indicator on-screen when playback stalls and the 'stream' needs to be buffered again. There's a multitude of reasons for a stream to stall and never recover, but the main candidates are a bug or something in the hardware decoder, or something in the media that ffmpeg doesn't handle right.
Things to try:
a) Disable DRMPRIME and hardware decoding. If the media now plays (software decoded) the issue is in the hardware decoder.
b) If not 'A' the enable things again and update to a current LE12 nightly since this has newer everything
c) If not resolved with 'B' share a reasonable snippet of media so that Pi engineers can have a look.
And if posting again, share a debug log that demonstrates the issue.
You cannot write (dd) anything from the u-boot console. Even if you could, you would fail writing to emmc since that's what the device has booted u-boot from (at some point you overwrite the code you're running). The board should boot from USB in addition to SD though; although you might need to manually start USB from the usb console before manually running bootscript commands.
Specs claim that it's an S905 (GXBB) so the AMLGX "box" image should work from SD card. You'll need to experiment with different "gxbb" device-tree files to see what works best. Read: https://wiki.libreelec.tv/hardware/amlogic#box-images
You happen to have a dd backup of the Wetek Hub factory image?
I am about to use emmctool and want to verify that the Play2 chip I am about to flash is a qualcomm?
Nope. Amlogic S905.
Library databases are in /storage/.kodi/userdata/Databases (from memory) as versioned sqlite .db files, e.g. MyVideos121.db; the databases are not .xml files.
What do you think about a LE 11 support for PI 5 ? Is it possible?
If yes, must we have to wait for a Kodi Nexus 20.3 release?
Kodi still has the intent to make a 20.3 release but there are complications with shipping another K20 Android release via the Google Play store as Google now requires a minimum API version that's higher than K20 implements (and each API bump typically requires some finessing in Kodi code). The route forwards hasn't been agreed yet.
If/when/once https://github.com/LibreELEC/LibreELEC.tv/pull/8181 is merged support will be in nightlies; although personally I'd still prefer the team to focus on an LE12 release; while LE11 compiles fine I'm not sure anyone put some testing miles on it and users expect "stable" releases to be, well, stable.
I think we reached the point where the current legacy driver needs to be bumped from 340.xx to something newer due to compat issues; but this will inevitably drop support for older nVidia devices. Or we drop nVidia support completely.. because stats show that most of active nVidia installs are using the legacy driver (the non-legacy driver has few users).
I rather doubt anyone on staff will leap down the rabbit-hole of trying to describe something that complex to a novice user. It can be done, but it's one of those topics where if you need to ask how it's done you probably shouldn't be doing it.
Plan B: Move the data somewhere else. Reformat the drive. Move the data back .. this is much (much) easier.
Where do I start looking for a solution please?
What add-ons are installed?
