Posts by chewitt

    LE10 and earlier use NTFS-3G via FUSE to mount NTFS drives. LE11 switched to new(er) in-kernel drivers so you'll see a significant increase in file read/write performance. However the in-kernel drivers appear to be a little more enthusiastic about flagging issues; hence the change in behaviour that users are seeing.

    LE normally does fsck before mounting drives but there is no fsck.ntfs utility to do this (ext2/3/4 etc. use /usr/sbin/e2fsck). In the past there was an fsck tool from NTFS-3G and I'm wondering if we might need to restore the package; not to switch back to the older driver, but to build and pick the fsck tool to the image.

    Kodi allows drives to be selected and unmounted in the file browser, but otherwise the GUI doesn't have an easily accessed option and you'd need to create an unmount-all script and then map the script to a custom remote keymap.

    The SD card will be /dev/mmcblk0 so as long as that /dev/device exists you can test writing with "dd if=/dev/random /dev/mmcblk0 bs=1m" and the OS will write random data to the entire card. It will take quite a while (larger card size = longer time) but if there are problems with the card (or reader hardware) it'll throw errors and hang/halt/barf on the task. To state the obvious; this will trash whatever data is currently on the card :)

    AirPlay etc. require the router to replicate broadcast traffic that advertises the service on both wired and wireless segments. Some routers do that, and others don't. If the RPi cannot see the WiFi SSID; common reasons would be the SSID being hidden (ConnMan cannot see something that is not being broadcast) or the wireless regdomain might need configuring to align the radio properties.

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

    In the absence of debug logs I'd make an educated guess that the keys that underpin the S in SFTP changed on the Synology side and while FileZilla is configured or defaults to ignoring that Kodi will probably flag the mismatch and fail. I'd have thought that kind of thing would be relatively obvious from logs though (although I never used SFTP for anything). See if clearing /storage/.ssh/known_hosts (or the old entries for the IP/FQNDs of the Synology target) makes a difference?

    So... I'll try this N100 fanless adventure, for 235 euros... It's more than 150 euros on RPi 5, but not so much (especially if it lasts 8 years also)... And the N100 is more future proof...

    Estimated shipping in December 2023 as long as they accumulate enough backers. Dates on Indiegogo are often a little optimistic so good luck with the purchase :)

    If it was already installed (and thus appended to $PATH at boot) the removal didn't alter $PATH in your current session and hence it should have been disoverable after reinstalling. If you uninstall > reboot > install .. it won't work again until another reboot or logout/login.

    Normally the "Disable SSH Password" option is used after configuring certificate authentication instead. So turn off the disable to allow SSH passwords again. If necessary (re)set the current password: there is deliberately no need to know the current one, it's just overwritten.

    I was wondering if the box was finding an older /storage partition from the older install, but blkid shows none of the partitions that exist on eMMC have partition GUIDs or names that would match so that's a dead end. And I meant "ssh" before, so that's not an issue.

    You did mention running a custom OS and not the stock one, but I don't really see how that could impact on Linux since the box is still booting (vendor u-boot) and hooking it to boot LE from SD card. Both stock and current OS are likely to use the same u-boot code.

    There's a pattern where services are waiting for things on the SD card second partition (/storage) to become available which results in some messages in the journal log, and the overall speed of boot looks a little slow to me. However I'm used to looking at logs from devices that boot from faster eMMC so that's just perception, and my boot logs also show similar messages: and ultimately /storage does mount and things do continue. I can't explain why the sshd.conf file hasn't been created automatically, but perhaps related to the second-boot failure to mount the storage partition. However boot scripts should still detect its absence on third boot and create that conf; it's not a one-time/first-boot only thing.

    In short, I'm a little stumped /shrug

    EXT4 is often recommended here but what I don't know is how resilient is it. Will LE/KODI/EXT4 handle a power outage or is a repair going to be needed or what?

    EXT4 is pretty robust but when it comes to power outages and the "what will I lose?" question, the reality is a dice roll with too many variables for anyone sensible to profer a guaranteed answer. The real question is "how much loss will you tolerate?" and then you spend appropriately so risk matches risk-appetite. As an example: I've invested thousands of man-hours ripping and recording a large private CD and Vinyl collection into FLAC format a few years ago and have zero plans to ever repeat the hurculean task. So I've spent on a local NAS with multi-disk redundancy and this is background sync'd over the internet to a second NAS parked with a relative with a fast internet connection. So I have both local and off-site redundancy on a multi-terrabyte media hoard. The proverb is "There are two types of IT user: those who take their backups seriously, and those who didn't lose all their data yet" :D