Posts by arhodiewithsoul

    In the meantime, I'm going to backup my current install of Kodi and then see if disabling NTFS3 (https://forums.linuxmint.com/viewtopic.php?t=398433) and using NTFS-3G will resolve this problem.

    ...well that's a wash.

    Doesn't look like I can 'disable' NTFS3 in favour of NTFS-3G. Apt-get commands are ignored and it appears that LibreElec prevents you from making changes to the system.

    I couldn't figure out how to permanently set NTFS3 to 'Read-Only' for all NTFS mounted drives as an alternative. Someone cleverer than I would have to offer their assistance in this regard, *if* the write aspect is even the culprit. I would have liked to test this theory as it seems that the NTFS-3G default of setting NTFS drives to Read-Only was somewhat more forgiving.

    Crystal mark, chkdsk indicates both 12v HDDs are error free when scanned.

    I don't see that there is anything 'wrong' necessarily in the way I have the system set up; it's maybe just a little inefficient... or maybe not, I don't know (?) It is however, something I understand.

    Anyway, I have ordered a new HDD, will format that to ExFat and carry on.

    jordixPI3
    March 1, 2023 at 7:04 PM

    I'm crosslinking to this thread as it seems to deal with similar issues.

    @arhodiewithsoul, I think your best bet, assuming you have the hardware, is to setup a media server, using Ubuntu or Windows, for the storage of you content then connect to it with LibreELEC via SMB (samba).

    This will also allow you to expand your setup in the future easier (ie. a second TV).

    As far as the drives spontaneously having this issue, either the system was writing data to the drives during a power outage (most likely) or other event that caused the write to not correctly finish, or the drives may just be getting old.

    Thanks again!

    The power outage happened during a storm last week - though the TV was not on and the drives were not being accessed ie: we were not using the media contained on the drives. The RPi is, however, powered on 24/7 (usually) and the drives connected to it, so when the village lost electricity...

    Why is NTFS has a dirty mark and why can't NTFS3 mount dirty NTFS partitions?
    https://wiki.archlinux.org/title/NTFS#Unable_to_mount_with_ntfs3_with_partition_marked_dirty When a NTFS partition is marked dirty, NTFS3 cannot mount this on…
    unix.stackexchange.com

    ... a catastrophic power failure causing a sudden disconnect or incorrectly removing the external drive from the RPi would result in the NTFS drive being marked as 'dirty'.

    "If the partition is marked dirty it means its metadata is inconsistent and using it in read write mode, e.g. for creating, modifying or deleting file system objects may result in a data loss. Normally chkdsk from Windows must be used to fix it."


    Apparently fastboot and hibernation may also result in NTFS disks being marked as dirty...

    You're right about setting up a server - I was effectively using the RPi4 as the 'server' as it's powered on constantly and accessible on my home network. The RPi3 upstairs is only used occasionally and up until now, didn't seem to warrant powering yet another device 24/7

    In the early days (for me ... XBMC on the RPi model B) I used to leave my pc on (with the external HDDs connected) and had the TV's usb port power the RPi on and off when the TV switched on and off, but I suffered a few occasions of corrupted SD card on the RPi (not to mention a horrific waste of electricity!). Having the RPi share the usb drives an act as THE media server was therefore my 'solution' to that problem ever since...


    I'll look into sbc alternatives with Win10/11 as a media server and possibly some sort of dongle for the tv to host Kodi.

    In the meantime, I'm going to backup my current install of Kodi and then see if disabling NTFS3 (https://forums.linuxmint.com/viewtopic.php?t=398433) and using NTFS-3G will resolve this problem.

    Thank you again mattrude, I appreciate your input :)

    So, to continue the conversation above, as I believe others may find themselves in a similar situation:

    I currently have about 4TB of data split over 3 HDDs. I do not currently have the means to copy this data elsewhere in order to format the drives as EXT4 and copy the data back on. Nor do I want to lose the convenience of Win compatibility/ ease of use that NTFS formatting allows.

    Mattrude identified the error in my logs (response #27, #28) and explained what seems to have occurred.

    In order to resolve this, I need to understand more clearly what to do (and more importantly is achievable by me) so as to not waste my time.

    From searching various Kodi specific forums, it appears that this is a common problem, but it is not well understood (by me). At least, I have not been able to find a conclusive solution other than plugging the drives into my laptop/pc and back into the RPi every time I encounter this 'fault'.

    I know that Kodi v19 and RPi 4 was stable. I know that every Kodi iteration since XBMC Dharma and the RPi (B+?) has worked and was stable. So something has changed between v19 and v20 or LE10 and LE11. The avenue I have chosen to blindly walk down is NTFS support with Linux.

    From searching Linux specific forums:

    Kernel 5.15 : ntfs3 vs ntfs-3g
    www.linuxquestions.org

    and

    new driver NTFS3 - Linux Mint Forums

    The links above are to conversations around NTFS3 and the old implementation of NTFS-3G (FUSE) in Linux. It would suggest that similar problems with NTFS drives has been encountered following the adoption of NTFS3 in the kernel (5.15). Subsequent updates to the kernel seems to have resolved some of these problems, but not for everyone.

    Maybe NTFS-3G being a 'read-only' solution did not throw up these errors due to not having 'write' permissions/ capabilities?

    Would it be possible to sudo apt-get NTFS-3G and implement it on my machine (LE11) without causing conflict (with NTFS3)?

    Is it possible to 'disable' NTFS3 in favour of NTFS-3G?

    If anyone with more knowledge on the subject could pitch in and clarify/ explain things better please?

    Many thanks

    Thank you for your reply!

    From reading threads on the Kodi forum, I suspected that this might be the case - I noted that other users have formatted their drives to EXT4. It's strange though that this check has only been implemented with Nexus - the HDDs have been connected to a RPi since XBMC Dharma (2011/2012) days without any issue...

    ...sorry I just re-read your message "or a Linux distro that handles NTFS". So, an alternate solution may be to have to HDDs connected to a Win/Linux (NTFS happy) device and my Kodi RPi remotely access that.

    Some further reading and thinking to do.

    Many thanks for taking the time to investigate my problem and the helpful information contained in your reply.

    :)

    Hi all,

    I'm having similar behaviour with LibreElec 11.0.1 (Kodi Nexus 20) and my external HDDs.

    I have 2x WD Elements with their own separate 12v power source and 1x 2.5" HDD connected via powered usb hub. The RPi (4, 2Gb) is powered by a RPi official product 5v charger.

    The installation of LE/Nexus was clean, YouTube add-on, otherwise vanilla (as far as I'm aware).

    The HDDs (WD) are recognised under 'System/System info/storage' and files are shared over a local network via Samba/ SMB.

    If we have a power cut or I reboot the RPi, the HDDs no longer show. If I pull the power or usb lead, a popup on Kodi states "...device successfully removed".

    If I reconnect the drive/s they are not recognised.

    If I connect them to my pc and allow it to scan the drive and/or 'fix' errors (no errors detected), then eject, reconnect to the RPi, everything works again.

    Separately, the 2.5" HDD sticks in a reading loop where it keeps disconnecting/reconnecting and is unusable. I have tried connecting it through the powered usb hub and to the RPi usb 3.0 ports directly with the same results. If I plug it into the pc, it operates correctly and all files are present, all operations are normal.

    Any assistance offered would be gratefully received.

    Log files pasted to http://ix.io/4yzh