jkBuckethead

Apologies in advance for yet another plex transcoding thread. I read a bunch of them and didn't find anything that addresses my issue. I just recently added a P2000 to my system, primarily to provide additional horsepower while processing A LOT of files using TDARR. TDARR setup went fine. I added the Nvidia driver plugin, added the Nvidia variables, selected the Nvidia plugin within TDARR. It has been chugging for over a week and has already saved me over a terabyte. Up till now, the iGPU in my i5-12500 has been more than adequate for my modest plex transcoding needs. In fact, I still plan on using the iGPU with plex, but I thought I would try setting up the P2000 just so I have the option. First, I tried selecting the P2000 in Plex transcoder settings without any additional config changes to the plex docker. In this case, Plex continued playback normally but it did revert to CPU transcoding. This was somewhat expected as I hadn't added any of the nvidia specific variables to my Plex config. I then completed the Nvidia config for the Plex docker, adding the extra parameter, both variables, and checking for spaces... basically everything I read in all the other threads. After this I tried to force another transcode and playback simply stopped. Cycling the play/pause button in the playback did nothing, and after a few minutes the title disappears from the dashboard. Of course I tried with several other files all with the same result. Again, playback just stopped. In the dashboard, network and CPU dropped off immediately as if I had stopped playback. Plex was not frozen as I could still navigate the UI and even play direct play files. All I have to do is select the iGPU inside plex and it takes over the HW transcoding just fine. Clearly something changed when I added the nvidia variables to the plex docker since it didn't revert to CPU transcoding as before. Any idea why the P2000 isn't picking up the transcode as it should? Don't know if it is significant, but I am using the Plex Official docker container.

Yes, I was able to enable the iGPU in BIOS so that both are available within unraid and plex. To the original poster's question, there was no need for me to determine which card/renderer represented which GPU. Since I was already configured for transcoding with the iGPU, my plex config includes a Device pointing to /dev/dri/, a folder which now includes two cards and two renderers. In the plex transcoder settings, I have options for Auto, Quadro P2000, and Alder Lake UHD 770. I selected the Alder Lake option and I am able to HW transcode with the iGPU. Plex reverts to CPU transcoding if I choose the P2000. This is likely because I haven't added the Nvidia variables or extra parameter usually required. I may experiment with that later so I have the option, should the need arise. Honestly, this is not a priority for me since I have the P2000 churning through files with TDARR, and the iGPU for my modest plex transcoding needs.

I have been working on the very same problem, but with a twist. I added a P2000 to add horsepower to TDARR, but doing so disabled my Plex hardware transcoding via QSV on my i5-12500. Interestingly, I don't even seem to have two cards to choose from. With the iGPU and the P2000 installed, I only see Card0 and renderD128. root@UNBUCKET:~# ls -l /dev/dri/by-path/ total 0 lrwxrwxrwx 1 root root 8 Apr 21 20:13 pci-0000:01:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Apr 21 20:13 pci-0000:01:00.0-render -> ../renderD128 root@UNBUCKET:~# I'm wondering if maybe this is a motherboard thing where it disables the iGPU when another GPU is installed. I haven't yet attached a monitor to check the BIOS for a setting that might disable the feature, if it exists. I also might try not installing the P2000 in the first slot and see what happens. If I can get the iGPU and the P2000 to coexist, I would be fine using the iGPU for my modest Plex transcoding needs while I leave the P2000 for TDARR. Down the road when TDARR is finished with existing files, and I only have new files to process, I might use the P2000 for Plex or simply remove it.

Diagnostics attached and thanks in advance. unbucket-diagnostics-20230731-1723.zip

