So it is in a way self powered. It’s not drawing power from the Pi but from the SATA interface if correct?
Since it’s the boot device, it would be difficult to give it a good test on the Pi.
That would be correct. However, the power supply is physically mounted in a small chassis along with the RPI 3, HDD, and misc. connection “blocks”. The p/s is not portable. Like I said, prob’ly easier just to use the SATA in the Fedora box.
You could always install Raspbian on a SD card and test the drive that way.
I hadn’t thought of that. Makes sense. I wouldn’t have to remove the HDD from the chassis.
OK. Doesn’t sound like such an issue anymore. Thx!
Been awhile, but finally got the chance to look at things a bit more…
UPDATE1:
Just had the chance to check out the USB-SATA interface I’m using for the HDD and got the same results as having the HDD connected directly to the SATA bus: Everything looks good.
I sorta got the sense that something is triggering the freezing of OSMC (sometimes I can ssh into the system, other times not 
Open to suggestions (and insight) how I might track this down. Thx.
To refresh…I have set up my system to boot from the SD card with everything else(?) located on a 1TB HDD. I have been getting unknown system freezes and cannot tell what’s causing them.
I tried the suggested idea (sounded the easiest) of inserting a Raspbian SD card in the RPI3 to test/repair the HDD but could not seem to get it to work (if I unmounted the HDD, I couldn’t get fsck to find it So I finally removed the drive from my PVR and installed on my Fedora 30 box.
I was then able to unmount it and run fsck on it. 1st time I ran:
fsck -p /dev/sdb1
and got results:
fsck from util-linux 2.33.2
/dev/sdb1: clean, 150394/61054976 files, 146633270/244189952 blocks
I then ran it again:
sudo fsck -f /dev/sdb1
and got:
fsck from util-linux 2.33.2
e2fsck 1.44.6 (5-Mar-2019)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: 150394/61054976 files (0.3% non-contiguous), 146633270/244189952 blocks
So, it seems the drive is actually OK. I am using a USB-SATA intfc which has been working, but I may bring that over to my Fedora system and try the same testing again.
Curious question…even tho the SD card is used only to boot, does OSMC/Debian write to the SD card and maybe that has developed issues? I guess I could find a way to plug it into my F30 sys and run fsck (or another diagnostic) on it. Open to suggestions on that.
Any good diagnostics for the RPI3? Something I could download to a SD card and have it boot into a diagnostic suite?
Thx in advance.
The SD card is just providing the Pi’s configuration and a boot path. Since OSMC (that’s on the hard drive) starts booting then the SD card is doing what it is supposed to do. It seem fruitless to follow that path.
As for the rest you determined that the issue was inside of the Kodi install. It was working with a clean Kodi folder, and then when you restored your old one the problem returned. Obviously something went wrong and it messed up some file/s. With a system that has had a single failure with no other people reporting the same it would likely be both impossible and impractical to figure out why. If you had a situation where you could say “when I do this, that happens” then you have something you may be able to figure out. As it stands you just have a random failure. After two months I would think your best bet would be to just start over from scratch and just chalk it up to bad luck. If the setup is that troublesome then I would make a backup after you get it all done just in case you do have some kind of a fault that repeats itself.
Thanks much for the help. At this point flattening the HDD and going from scratch is prob’ly the right move (rather than trying to sort this out). Guess I have another project added to my list 
Does seem like something somewhere glitched and created some kind of error in the system (might have been some odd write error during a nightly TV program guide update). The system had been running so well up till then. Sighhhhh…
If nothing else, it gives me a chance to clean out any possible system incompatibilities that might have crept in as I upgraded versions along the way.
So, if I understand you correctly, the only time the SD card is written to (if at all) would be if I (or some code) changed something that affected the RPI’s profile? I know SD cards have limited write life.
Anyway, appreciate the support…cheers…
Unless you programed it otherwise that should be correct.