ctrlbreak

FYI - I tried mounting the data disk with UD, but it complains about a clash with the (emulated) device: May 13 21:08:43 bigboi kernel: XFS (sdn1): Filesystem has duplicate UUID 041b0c28-6d93-4c28-89e4-c85ff7eef5d2 - can't mount May 13 21:08:43 bigboi unassigned.devices: Mount of '/dev/sdn1' failed: 'mount: /mnt/disks/WDC_WD140EMFZ-11A0WA0_9RKDW2VC: wrong fs type, bad option, bad superblock on /dev/sdn1, missing codepage or helper program, or other error. ' May 13 21:08:43 bigboi unassigned.devices: Partition 'WDC_WD140EMFZ-11A0WA0_9RKDW2VC' cannot be mounted. Any ideas how/if I can mount it on the same server?

I'm going with your suggestion itimpi - thanks! If it turns out I find data corruption I will have the data disk just in case.

Very hard to tell - it's primarily large media files, so there could be corruption to them. I don't run regular hashes/file integrity checks (maybe I should start!). But, being paranoid, what would cause so many parity errors/corrections from that last parity check? The server had been mostly idle since last parity check (due to aformentioned internet outage), so I doubt a lot of data was written to disks... makes me suspect that there was something else weird going on, so I wonder if it's worth digging deeper into the errors (no logs, sadly). I suppose I could try to compare the emulated disk 4 with the "real" disk 4 to look for any file hash discrepencies...

Hmm, after a bit more investigation, the plot thickens. I actually now recall I had a power cut on 4th May, during a monthly scheduled correcting parity check (it started. I only powered the server back on today (long story due to our internet being down etc etc) to find the two red-balls. And it looks like it was a pretty weird parity check from the data on the dashboard (see attached, but 1953506633 errors!?). I now suspect that the backplane may have gone bad during the parity check. But that means I'm not sure whether to trust the data disks or the parity. But I'm leaning towards the data disks given that if that error count is correct, it could have written bad parity data? If that's the case and I want to trust the data disks, how do I force a parity rebuild with 2 parity disks, 1 of which is currently red-balled? Thoughts? Thanks!

I have a slightly dodgy supermicro 5-in-3, which sometimes seems to cause read errors/redballs. I've checked all the SATA cables but I think it might be a power thing. Obviously I need to sort that out! But this time it's hit 2 disks at the same time: Parity 2 and a data drive. As I see it I have 3 options: 1) new config and force the disks back to good status (I hear this is a bad choice?) 2) rebuild the data disk to spare disk, then the parity to the data disk (I have a spare - safer this way?) 3) rebuild the parity disk to spare disk, then the data drive to parity disk. I was planning either 2 or 3. Any recommendation which way to take it? Thanks!

Force update sorted it - now 8.2.0 TRUNK. Odd that it wasn't showing an update available in docker. Thanks!

Hey Snoopy. I notice that LMS 8.1.x is now out but the latest container image from your repository seems to be on 8.0.1. Is this something we can manually update or do you have to create a new image? Thanks.

(delayed reply here, thanks for bearing with me!). The thing is, had been up for 57 days, completed a previous parity check with 0 errors since shutdown. Definitely no unclean shutdown since last good check. Could it be dodgy cabling/SATA crc-type errors causing this? My main question was how/if I could investigate in more detail as I don't seem to have logs that go back far enough in any case. The more principled issue is - in this case is correcting or non-correcting the right thing to do? That is, is it the data on parity disks that's wrong or the data disk(s). I guess having dual parity makes it less likely to be the parity disks?

Non-correcting check ran fine, 0 errors. Diagnostics attached in any case. bigboi-diagnostics-20200910-1343.zip

Hi all, Long time user and mostly lurker in the forums, have self-served most issues I've had including dirty shutdowns, weird upgrades, HDD replacements and data loss issues in the past. But... this seems quite a vanilla question, but I'm not sure how to investigate what/if this issue is something I should be concerned about? My monthly parity check just completed and found/fixed 333 errors. Server has been up for 55 days and the previous check was 0 errors. Where do I start to investigate if this is a significant issue worth more investigation? Diagnostics attached, and thanks in advance! Patrick bigboi-diagnostics-20200908-1307.zip

Update on this - I've done some more digging and it seems that the problem is exclusive to wav encoding in shairtunes, it's working fine on flac and mp3. Not sure if this is directly a shairtunes issue or a missing/incompatible enconding library, the logs don't seem to help, but will carry on investigating, but for now have it working

In host mode. And I've not changed that I don't think. It was definitely all working previously (for years!), so I'm not sure what I've done to mess it up, or whether it's some 8.0/config issue.

Thanks for your work on this docker Snoopy86 - I use it daily and did even contribute via paypal once! However, since the 8.0 update (I think - the timing seems to be right) I get errors when I try to send airplay from my phone to one of the players (using shairtunes2 plugin). The player gets all the metadata and tries to play the stream, but can't seem to connect back to the server. Have you seen this? I checked and the shairport is listening on the port that the player is trying to connect (I was surprised to see it uses a random port which isn't explicitly mapped in docker, but it seems to - and I can manually connect and retrieve the stream from a remote command line (using http). Any ideas? Thanks!

Seems that Plex now supports Linux HW decoding AND transcoding on Nvidia: https://forums.plex.tv/t/plex-media-server/30447/286 Will this work with unraid and docker passthrough? What drivers might be required?

Great, thanks for the help. Hope the SSD is not bad, though it's under warranty if it is. Good job I had a pool - only got the second drive about 3 months ago!