One of my cache SSDs has been showing some errors so I want to replace it. Since SSD prices have come down, I also want to upgrade all the drives with larger ones because I have a large Plex library in appdata that takes up nearly half my total cache. Anyway, to prep for replacing the cache drives, I set all my cache shares to use the array, disabled Docker and started the mover. Once the move was complete, most files had moved from the cache pool to the array, but a number of small files remain in the cache appdata folder. The share size data shows 11.8MB on the cache pool, most of this is from two SUPERVISORD.LOG files in my RADARR and KRUSADER folder. The other files are all really small log and config files. Unfortunately, I don't know a way to attach a complete listing of the files. I haven't checked every file, but I did check all the files in the top folder for Krusdaer and Radarr. In every case, there are at least two versions of the files, one in cache and one on an array disk. The sizes and dates vary, sometimes they are only a few minutes apart in age. Many of these are files that haven't been modified in some time, others were modified just a few days ago. Some of the files on cache are newer, for others the array is newer. A lot of the files on the array have the same date, 1/3/23, which I think is the last time I cleared the cache to replace another cache drive. I wasn't changing the size of the cache pool so I just replaced the drive and let it rebuild the pool, but I moved the data out of cache as a precaution. It seems as if the duplicate files are preventing the files from moving from the cache to the array. Would it be safe to delete one copy so the mover can finish moving files from the cache to the array? If so, should I delete the older files, or the files in one location or the other? I'm also curious how unraid handles having more than one version of the same file. Does it use the file located in the primary location, or does it use the newer version?

Thanks, I found the a similar comment about "EFI-" on linuxserver.tips shortly after posting here. Removing the hyphen did allow me to boot with both my current and backup-created flash drives. Great to get over that hump, but that was just on a tabletop. Waiting for new M.2 drives to arrive before I put everything back together and see if the storage array is still intact. I also tried the CSM option but could not enable it on my motherboard. Searching that issue led to articles on the ASUS support site saying CSM was disabled or restricted in intel 10th gen and 500 series boards. I say restricted because one of their proposed solutions was to use a discrete GPU instead of the iGPU and it would work. I guess in certain cases it is available but in mine it was not. I didn't find a specific reference to 12th gen and 600 series chipsets but it seems likely it was not added back.

My unraid motherboard recently died. It was a 10 year old LGA1155 board so the only replacement boards I could find with enough PCIe slots were used, expensive and often both. Instead of spending a bunch of money on an old fossil I decided to modernize and got a new 12th gen Intel CPU and ASUS Z690 motherboard. The motherboard is a little overkill but had the number of slots needed for my HBA cards and included 2.5G networking, which let me remove my existing NIC. Unfortunately, I had no luck when booting the new board with my existing unraid flash drive. I could see the drive in the boot menu and in BIOS, but after selecting it the computer would quickly return to the BIOS screen, without an error message or anything. I tried my current unraid drive and one created from a recent backup and they both failed to boot. I then tried an unraid drive made with a fresh download plus a windows install drive and both worked fine. What could it be that is preventing the existing unraid drive from booting? I would definitely prefer to use my existing drive rather than start from scratch. I have no idea what could be preventing my existing drives from booting when the fresh one works. Suggestions or ideas will be much appreciated.

I recently upgraded a drive in my SSD cache pool. I probably would have been fine without, but before replacing the drive I moved shares that normally reside on the cache to the array. Most importantly I wanted to move my large Plex appdata folder. To move the shares, I changed their cache preference from PREFER to YES and ran the Mover. I also stopped all dockers and disabled auto-start so that the files would not be in use. After the cache upgrade, which had no issues, I changed the shares back to PREFER and started the Mover again. Once finished, I checked the array disks for any lingering folders or files, and I found some. There aren't many, just one .icons folder from Krusader that seems to be empty, and six Plex metadata .bundle folders. The Plex folders are spread across five folders in one library, so just one or two subfolders in folders that normally contain hundreds of these .bundle folders. When I explore the bundle folders deeper, there are several more levels of subfolders but ultimately they all appear empty. This means I don't think there is really any data to be worried about, just folders that need to be cleaned up. I didn't previously have mover logging enabled, but now I do. The most recent mover operation is very close to the end of the attached log. What seems interesting is that the the mover is trying to move files (that do not exist), that have the same paths as the few folders still remaining on the array. I guess instead of deleting the empty folder path, Mover left the empty folders behind. Is there a way to force Mover to clean up the folders? Can I safely remove them manually? Should I ignore them since they take up no space? unbucket-syslog-20210624-0045.zip

I have not shucked an 18TB drive, but I have shucked several 10 and 12TB Elements and MyBook drives. In all cases, they were SATA drives. Once installed they identify as Wester Digital Ultrastar He10/12 drives. I did have to tape off the 3rd pin to make them work with SATA power connectors but that was pretty easy.

