Squid

Question: Does the system you're using and leaving a chrome tab open to the dashboard go to sleep? (ie: a laptop). Just found my MacBook w/Chrome had the tab hit 4.8G overnight, and it should have wound up sleeping.

I plan on living forever

If you install Unassigned Devices, and mount them with it, does it show multiple partitions on the drives?

Is there anything looking really out to lunch if you look at Docker, Container Size

This is what you'd want

I replied in your other thread

Post your diagnostics. This likely has nothing to do with CA as it basically reports what the system tells it

Usually caused by poor connection of the Sata cabling. Reseat (both ends) or replace

You could probably delete /config/plugins/dynamix/mover.cron on the flash drive (then from a command prompt) update_cron but that file will get regenerated if you make any changes to Settings - Schedules (presumably)

Mar 12 12:09:26 Sharkie-Media kernel: BTRFS warning (device loop2): csum failed root 797 ino 19540 off 4399104 csum 0x7fbdee55 expected csum 0x42dde054 mirror 1 Mar 12 12:09:26 Sharkie-Media kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0 Mar 12 12:09:26 Sharkie-Media kernel: BTRFS warning (device loop2): csum failed root 797 ino 19540 off 4407296 csum 0x8a9b8ee7 expected csum 0x42d0b0f3 mirror 1 Mar 12 12:09:26 Sharkie-Media kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 3, gen 0 Mar 12 12:09:26 Sharkie-Media kernel: BTRFS warning (device loop2): csum failed root 797 ino 19540 off 4423680 csum 0x36a48629 expected csum 0xcbf3a90b mirror 1 Mar 12 12:09:26 Sharkie-Media kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0 What you should do is run a memtest on your system from the boot menu for at least a pass or two, as corruption is usually caused by memory issues (but not always - could be unclean shutdowns) After that passes (or fails and you replace the memory), then you're going to need to Settings - Docker, stop the service Delete the docker.img (option to do it on the same page) Re-enable the service Apps, Previous Apps. Check off whatever you had installed before, then hit Install "X" Applications It'll all be setup identically to as it was previously before you have time to even make a copy. (If you did have any custom docker networks / containers installed outside of CA / templates, then you will need to redo those accordingly)

@trurl wants you to uninstall Mover Tuning altogether (not install the one from masterwishx) and then try again without the added complications of what the plugin does / adds

If you shutdown your server, on another system edit /config/go in any text editor and change it so that it only says #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp

Nothing to do with System Statistics. This has already been officially entered into an internal bug tracking system.

As a note, I would love if there was a separate support thread for each container. But, even if that were the case, a lot of the problems is that postings with issues / questions etc have a tendency to not happen within the designated thread in the first place, and that is completely out of LT's hands. (The only "control" is that regular forum users are unable to create any thread of their own within the Docker Containers section - Only devs are allowed to do that). The dropdowns on the container have the "Support" link listed for this very reason. FWIW, when clicking the drop down, from top to bottom is actually the "preferred" support venue by the author. (As an aside, you also inadvertently found a bug because when checking this, "Discord" is not getting listed - And when it's present it takes priority over the forum) Speaking as someone who on any given day gets roughly 100+ notifications from the forum, I can certainly understand why maintainers would prefer a single thread (again, not that I agree with it). It does make their job easier.

Not sure whether that's what I wanted to hear or not. I managed to replicate this issue once when I started looking at it, and did "fix" it, but when I went back to stock (to confirm that the issue happened again), it didn't happen again (or on multiple future tries). I believe that this is a memory leak caused by the library used to generate the graphs, (various reports online about this library, but they're all old and the changelog for the library says that the problem was long solved). The real solution (if this is indeed the cause) is switching the graphs to be rendered by a different library, but unfortunately it's not a drop in replacement so not an easy fix to do at this point in time.

It's a memory leak, except that the leak only affects a very small portion of users, and unfortunately its hard to fix what we can't replicate. I believe that 7.1.0 (currently public beta) has another potential fix for this in it.

Can you stop tdarr and then try updating it

Looks like a bug... It actually should work for multiples (and pretty sure it used to) But, to do more all you have to do is hit install second instance again, and then change the name of the container (and any other paths that might directly reference the default appdata path of the original name)

You need to install the one from masterwishx

Yes it is.

@ljm42

Based upon the last time @docgyver was online here, I'd say unlikely. How is it broken?

And that is the information which I needed to know if you continued to have the problem. Still weird that Safari works, but it's something for me to go on.

It's a security change that I made on the back end appfeed that had the unexpected side-effect of breaking the file in diagnostics. Already know how to fix on the back-end, but priorities shift sometimes and hasn't been implemented yet. Probably a day or two

If this continues, disable XMP in the BIOS and run the memory at its rated speed of 2133 (SPD speeds) instead of it's Overclocked XMP speed of 2666. All overclocks introduce instability into any system