I've been using LibreElec for quite a while now, and have been very happy with it.
My setup is an Asus chromebox that runs LibreElec, which is on the SSD inside that box along with all the config files & the Kodi DB. Plugged into that box via USB3 is a Drobo 5D that holds all my media. (I've been a big fan of the ease and reliability of Drobo solutions for a very long time now.) The volumes on the Drobo are exposed to the network as Samba shares by the LibreElec box. The Drobo is setup with volumes mounted as NTFS.
My primary workstation does things like ripping DVDs, and then I can copy the files over the network onto the Drobo, where LibreElec will pick them up when the library is next updated.
This setup, as I say, has been working GREAT for me for several years.
However, it doesn't work with LibreElec 8, or any of the point releases after v8.
The upgrades will work fine, and the system will happily update the DB, etc. In fact, it will work fine after the upgrade to v8.x, so long as I only read from the volumes on the Drobo. Operations that don't involve the Drobo (like streaming video, for example) work fine. I can watch videos from the Drobo as well, without problem.
However, as soon as I do anything that involves writing to the volumes in a v8 system, Kodi will hang, and the volume itself will become corrupted. A hard reboot of the chromebox will bring Kodi back up, but the volumes on the Drobo will not mount again until I disconnect the Drobo and plug it into a windows box for some chkdsk love (which finds NTFS errors).
At first I thought this was a SAMBA problem, since I would notice it whenever I tried to copy files from my workstation onto shares the LibreElec box exposed on the Drobo, but later experimentation shows that SAMBA does not have to be involved... any writing to the Drobo shares (including things like backing up Kodi settings onto a volume on the Drobo, or using the File Manager interface to copy files from the SSD holding LibreElec to the Drobo shares, etc) causes the hang and volume corruption.
I saw this first with v8, and I've waited hoping that a point release would resolve it, but 8.0GA, 8.0.1, and 8.0.2 all have the same problem.
When the hang happens I can see messages in dmesg that look like this:
[ 902.832530] Buffer I/O error on dev sdc2, logical block 664500664, lost async page write
[ 902.832543] Buffer I/O error on dev sdc2, logical block 664500665, lost async page write
[ 902.832547] Buffer I/O error on dev sdc2, logical block 664500666, lost async page write
It seems that the OS level components in 8.0.x can actually identify the Drobo and have more information about it--the contents of the Hardware logs for the two versions show that v7.x can't identify the drive and I guess just treat it as generic storage, while the 8.0.x versions can tell that it's a Drobo and have a "Binary Object Store Descriptor" that isn't present in the earlier versions.
So I'm guessing that the OS in V8, knowing more about the drive, is trying to use it better/differently, and this is causing the problem, but I'm way over my head here.
Anyone have any ideas how to fix this problem, or failing that how to force v8 to treat this drive as a "dumb drive" like v7 does?
Hardware logs from v7: Old HW File - Pastebin.com
Hardware logs from v8: New HW File - Pastebin.com
dmesg output from v8 crash: dmesg - Pastebin.com
lsmod output from v8: lsmod - Pastebin.com
Thanks.