For a few weeks now, my server has been locking up every weekend. At first I didn't notice the regularity, but this week I noticed the uptime was 6 days and 20 hours when I was dealing with it. Considering I woke up around 3:30 AM and started messing with it, the uptime would have been right at 7 days if I had waited until morning to take care of it, like usual. The lockup first becomes apparent because the network shares become unavailable to file explorer and any other applications using the shares. While the shares are unavailable, the webGUI is still partially working. The exact state of the webGUI has been different each week. Some pages load fully, while others only load partly. For example, the past few weeks the MAIN page would load, except the Array Operation section at the bottom would be blank. In each case I have been able to access the page to download diagnostics, but until this week the diagnostics never would actually download. The week the diagnostics did finally download so I have something to upload. Recovering from the lockup always ends in me shutting down manually and restarting, which of course is followed by a parity check. I have tried shutting down via the webgui and the terminal window without success. With a monitor connected to the server, when I try powering down from the terminal window I can see the process starting, but it never finishes and actually shuts off the hardware. Since this week the webgui was a little more complete (i.e. Array Operation was loading) I got to see a little more info than past episodes. One interesting thing is it indicated Mover was running, but no actual disk activity was indicated. I don't know if that is significant, it's just something I saw. The regularity of this happening every saturday night/sunday morning made me look for a corresponding scheduled event. I have a number of things that check overnight, such as application updates that check daily, the only weekly item I found was SSD Trim (enabled for my cache SSDs) set for Sunday at 2AM. I am going to disable Trim for now and see if it solves the problem. Any thoughts on Trim locking up the system? UNBUCKET Main 09052020c.pdf unbucket-diagnostics-20200906-0331.zip

Thanks, you've confirmed my thoughts. I knew I could turn on the PSU with a jumper, I just didn't know if there was a reason I shouldn't.

Seems like your response is closest to what I want to achieve. If nothing is connected to the MB, then you are controlling the PSU directly. Not clear whether your remote switch is connected to the incoming power or the PSU output. Please clarify how you are turning the PSU on and keeping it on. Did you install a permanent jumper on the 24-pin connector and now you are switching the power from the wall? Or, is your electronic switch connected to the 24-pin connector? Either way would confirm my thought that using a jumper to activate the PSU, whether the jumper is solid or switched, is all I need to turn the PSU on.

Thanks for the input, both of you. Not keen on the idea of splicing into my PSU cables. I'd need a pair of 24-pin extensions so I could splice into them without permanent damage to my PSU cables. Plus, I would need some sort of connectors at the back of the machine for easy disconnection when I need to move them. Cheaper than the supermicro widget, but still probably $15-20 in parts. Both of these solutions would require additional cabling between the two enclosures. I'm not aware of any off the shelf cables that would work for either option so I would have to rig something up using adapters and old cable parts. I might even have to solder, which I suck at. I'm not concerned about keeping the PSUs in sync. Except for upgrades and/or repairs, this server runs 24/7. I think I'll try to stick with a solution that doesn't involve extra connections between the two machines.

Looking for a little room to grow. Planning on using one of the currently available mini-ITX enclosures with 8 hot swap bays to house the drives and connecting to an external SAS HBA in the main system with a pass-thru in the back of the case. I know that on a dollar per bay basis I would be better with a used server chassis, but I don't need that much expansion and I don't have anyplace to mount a server chassis. My question is how to power the external chassis since I won't have a motherboard. Do I really need something like the SuperMicro JBPWR2 Power Board or can I simply turn on the PSU with a jumper? If all I need is a jumper for the PSU, looking at this switch to make powering off and on easier. If I need something more, I also have an old ASUS AT5IONT-I board with an integral Atom CPU lying around collecting dust. I'm thinking I could also use it to control the PSU, and it would just be in a constant state of failed boot without a boot drive. This would waste a bit of power, but with a 13W CPU not too much.

I have had no issues using the Aquantia AQtion 10G Pro NIC in my unraid machine. The card is multi-gig so it supports 1, 2.5, 5, and 10G depending on the connection at the other end and the length and quality of the cable. In my case it sits right next to my main switch with a CAT 7 patch cord connection, but is limited to 5G because it is connected to a 5G port on my switch. Still, with spinning hard drives this is more than enough speed.

