ConnerVT

I have been running Plex for several years now (since Media Browser switched over to Emby. 2017?). I have only needed to delete codecs a few times. A couple when my Plex server was running on a Windows machine, maybe once on Unraid. So it is not (and shouldn't be) something that happens frequently - If it is, I would check for some other underlying issue. But it is something that can be difficult and frustrating to troubleshoot if you aren't aware of the possibility. I found out about this from mining the Plex forums years ago (back before they changed their forum style). From what I have seen in the Plex forum, and the number of responses I've had here in the Unraid forum, it has been the solution for quite a few people to solve their transcoding/playback issues.

Impossible to answer. It isn't so much what you will be serving, but how much you will be serving. For a non-business server, will you really be serving 100 TB/month?

A Two-for-One sale! Excellent!

Thanks for that. From the dashboard, I was hunting through System Devices and the System Log (which no longer has the boot sequence from a month ago). I was poking around the diagnostic files, but never revisited syslog, as I had looked at it from the dashboard. Now I know the file has all the logs from start of boot, and is not truncated. Good new is that Kingston SSD is an ancient drive, one I've had for nearly a decade. I use it as a transcoding temp location, as I really don't care if it fails, as it has more than given me my money's worth of service.

Just saw these in my syslog from last night. Been poking around, and I can't seem to figure out which drive is ata6.00. Diags attached below. Thanks! Jul 25 22:29:38 Malta-Tower kernel: ata6.00: exception Emask 0x11 SAct 0x30e0 SErr 0x680100 action 0x6 frozen Jul 25 22:29:38 Malta-Tower kernel: ata6.00: irq_stat 0x48000008, interface fatal error Jul 25 22:29:38 Malta-Tower kernel: ata6: SError: { UnrecovData 10B8B BadCRC Handshk } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/c0:28:00:1d:01/02:00:00:00:00/40 tag 5 ncq dma 360448 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/40:30:c0:1f:01/05:00:00:00:00/40 tag 6 ncq dma 688128 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/c0:38:00:25:01/02:00:00:00:00/40 tag 7 ncq dma 360448 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/f8:60:c0:27:01/06:00:00:00:00/40 tag 12 ncq dma 913408 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/c8:68:b8:2e:01/00:00:00:00:00/40 tag 13 ncq dma 102400 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6: hard resetting link Jul 25 22:29:39 Malta-Tower kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 25 22:29:39 Malta-Tower kernel: ata6.00: configured for UDMA/133 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 CDB: opcode=0x28 28 00 00 01 1d 00 00 02 c0 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 72960 op 0x0:(READ) flags 0x80700 phys_seg 88 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 CDB: opcode=0x28 28 00 00 01 1f c0 00 05 40 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 73664 op 0x0:(READ) flags 0x84700 phys_seg 168 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 CDB: opcode=0x28 28 00 00 01 25 00 00 02 c0 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 75008 op 0x0:(READ) flags 0x80700 phys_seg 88 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 CDB: opcode=0x28 28 00 00 01 27 c0 00 06 f8 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 75712 op 0x0:(READ) flags 0x84700 phys_seg 168 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 CDB: opcode=0x28 28 00 00 01 2e b8 00 00 c8 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 77496 op 0x0:(READ) flags 0x80700 phys_seg 13 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: ata6: EH complete Jul 25 22:29:39 Malta-Tower kernel: ata6.00: exception Emask 0x11 SAct 0x1e000 SErr 0x600100 action 0x6 frozen Jul 25 22:29:39 Malta-Tower kernel: ata6.00: irq_stat 0x48000008, interface fatal error Jul 25 22:29:39 Malta-Tower kernel: ata6: SError: { UnrecovData BadCRC Handshk } Jul 25 22:29:39 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:39 Malta-Tower kernel: ata6.00: cmd 60/00:68:80:6f:01/0a:00:00:00:00/40 tag 13 ncq dma 1310720 in Jul 25 22:29:39 Malta-Tower kernel: res 40/00:80:70:89:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:39 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:39 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:39 Malta-Tower kernel: ata6.00: cmd 60/f0:70:80:79:01/05:00:00:00:00/40 tag 14 ncq dma 778240 in Jul 25 22:29:39 Malta-Tower kernel: res 40/00:80:70:89:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:39 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:39 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:39 Malta-Tower kernel: ata6.00: cmd 60/00:78:70:7f:01/0a:00:00:00:00/40 tag 15 ncq dma 1310720 in Jul 25 22:29:39 Malta-Tower kernel: res 40/00:80:70:89:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) malta-tower-diagnostics-20230726-1050.zip

Innostor is the company of the disk controller of the flash drive. My best guess is the company that produced the completed flash drive (Platinum?) saved a few cents, and did not bother to generate/program unique GUID for the drives, but rather left it set to how they received the controller chip from Innostor. So there are likely tens of thousands of these drives out in the world, all with the same GUID, and one of them was already used for an Unraid boot flash drive.

Not a lot of details here to make a solid suggestion. But it reminded me of a quirky thing I saw when setting up a backup server. I have an old GT 710 I put in that server, just for setting it up, configuring BIOS, etc. I noticed that one core would pin to 100% after waking it from sleep (server boots to Unraid GUI). I found that the proc XORG was causing that core to max out. As I had no plans to use the GPU for anything other than the Unraid dashboard, I hadn't bothered installing any driver for the GPU, and it was functioning as needed without it. I ended up installing the Nvidia driver and set nvidia-persistenced, and it is now no longer an issue. I don't know if this will help any, but something you can look into.

Do you have a monitor plugged into the Nvidia card? I had a similar issue some time back, where it would only boot when a monitor was attached. I ended up plugging in a HDMI dummy plug, as I did not wish to keep a monitor on the server. https://www.amazon.com/gp/product/B071CGCTMY

Shooting from the hip here. Looks like Plex having an issues during audio scans (probably during maintenance). If it were me, I would delete all of the files in my Plex codecs folder. This is a common fix for funky encoding issues with Plex, which has been going on for years. Your Plex application will download and reinstall a fresh copy of the codecs automatically. I typically stop the docker, delete the contents of the folder, then restart the container. It may solve the issue. It may not. But worth a try.

I am still looking forward to this happening.

In your case, probably not (see my post above). But Microcenter, like any retailer, is only as good as their supply chain practices. Ten years ago, you would have said the same thing about Newegg. But now that they have become a "marketplace" reseller (as is Amazon), products can be intermingled. I'm sure that Microcenter does not deal with SanDisk and Samsung directly, but buy commodity products such as flash drives from a wholesaler. And these types of products are usually bought looking at who has the lowest price at the time of the order. If you buy a RX4090 from Microcenter, odds are better than 99.9% it would be genuine. can't say the same for a $10 flash drive. I work in semiconductor manufacturing. each year I need to re-certify a training on secure supply chain logistics. Counterfeiting is a big issue in the industry.

Some USB sticks come pre-formatted in funky manner - May have extra partitions which contain backup software, or are just generally strange. I've seen the USB creator tool tends to have issues with this. Wiping the drive clear of all partitions (Windows Administrative Tools -> Computer Management -> Storage -> Disk Management) will usually remedy the issue. Note this not only happens with Unraid's USB Creator. I have had similar issues using the Raspberry Pi Imager, Rufus and other ISO type imagers as well.

20TB isn't an extreme amount to move. Not the fastest to move across a 1GB LAN, but not totally unbearable either. I'll suggest two different options: 1. Treat the new server as a hardware upgrade - Think of it as replacing the CPU/MB/Power Supply/Case. Put the drives from your current server in the new system (including any cache/pool drives). Before shutting down your old server for the last time, be sure to update any plugins and turn off the Start Array Automatically as well as VM and Docker services. Boot from your current licensed flash drive, and sanity check that all runs correctly as expected. Move on to starting the array, Unraid should remember your drive configuration and start normally. You can then start up Docker, and this should also start normally, as your appdata is still in the same place as it was in the old server. Once the system has proven itself functional and stable, you can start swapping out the disks. Start first with the Parity Drive, and let parity rebuild. Then a data drive, and let that rebuild. After this, you can move data from old drives to the new one (assuming there will be less drives in the new system than the old) or just swap in another new drive. (Unraid Docs for details) Lather, rinse, repeat. Some benefits of going this route: Limited amount of down time (as array will be accessible through emulated disk during rebuild); stays true to your current configuration (less chance to name/config something wrong and messing things up); data always 100% in sync between old and new servers during migration transfer; old server drives are in hand as an effective backup in case you have any issues. 2. Create Trial USB for new server - You can build the new server hardware with all the drives as you want in the final server. Create a Trial USB for the new server. Then you need to configure it all. Afterwards you transfer all of the data from the old server to the new server. You can do this via you LAN, or using Unassigned Devices and pulling a drive from your old server, put it in a USB enclosure (or attach internally in the new server if there are available connections, IMHO a PITA) and copy the data. Continue until all is transferred. (Note: You will want to either enable Turbo Write or just not enable your parity drive until all is transferred). After all is done, you can copy the contents of your new trail flash drive over that in the license one (SAVE your *.key file from the old USB config folder first!), then copy the license back to the original flash drive. The benefit of doing it this way (at least, copying by LAN) is zero down time of the server. But it doesn't guarantee the data will be 100% in sync, as a file/folder you copied at the beginning of the process may have been updated/added/changed before all is done copying. But personally think that this is way more prone to error.

It is usually a crap shoot trying to diagnose why without a diagnostic file or much info to go on. Assuming there are no other issues (except for the errors mentioned on the drive being replaced, which shouldn't have any affect), my first guess is that there was some read/write activity happening in the array during the rebuild. That's assuming the ~30MB/s was happening during the rebuild stage. Speeds during parity check/repair and drive rebuild can be funny when there are different sized drives in an array. I'll use my array as an example, which has both 8TB and 16TB HGST drives. Drives access faster on the first tracks, slower on the last tracks. My read access is basically 250MB/s to start, 150MB/s at the end. Obviously when you write, it is slower (and slower still when calculating and writing (parity or data). It takes a few moments for the reads of multiple disks to sync up, then will start off at the fastest speed (250MB/s). As I have 8TB and 16TB, the speed will track that of the smallest drive (8TB), so for the first 50% of the process, speeds will track down to 150MB/s. After it is done needing to access the 8TB drives, the speed will jump back up to 200MB/S, ramping back down to 150MB/s at the end. (Remember this is parity check speeds, read only. Obviously much slower for read/write parity or data rebuild). If there is any sort of array activity happening other than the rebuild operation, the synchronization of the reads gets messed up, so the drives thrash around a bit, really slowing down the drive rebuild.

It is difficult to give advice on a best plan without more details. How much data are you needing to move? Does the current server need to be up and available, or can it be down for some time? Are you putting all new drives in the new server, or will some/all of the drives in the current server end up in the new server? Every migration is different, depending on the situation. The devil is in the details.

A little OT for this thread, but don't assume the fault lies with these player. Could easily be that this version of Plex is at fault, and not playing nice with them. You might want to try an earlier revision of Plex (ideally, one that is known working correctly) to see if this helps. This is one reason I don't jump on the latest Plex release. Those guys always break something when adding something new and shiny.

One additional strategy - Buy a new "old" model of a major, popular brand. Counterfeiters aren't likely to knock off fakes of low capacity and/or "slow" USB2 flash drives. There isn't any money in it, as the buying public is usually looking for "BIGGER! FASTER!" drives. There is little reason to use flash drives over 8GB for an Unraid boot drive - plenty of room for Unraid, and not best practice to use it for other storage as in increases wear and may reduce the drive's lifespan.

I was today days old when I found out about this. Thanks!

I could put this in any of a half dozen threads, but this is the most recent of the @binhex containers I've installed. I have been using NBZGET running through DelugeVPN for the past few years. But with NZBGET development on hold (was hoping the -ng group would pull something together) it was time to move on to SABnzb. Again, you did not let me down. I first loaded the non-vpn version and configured one of my arr containers to use it. Worked smooth as silk. After a few days testing (my boss expects me to work, dammit!) I switched to the SABnzbVPN container and set up for PIA. Again, totally painless. Today, I moved the rest of the arr containers to use SABnzbVPN and shut down DelugeVPN and NZBget (I haven't used the torrent part of the container in well over a year). A Docker cleanup I've been planning to do for too long, and one of the few times everything just worked as it should. Enjoy a beer, and some pizza, as a token of my appreciation. My thanks to you, for all you provide to the Unraid community.

Thanks for the quick reply. Was second guessing myself, wondering maybe I *did* have it set to Latest before. Wasn't much of a concern for me. The GT710 is only in the system from when I first set up the server a few months back, and the Ryzen 1500X doesn't have a iGPU, so needed something to config the BIOS. I agree the GT710 is almost worthless. It's one strength is it is the cheapest GPU that allowed you to install Win10. So it is the card in the drawer, when I need a card... 😉 I follow the Nvidia Driver thread, and know some folks have a need for not running the Latest driver version. Just thought I'd give them a heads up to check after updating their OS.

I decided to stick my toe into the water and updated my backup server from 6.10.3 to 6.12.3. The system is as bare bone as can be - No parity/cache/Docker/VM. Just a basic PC with 3 HDD plugged into the motherboard. I wanted to start playing around, checking the new Dashboard interface and have a look at what has changed. The update went with no real issues. One thing I did observe: I had updated all my plugins before updating. The Plug In Helper did again update the Nvidia Driver plugin. I am pretty certain I had it set for v470.129.06 (though not 100% sure), as I have an old GT710 in the server. After rebooting, I found it was set to Latest. I recommend that those of you who are not using the Latest driver for some reason double check that the setting is what you wish it to be.

If you have the same GUID on multiple flash drives, they are most certainly counterfeit and not from SanDisk. GUID stands for "Globally Unique Identifier", the equivalent of a serial number. The GUID is programmed into a small NVRAM that is part of the flash drive's controller chip. SanDisk will generate a different GUID for each flash drive it manufactures. Someone making fake drives likely won't be bothered to do this, as it costs more time and money to do so. Sorry you got burned by buying a not genuine part. Earlier you said you bought the 3-pack for cheap. Now you understand why it was inexpensive.

It doesn't take much of a power sag or spike to disrupt a system. It doesn't even need to be perceptible to you by the light flickering. A UPS does more than keep your server running when the room goes dark. All but the least expensive ones also provide power filtering to smooth out these low/high voltage situations.

Well, there *are* quite a number of "Post Diagnostics" But seriously, I add my thanks and appreciation as well. I can't count how many times I've opened the General Support sub-forum, and have seen JorgeB's avatar down the entire right side of my screen.