Thanks. I guess all I can do is try things again and hope something works differently this time.
One thing I did notice is that my synchronisation program (written in Delphi and using standard windows API calls (ShFileOperation) was running at very slow speeds on copying a file from the 6TB HDD to backup eg over 2 minutes for a .nfo file. With the RPi3 the same operation takes a few seconds.
Thanks for that.
Before I install the latest nightly I do have one more question. My new 6TB powered Seagate Hub (2 USB ports) was corrupted 3 time whilst hooked onto the RPi4 - last time under LibreELEC-RPi4.arm-11.0-nightly-20220820-b2dced8. The same HDD is happy on my old RPi3 setup - absolutely no problems. The only thing I know would be writing to the HDD is samba.
Long preamble - my question is what are the chances that it was the incomplete implementation of samba that caused the corruption? I do know that I forgot on several occasions to access via \\server\folder and received the can't find it message.
Sorry to be a pain but does this mean that samba is now working fully and correctly? I read the github entry and cannot understand it (no surprise there) and tried googling to understand dcerpc and srvsvc - good way to waste time 
petediscrete
Thanks for the suggestion. I'm skilled with Windows not with Linux (4 Windows PCs to 1 Linux one) so I would have no idea what I'd be looking for apart from the disk becoming corrupt again and spending another 12 hours copying all the files back. The 6TB HDD was connected to a USB3 port on the RPi4 (and is currently plugged into a RPi3 USB2 port), only for population was if connected to the Windows PC.
If you can expand on your suggestion I'm willing to give it a go.
The story so far for the 6TB HDD:
1. copy 4TB of files of backup
2. run Windows app (homebrew written in Delphi) to modify 6TB HDD file names and .nfo to reflect name changes
3. set up the RPi3s (LE 9.2.8, Kodi 18.9), removed sources and cleaned database
4. plugged 6TB HDD in
5. set up new sources and loaded database
6. no last played information
7. Exported database just in case nfo format was different
8. was told I'd forgotten about advanced settings.xml
9. use Windows via SAMBA to a) delete nfo files (c 7200 of them)
10. use Windwos via SAMBA to copy nfos from backup to 6TB HDD
11. removed sources, cleared databases, reset sources loaded database
12. everything fine
That pretty much confirms to me that the HDD is OK. I'm wondering if the incomplete implementation of SAMBA on the RPi4 could be responsible for the disk corruption. I can see no reason why Kodi should be writing to the sources unless I export the database and any file manipulation I do is via SAMBA so it will be writing to the disk.
Any thoughts?
I tried to connect it to the RPi4 again - not recognised. This time when I connected to my Windows PC it asked to scan and fix - FUBAR. I have for now given up on the RPi4. I do not know where the problem is but I suspect LibreElec. It may be the Pi but lack ability to test it. I'm going to swop the new 6TB HDD onto the old RPi3 system and see if it gives problems. If it does I'll apologise to LibreElec.
Any suggestions on how to test the Pi welcome.
System is setup on 128GB SSD.
Chkdsk and other disk testing utilities run on Windows PC and no problems identified.
The Seagate is set to spin down after 15 minutes same as the other Seagate 6TB HDD I had on the RPi3 setup which has run since 2018 with no problems.
A little more information - I took the HDD back to the Pi and its refusing to recognise it. Tried a different cable - still not recognised, tried one of the USB2 ports - still no joy.
Configuration:
LibreElec 20/08/2022 nightly, Amber skin loaded but not used, Shadertoy visualisation loaded, TVheadend server & client installed and running
RPi4B 4GB, 128GB SSD (for boot etc), 6TB Seagate Backup Hub NTFS formatted (films etc) with Haupage tuner & wifi keyboard dongle plugged in, ethernet,
I have posted about HDD corruption before but now I've lost a complete folder. I have three top level folders on the 6TB HDD - Films, MVids, Records. In Films I have folders A to Z with sub folders if there's a series (eg 'Allo 'Allo). This morning checking something I found I've lost the entire contents of Films/A. The folder is still there but there's nothing in it. Fortunately I do have backup but its more than a little disturbing.
The RPi4 has been running since 20/8 but has been rebooted via the menu on occasions. I have pulled the HDD from the Pi and checked it out on Windows since I have better diagnostic tools there and can find nothing wrong apart from the fact that stuff has gone missing.
Does anyone have a suggestion (or an explanation) that does not involve reformatting to Ext4 since that is not a viable option.
Joe
"a FS gets corrupt when a disk gets unplugged or a power cut, while the FS/disk is in use.
and "being mounted" translates to being "in use", here."
WOW! To my Windows centric eyes that seems like a major design flaw.
Hias
"Or just use the "remove media" option from the context menu in the video files view."
I knew it was there but assumed that I'd need to recreate the source and re-scan to the database. I've obviously misinterpreted as I did with EXPORT for videos.
This reply because its the only way I know to mark the thread as resolved
Thanks - I'll go and zap some files.
Hias
Thanks for that. The 6TB HDD did have an extra partition on it (can't remember how it was formatted) but it was rapidly removed with Mini Tool Partition Manager and the whole thing formatted to NTFS.
Your's and Joe's comments pretty much destroy my theory. I'll just have to hope it doesn't recur.
"your thought/theory are unlikely"
Agreed, but it is the best fit I have to the facts I know
"against the "boot theory" and for the "dear Pi don't boot my external drive":
usually LE is configured where to boot from during LE installation.
with the UUID's form the disk what is attached during installation."
OK, but all I could find while searching was you can toggle between SD card & USB device as the first one to look at. What I have no idea about and why I thought disabling boot from specified disks is what happens if LibreElec starts its boot from SSD and then tries to spin up the HDD and fails? I know the Pi will close down but I have no idea what else its doing.
"mostly a filesystem gets corrupt when the drive is disconnected while being in use/mounted (e.g. hard power cut)."
We do get the occasional power cut or voltage fluctuation in the Highlands (not as many as I expected when we moved up here though).
The RPi4 is connected to a 128GB SSD for boot and a 6TB HDD for source (videos, records). The 6TB HDD should not be written to unless I carry out a media export and I do not recall ever seeing a disk / memory stick corrupted simply by unplugging unless it had been written to and items not flushed to disk.
OK my experience is primarily Windows based so Linux / LibreElec may be different.
Running 20/08/2022 nightly on RPi4, using Local information only with .nfo and .jpg files for each video
I've turned off Download actors thumbnails & Extract thumbnails from video files.
However, when I backed up and copied the tar over to my Windows PC I have c160MB of thumbnails.
1. Is this a LibreElec or a Kodi question
2. How do I stop the thumbnails being produced
3. Am I safe to just delete storage\.kodi\userdata\Thumbnails\
I'm still trying to understand why my 6TB USB HDD became corrupted twice. I think the first time was because I hadn't powered up the drive before turning the Pi on. I have a theory that the second time could have been caused by the Pi trying to boot from the 6TB HDD rather than the 128GB SSD even though the 6TB drive was powered up.
I don't think its going to be possible (tried googling but haven't found anything to support the idea) but I'd like to be able to say to the Pi - "you can boot from the SSD but not the HDD" by USB port, disk name or anything. Is there a way?
okay, next time please mention in your questions that your're not really interesting in answers, safes some time here ...
The question was
"What does anyone here think? Likely or not?".
If you are interested in answering that I'm interested.
If you are looking for cross platform compatibility, use NTFS. Both NTFS and exFAT are not native filesystems for Linux and NTFS implementation is older and more mature.
Turn off hibernation in disk settings. If disks shutdowns on its own while being mounted, it can only cause mess. Disk should be stopped by OS and not other way. If your storage thinks that it is smarter than OS, you have to use synchronous file system without journal on it.
Thanks.
"Filesystem performance is less critical than device performance."
fully agree with that
I'm convinced the "somebody" doesn't "attack original poster", but "attacks" the OPs wrong attitude what prevents to find the answer for his question(s) himself.
please learn to read the differences in the sentences !
Interesting. I hadn't realised that asking questions here was forbidden. After all if I'm to find out the answer for myself I shouldn't be asking anyone. I was also unaware that you were watching and discounted my efforts googling for information and trying physical tests to see if I could recreate the problem.
As a matter of interest. Did you look at the Wikipedia article, and if so how would it have helped answer my question? I ask because I'm always interested in learning - even at 70.
The expense is worth it
I would have agreed with you totally whilst I was still working and running a small IT Department. As a pensioner who had a large percentage of his savings disintegrated by the Credit Crunch my attitude has changed a bit <G>
there exists a comparison of filesystems in wikipedia, search for it
I did a lot of web searching before I posted here. The vast majority do a bit of a pro & con list with zero evidence to support anything. Wikipedia have a very detailed entry if I was interested in technical specs. I'm not.