A couple of weeks ago, completely out of the blue I saw I had errors on two storage drives plus one of my two parity drives was offline. The first sign something was weird was that both storage drives had the exact same number of errors. This would be a huge coincidence if it was physical drive failures. It turned out that all three drives were connected to the same breakout cable (the 4th was unused) on my LSI 9207-8i HBA. Thinking it might be a bad cable, I swapped out the cable and rebooted. I rebuilt the 2nd parity drive and everything has been fine for the past two weeks. Tonight, I updated to version 6.8.1. Right after rebooting I saw a strange warning message that one of my cache drives was unavailable. Oddly, when I checked the drive on the MAIN page it said the drive was operating normally. A few minutes later, the same parity and two storage drives started having similar problems as before. While on a different breakout cable, the cache drive is connected to the same HBA as the other malfunctioning drives. I shut down and swapped the HBA for a spare I just bought for another machine. It seems like the HBA may be sketchy. I prefer not to put the HBA back into service without confirming it is healthy. I also don't want to buy another if not necessary. Does anyone know of any software tools or other methods for testing an HBA? unbucket-diagnostics-20200113-2308.zip

Best Buy is currently offering $90 off on the 10TB Easystore, making it $159.99. This is $30 less than the 8TB at $199.99. They also have $100 off on the 14TB model, making it $209.99. If you can go big, $15/TB is not too shabby. No deal on the 12TB so it is $249.99.

Thanks to all. The file system status check with the -L switch seems to have done the trick.

Unfortunately I tried both, but with no positive results. First I tried xfs_repair from the terminal window, which seemed to return an error and stop. I can't figure how to copy text from the terminal window so I've done my best to repeat the results below. xfs_repair result Phase 1 - find and verify superblock... - block cashe size set to 323016 entries Phase 2 - using internal log - zero log... zero_log: head block 116006 tail block 116002 ERROR: The filesystem has valuable metadata changes in the log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the file system before doing this. I checked out the -L option under xfs_repair, and it had this to say: -L Force Log Zeroing. Forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data. Since this didn't sound promising, I moved on to the webGUI option. The webGUI option first returned an ALERT that was similar to the error above, but still essentially cautioned to first mount my (unmountable) file system. It did however complete the scen, the results of which are below. The wiki indicates that the file system check should clearly indicate what steps should be taken if a repair is required. Maybe I'm missing something, but I do not see any suggestions below. Since nothing was suggested, I restarted the array normally and still the disk is unmountable. With no obvious error, does this mean my disk is toast? My replacement should arrive tomorrow. Is rebuilding from parity the bet option? After that I can pull the disc and more thoroughly test it. webGUI file system check results Phase 1 - find and verify superblock... - block cache size set to 323016 entries Phase 2 - using internal log - zero log... zero_log: head block 116006 tail block 116002 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (1:120049) is ahead of log (1:116006). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu May 16 18:40:32 2019 Phase Start End Duration Phase 1: 05/16 18:40:31 05/16 18:40:31 Phase 2: 05/16 18:40:31 05/16 18:40:31 Phase 3: 05/16 18:40:31 05/16 18:40:32 1 second Phase 4: 05/16 18:40:32 05/16 18:40:32 Phase 5: Skipped Phase 6: 05/16 18:40:32 05/16 18:40:32 Phase 7: 05/16 18:40:32 05/16 18:40:32 Total run time: 1 second

DITTO, the same thing happened to me. The common problems plugin notified me of an issue. The error was "Unable to communicate with GitHub.com" but I have also determined that my Plex server (running as a docker) is not available outside of my network. Fortunately I have no problem seeing the server or my unraid shares on my local network. I checked the network settings and discovered that the motherboard ethernet port, which has been disabled for many months in favor of a mellanox 10Gb network card. I set interface back to PORT DOWN and rebooted. Unfortunately after rebooting the server still cannot connect outside of my network. EDIT I rolled back the OS to version 6.6.7 and the network connectivity issues are gone. No settings changes, just the OS version. Definitely looks like a network issue with OS 6.7.0. unbucket-diagnostics-20190516-0320.zip

