seestray

it needs to be included in part of the docker image, if it doesn't show it in the adv menu, then that docker image doesn't have it. I had a similar problem, it's been fixed for a while now - although can't remember what did it (there are some threads on here with potential solutions, btrfs or changing from the docker image to the folder structure might have helped - I recall changing those around that time). What file system are you running on the cache drive?

Ran 4 passes of memtest6.2 on a different pair of 2x16 using the same slots in the motherboard, they passed. Rebooted the server and parity check has completed with no errors found. Anything else I should check/run to catch errors that the bad memory could have caused? (As an aside running memtest86+7 with only the suspect dimm in a different PC, will leave it for a while more, but it's done 4 passes without an error. I'll let it go until I need that PC tomorrow - is it likely that it was just a connection issue that was solved by removing/reinstalling in a diff PC?)

Thanks for the reply JorgeB, I've been running memtest this afternoon and looks like one of the sticks are bad. Swapped in a different pair from the desktop, and running memtest on them to rule out the board or something else. The ipvlan change is on my do-to list, didn't want to change too many things at once with the upgrade - since things looked to be stable before this.

Updated to 6.12.8 about two weeks ago, came back from a week away and my shares have disappeared. (And most docker containers have either stopped due to errors, or aren't running correctly due to no disk.) Browsing from the Main --> Disk shares, the files all appear to be present Shares --> all are missing When I run: i3-12100, Gigabyte Technology Co., Ltd. B660M DS3H AX 16Gb DDR4, LSI SAS2008 Found a pair of similar threads, but they are earlier versions. Solving it with a reboot doesn't seem to be a permanent fix, though, and I should probably try to understand why it's happening first. Diagnostics attached, anything else to check/get before I reboot the box? tower-diagnostics-20240320-0842.zip

Went from 6.11.5 --> 6.12.8 with the realtek RTL8125, macvlan and a unifi docker that's on 8.0.24. An hour in and all appear to be working at first glance - we'll see over the next couple of weeks if it remains stable.

Thought I would add a little bit of documentation - I did the cache swap procedure to replace/add a second cache drive - it caused an issue where paperless would not start after reinstalling all the dockers (it was the only one that had an issue) nothing changed with my config. (Don't know if it is fully related, but either way, figure this is the best spot to add in case someone else has the issue.) From the startup log, this was the only thing that stood out: django.db.utils.IntegrityError: CHECK constraint failed: archive_serial_number Applying documents.1029_alter_document_archive_serial_number...Paperless-ngx docker container starting... I don't use the ASN feature, but since I didn't have anything else to go on, turns out one of my documents had the ASN set to '-2' and this was enough to prevent it from starting. To fix: open terminal cd /mnt/cache/appdata/paperless-ngx/data#ls -l /mnt/cache/appdata/paperless-ngx/data#ls -l make note of the current permissions for the database /mnt/cache/appdata/paperless-ngx/data# chmod 777 db.sqlite3 change to allow all to write (we will change it back at the end) Open the documents_document table in DB Browser for SQLite, look for archive_serial_number that is out of range (negative or huge), set them to a null, or other valid value. back to terminal, /mnt/cache/appdata/paperless-ngx/data# chmod 644 db.sqlite3 At this point I was able to start paperless-ngx again.

So if they are already organized, I would scan each batch to the watched folder, go to the paperless inbox view - tag that batch, then scan the next batch, tag it and repeat. Over a couple of evenings I think I scanned in ~500 docs which got most of my semi-recent stuff off my desk.

I have it setup so a 'new' tag is assigned to everything as it's imported (and a view that shows only the 'new' by default.) I then manually review and remove the new tag. You can also edit a batch of them all at the same time from the list view no need to do them individually if you know they are all the same. I've found the automatic/AI tagging to be pretty decent after a few rounds, seems to get the tags right more often then not, but you need to do import/tagging in batches - it only learns after you correct things, so items in the 'new' queue won't take advantage of the AI learnings from earlier in the batch.

I'm running two instances of pi-hole, one in unraid, and a second on a pi-zero w. The pi is generally reliable, but when a wyze cam goes on the fritz and starts a couple of million dns requests to google, it will crash. Having both the pi & a docker version, lets me update without having to worry about any of the clients having dns issues (or having to rely on an outside source.)

FYI - mass downloading of old episodes is an issue, so update your v2 instance asap. Had this issue this past week on a couple of shows - over 500g in unexpected downloads of un-monitored seasons I've added a quota that resets daily in SABnzb, hopefully that will reduce the chances of automation gone wild in the future - likely a good idea to add one, if you don't already have one in place. Sonar version: 2.0.0.5338 (issue occurs) v2 master: 2.0.0.5344 (issue corrected) More info on the issue: https://forums.sonarr.tv/t/important-zero-episodes-and-old-episodes-reappearing-as-monitored-and-potentially-downloaded-unintentionally/25023 https://old.reddit.com/r/sonarr/comments/fhj8z9/important_zero_episodes_and_old_episodes/ https://github.com/Sonarr/Sonarr/issues/3619

but if you look to the prior releases in the -latest branch, it's the same comment/update for 5.12.35-ls49 (5 days ago) , 5.12.35-ls48 (12 days ago), 5.12.35-ls47 (18 days ago), 5.12.35-ls46 (26 days ago), etc. So please correct me if I'm wrong, but it doesn't look like the updates are for something ubiquiti has changed.