ConnerVT

A couple of thoughts: 1. Don't use the Plex Web client for troubleshooting. It has a long standing issue when changing the requested transcoding. Instead, use a Plex App on your client device - AppleTV, Roku, smart TV, etc. 2. Delete the contents of you Codecs folder. This has solved odd transcoding issues for many people in the past, even for those using hardware transcoding. Your Plex server app will go out and re-populate the folder with a fresh set of codec files when you start the Plex docker.

Yes. Access speeds of HDD drives decrease as you go from access the first sector to the very last. For my 16TB drives, that is nearly a 50% decrease. Parity speeds track with the speed of the drive with the slowest access speed.

Two things to consider: Access time (read/write time) of the slowest drive being accessed during Parity Check/Rebuild is typically the gating factor as to how fast it is running at any one time. Spinning HDD access times are always the fastest at the start of the Parity Check/rebuild, and slowest at the end. If all you had are spinning rust drives, you probably would have seen an increase in speed once the 4TB drives were finished. Since they are SSD, there will be no speed increase, just slowly getting slower (or maybe not - I don't know if Unraid is smart enough to recognize that it just needs to write zeros for the rest of the task).

Group 15 is the USB hub - All of the listed devices are grouped together, as IOMMU cannot control/separate these, only the hub (which is part of the motherboard). Try a different USB port, so it is sitting alone in Group 19. Then pass Group 19.

In Docker, click Frigate and Edit to open the template. Select Advanced View (top right corner. Add what you need in Extra Parameters.

Probably was the cheapest PCB blank available at the board house of that physical size. Allowed space for the 4 less expensive SATA connectors across the top and freeware PCB layout software to do the design. All about making it as cheap as possible.

DOH! I think I figured out what happened. 🫢 As I wrote previously, I have a number of maintenance tasks I run. Several bash scripts and some plugins, all that send Telegram notifications when run. All of the server tasks are spread out so not to overlap (and at times where they have low impact on media server users). But I also have another task - a backup of my desktop workstation which runs daily. Macrium Reflect, which runs local on that workstation. It only sends notifications on failure. Macrium does a full backup on the first Monday, weekly differential every Monday, and an incremental daily. The daily incremental is usually very fast (10 minutes or less). The day before Appdata Backup ran, I copied a large amount of data to the workstation (+1 TB). I usually move this to a drive on the workstation that isn't backed up, but there wasn't enough free space. So it ended up on a drive that is included in the backup. When Appdata Backup ran, the server was busy with Macrium writing a ton of data directly to the parity protected array, while trying to verify the 16GB / 80000+ files of the Plex appdata backup file. I'm pretty confident that the array drives were thrashing around madly for a few hours. The Macrium backup completed without any error, so I did not receive any notification from it. My apologies for sounding the alarm. At least this is something you can add to your troubleshooting toolkit as a possibility if someone asks about something similar. Thank you for your time and support of this very useful plugin.

Hmmmm... Perhaps this is related to what I recently posted above? 🤔

My thoughts exactly. If there was some other drive activity that was taking that long, it would be something which I would had received a Telegram notification (backups, media downloads, parity checks, etc all go to my phone via telegram). I will see what happens next week. Maybe just a head scratching, one off glitch in the Matrix. Just thought I would toss it into this thread, to document and save some data about it, in case it comes up again for me or someone else.

The Immich iOS app can automatically upload photos (can turn on/off this in app). Like many iPhone apps, you need to actually open the app for it to start this task - an issue for most Apple apps, it doesn't like running things in the background. I don't believe Immich will remove photos from your phone, so they likely would upload again if removed from the Immich photo directory. The screenshot is from QDirStat docker. A very useful tool when trying to figure out what is using your storage space.

Photoprism Cache directory holds several thumbnail files for each photo in your library. It makes up almost the entire appdata directory for the app. This is one of the reasons I moved on to Immich. Photoprism just doesn't scale well with large photo libraries.

@KluthR Not looking for a fix, but wanted to note something strange that happened this week. I run a weekly appdata backup of ~30 Docker containers. A very plain vanilla config: Stop all - backup - start all, standard appdata locations, only exclusion is the Plex Cache folder. I consistently end up with ~33GB with 107 files. Usually completes in 24 minutes. No major changes made on the server or any Docker. The only change was installing the Unraid Patch the other day. (Server still on 6.12.10). All plugins and (most) Dockers up to date. Appdata backup ran yesterday and took just over 4 hours. No errors in Appdata Backup log. File is the same 33GB/107 files. No other activity going on at the time of the backup. I get Telegram notifications for many of my maintenance activities. Very strange that that it took 10x longer than it has done for many months. Seems as the Plex verification is what added all the additional time. I'll see what happens at next week's scheduled appdata backup. Just wanted to pass this along, in case you find yourself hunting this issue down. Adding Debug Log : f03fcb63-b91f-4dfa-8848-c78442a7923b

Also seeing it right after installing the Unraid Patch plugin on my 6.12.10 Main Server. Yeah, I know, update. It will be, eventually. But this narrows it down to possibly being related to the installation/presence of the security patches.

Even though it goes against my nature to install any software that ends in "0" (and ".0.0" is even worse), I pulled myself together and updated my backup server to 7.0.0. It is a fairly plain vanilla server, with Frigate and MQTT dockers running on it. It does have a Realtek motherboard NIC that needs the plugin installed, which I left in place during the install. All went without event. Thanks to everyone who contributed to this milestone revision.

Scroll down to the bottom of the Pricing > Buy Now page: Pro is lifetime updates, Unleashed is annual (one year of updates).

My guess is that /mnt/dockers/appdata/ isn't either one of these paths: [Main] Backing up from: /mnt/user/appdata, /mnt/cache/appdata

Frank has some good Google Fu skills, especially when searching things Unraid. Thanks!

No. Unraid only runs on x64 processors. Those two arm ARM based.

The 1500x and the 1700 are the same Ryzen family. This I know, I work where they built all of the 1st and 2nd generation Ryzen chips. I also have been running Ryzen since 1st gen, where my pre-ordered chip arrive a week early. Nothing on any board manufacture's QVL applies to any non-Windows OS. If you want stable, you need to set the memory to 1866. See if this resolves your lock up issue. If it does, you can try 2133 and see if you are lucky and it remains stable.

You have Dual Rank memory and 4 DIMMs. Don't get hung up on the marketing department's 2666 claim. You need to run at 1866. This is what a 1st Gen Ryzen's Infinity Fabric based memory controller can handle. My first Unraid server ran a 1500x. I had similar issues, until I clocked the memory as it was required. I seriously doubt you will see any performance hit on your server.

Unraid license is not tied to any hardware - It is associated to the boot flash drive. you can upgrade hardware as you wish. Even take the flash drive and use in a completely different system.

This isn't a very active sub-forum. You are probably better off posting in the General Support sub-forum and/or the Appdata Backup thread on Plugin Support. You'll get more eyes on your question this way.

@SpencerJ Weren't you folks hiring someone to rebuild the USB Creator code? Seems that a deep dive is needed into why the USB creator code has issues, and perhaps need to have a broader view of the current flash drive hardware and market as a whole. I understand LT's need to protect their IP, as well as the difficulty in any migration away from the flash drive based system. But the long ongoing issues folks have creating a boot flash drive is not a good look.

The Unraid license is tied to the USB flash drive it it was associated with. All that matters is the *.key file is in the flash drive's config folder. You can plug the flash drive into any machine, and it is good to go (except for needing to configure for new hardware and drives).