Got home from work today, and happened to see that a new unraid version was available so I decided to upgrade. I backed up the flash drive, and then I ran the upgrade assistant tool, which advised me to upgrade a couple of plugins, which I did. Plugins sorted I started the upgrade, which completed just fine and told me to reboot. Upon rebooting Disk 4 is now showing as "Unmountable: No file system". Prior to the upgrade I didn't notice any issues or warnings. About 3 weeks ago the server did shut down abnormally when a power outage exceeded my UPS standby time, but it had been running fine since being restarted. I have only tried the most basic troubleshooting. I tried restarting with no change. I also tried a new SATA cable and swapping SATA ports on the motherboard, but the error remains on the original disk 4, not the cable or port. I have attached my diagnostics tool zip file. I don't have a spare disk at the moment because I used it on another system, but I already have on order. In the meantime I have shut down the server since it houses less than critical data that I can live without for a few days. While I wait, I would like to know what happened, in case it's something that I did or something otherwise preventable in the future. While I wait for the replacement drive I guess I need to read up on how to replace a drive and rebuild the array since this is my first failure since starting to use unraid. EDIT Rolled back the OS to version 6.6.7 but the drive is still unmountable. Seems like maybe it is a drive issue that just didn't show up until the system was reboot. ghost-diagnostics-20190516-0154.zip

Makes sense. Thanks.

Thanks, that seems to have fixed the problem. The process is now going 80-90 MB/s, and should be done in a day and a half. 5 minutes in and it has already done more than 5 hours yesterday. I replaced the two cables, and of course gave all the rest a push to make sure they were seated. Like I said I am still learning. I'm guessing that ATA# refers to the actual interface, but 3 and 6 didn't correspond to the port numbers those drives were connected to on the motherboard, even if I start counting at 0. For example, the drives were connected to SATA_1 and SATA_4. Could you please tell me how you determined which interface was connected to which drive? Finally, thanks for the tip about the diagnostics tool. I posted the system log because it was the first thing I found that was full of errors. I now see that the diagnostics tool includes the log plus other useful info.

I've just gotten started with unraid in the past few months. My first server is working great, but the case has no more room drives. Instead of getting a server case I have no place to mount, I decided to create a second server using an old computer on hand. I started by installing 10 hard drives salvaged from my old amahi server, which I stopped using. Drive sizes range from 5 to 8 TB. I didn't have a parity drive to start, but I recently purchased a 10TB drive to use for parity. I installed it, assigned it to parity, and the parity sync began. Unfortunately, the process is proceeding at a snails pace. Right now the anticipated completion time is 55 days, but I have seen it well over 100 days. Progress is slow on two fronts. First, I haven't seen the read speed yet exceed 25 MB/s, but most of the time it is between 1 and 2 MB/s. As if this weren't bad enough, it only reads for a few seconds before it stops and all drives read 0 MB/s for a few seconds. This on and off really hurts the average speed. This is not a powerful machine, but this is the first time I have had any speed issues. All drives mechanical (no SSD) and some are connected via SATA II ports, either on the motherboard or pcie cards. The pcie cards are pcie 2.0 x1, but one has only one port, and the other only two ports so they shouldn't be bottlenecking this bad. The CPU is only an Athlon X2 270, but according to the dashboard it is barely topping 25% so it doesn't seem like a bottleneck either. I've attached the system log. There is an error that keeps repeating on either ATA3.00 or ATA6.00. I'm guessing this is what's causing my problem. Can someone please help me identify what the error is. Also, how do I correlate the ATA device with actual drives so I know what drive or cable to check? For now I am going to shut down and remove the parity drive. I'm leaving town tomorrow for the holidays so I won't have time to fool with it till I get back in a few days. ghost-syslog-20181223-0143.zip

I'm not completely certain that I know how to answer that. When I check permissions for a file using krusader, I first see a screen with separate pulldown menus for Owner, Group and Others. Each menu is set to "Can View & Modify. At the bottom is a box labeled Ownership, which says User: nobody and Group: users. This seems to match what you are saying it should be. I tried running this tool on part of one share. Unfortunately there was no change in my ability to play videos using VLC. It did however change the file permissions from rwx to rw-.