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!

Thanks. I've run the command and it's showing a bunch of errors for /dev/sdm1 (the drive in question). I tried a bunch of stuff but then rebooted from the command line as I couldn't get a clean shutdown. Now the device isn't picked up at all, the btrfs dev stats command shows: [devid:1].write_io_errs 66715124 [devid:1].read_io_errs 47572829 [devid:1].flush_io_errs 367590 [devid:1].corruption_errs 0 [devid:1].generation_errs 0 [/dev/sdk1].write_io_errs 0 [/dev/sdk1].read_io_errs 0 [/dev/sdk1].flush_io_errs 0 [/dev/sdk1].corruption_errs 0 [/dev/sdk1].generation_errs 0 And the logs are showing a whole load of relocating messages: Feb 23 11:38:37 bigboi kernel: BTRFS info (device sdk1): relocating block group 3785372205056 flags data|raid1 Feb 23 11:38:42 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:38:46 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:38:46 bigboi kernel: BTRFS info (device sdk1): relocating block group 3784298463232 flags data|raid1 Feb 23 11:38:50 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:38:57 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:38:57 bigboi kernel: BTRFS info (device sdk1): relocating block group 3783224721408 flags data|raid1 Feb 23 11:39:02 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:39:06 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:39:06 bigboi kernel: BTRFS info (device sdk1): relocating block group 3782150979584 flags data|raid1 Feb 23 11:39:11 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:39:15 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:39:15 bigboi kernel: BTRFS info (device sdk1): relocating block group 3781077237760 flags data|raid1 Feb 23 11:39:19 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:39:23 bigboi kernel: BTRFS info (device sdk1): found 4 extents Feb 23 11:39:23 bigboi kernel: BTRFS info (device sdk1): relocating block group 3780003495936 flags data|raid1 Is this to be expected because of the missing device in the pool? Should I run a scrub, or see if replacing the cable restores the device first? Is there a good way of establishing if an SSD is bad? I'm pretty new to SSD drives so the various admin tools aren't obvious to me. Thanks for your help! (latest diagnostics attached). bigboi-diagnostics-20190223-1141.zip

Thanks. Slow reply as I was out of town. Diagnostics attached. Still getting the errors, still no indication in the web gui of any issues and ostensibly everything functioning fine. bigboi-diagnostics-20190223-0934.zip

I have a cache pool of two drives, which has been working fine. Today I got an email saying the regularly scheduled TRIM had failed, so I checked the logs and there are LOADS of errors related to one of the drives in the log, going back at least 2 days, like this: Feb 18 01:18:11 bigboi kernel: BTRFS error (device sdm1): bdev /dev/sdm1 errs: wr 21253557, rd 11461666, flush 205573, corrupt 0, gen 0 Feb 18 01:18:11 bigboi kernel: sd 12:0:0:0: [sdm] tag#22 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Feb 18 01:18:11 bigboi kernel: sd 12:0:0:0: [sdm] tag#22 CDB: opcode=0x2a 2a 00 00 16 32 50 00 00 20 00 Feb 18 01:18:11 bigboi kernel: print_req_error: I/O error, dev sdm, sector 1454672 Feb 18 01:18:11 bigboi kernel: sd 12:0:0:0: [sdm] tag#23 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Feb 18 01:18:11 bigboi kernel: sd 12:0:0:0: [sdm] tag#23 CDB: opcode=0x2a 2a 00 00 16 6f 90 00 00 40 00 Feb 18 01:18:11 bigboi kernel: print_req_error: I/O error, dev sdm, sector 1470352 Feb 18 01:18:11 bigboi kernel: BTRFS warning (device sdm1): lost page write due to IO error on /dev/sdm1 Feb 18 01:18:11 bigboi kernel: BTRFS warning (device sdm1): lost page write due to IO error on /dev/sdm1 Feb 18 01:18:11 bigboi kernel: BTRFS warning (device sdm1): lost page write due to IO error on /dev/sdm1 Feb 18 01:18:11 bigboi kernel: BTRFS error (device sdm1): error writing primary super block to device 1 Feb 18 01:18:11 bigboi kernel: BTRFS warning (device sdm1): lost page write due to IO error on /dev/sdm1 Feb 18 01:18:11 bigboi kernel: BTRFS warning (device sdm1): lost page write due to IO error on /dev/sdm1 Feb 18 01:18:11 bigboi kernel: BTRFS warning (device sdm1): lost page write due to IO error on /dev/sdm1 Feb 18 01:18:11 bigboi kernel: BTRFS error (device sdm1): error writing primary super block to device 1 However, in the web gui there is no indication that one of the cache drives is bad, and everthing (unraid itself, all my dockers) appears to be functioning fine. If there was a serious disk issue I would have expected this to be reported to me? Any ideas how best to proceed? The good news is I have a full daily backup of the appdata share, plus I'm running a pool, so I should be fine long-term. But I'm not sure how best to deal with the issue right now. I'm running unRaid 6.6.6 Any help appreciated!

Ah! Good point... I must have tried with only the old container. Intsalled from http://raw.github.com/disaster123/shairport2_plugin/master/public.xml and it's working great. Thanks! Now that is cool! Been meaning to send you a donation, snoopy. Donation sent! Yes, indeed. Beer donated, thanks Snoopy... Been trying to get this all working for a while

Ah! Good point... I must have tried with only the old container. Intsalled from http://raw.github.com/disaster123/shairport2_plugin/master/public.xml and it's working great. Thanks!

Hi Snoopy, Great work on these dockers - I recently migrated to your LMS docker from dfjardim's with no issues as I wanted the airplay integration, which is working well. I was also hoping to get airplay working the other way - using LMS as an airplay receiver. It seems that some good work has been done on a plugin that can do this: called Shairport2: https://github.com/disaster123/shairport2_plugin I've had a go at installing but can't seem to work out the dependencies. I was hoping you might be able to add it to your container? Cheers.

Just ordered a couple of these from Amazon in the UK with internal only connectors. If anyone's looking for them: http://www.amazon.co.uk/exec/obidos/ASIN/B005B0A6ZS/ref=ox_ya_os_product

Still available? I'd be interested, and I'm in the UK...

Still available? I've sent you a PM - I'd be interested, and I'm in the UK...

Yep, different browser doesn't seem to show the same problem - works fine. Switch back to Chrome (30) and bang! I'll try to get a log of the HTTP request. Is there any logging or core dump that I can enable for emhttp without tom doing a special build?