jademonkee

FWIW I have this same setup and am running the latest v6.4.54. Note however, that the front page on this version is pretty useless for the USG now, as I have a 500mbps internet connection, which is too fast for deep packet inspection to work without causing a bottleneck, and the front page now shows DPI info rather than current bandwidth usage. It can't currently be changed, either, so it just sits there being useless. Curiously, the Android app still shows bandwidth, so I now have to use that to see if something is eating my bandwidth. So, up until recently, 6 was fine. But if you have a fast internet connection and want useful info on the front screen, then stick with the version previous to v6.4.54, as it has bandwidth rather than DPI on the dashboard. Don't go any further back than that, though, as they start to get real flaky. As it's a new setup, I'd prob go to 6, as you're going to have to jump to that version sooner or later anyway, but the version recommended by JonathanM is perfectly fine, too. EDIT: I later found out that traffic analysis doesn't negatively effect bandwidth on my connection, so do ignore any above advice not to enable it.

Out of curiosity, do you have in your logs: 211004 10:30:59 mysqld_safe Logging to '/config/databases/90d1ec1b4a9c.err'. 211004 10:30:59 mysqld_safe Starting mariadbd daemon with databases from /config/databases I have it in mine, but everything works fine (or at least seems to). Just wondering if I do the above 'downgrade, command, upgrade fix' if it will fix that problem, too. Cheers.

I responded, and shall again: I have had no issues.

Ok, so since upgrading (or since the weird error that reset the theme in the dashboard?) I no longer see traffic on my dashboard. Yay. I just love this company... EDIT: Unless it's just changed what's displayed there? It used to show the current bandwidth being used, but maybe it's now meant to show the results of the "traffic identification" option, which I have turned off. I've just turned it on, but it's still not showing anything. I'll give it a few minutes to populate... Any idea how to just show bandwidth being used again, like it used to? EDITEDIT: confirming that yes, the dashboard has changed to display the data gathered by the "traffic identification" option. Can also confirm that enabling the traffic management option severely reduces my throughput, so I have once again disabled it. EDITEDITEDIT: later further testing showed that enabling traffic management doesn't impact my bandwidth: my initial poor results were simply coincidence.

I've had the same error in my log since the Alpine re-base. Nothing is broken on my end, though (I'm only using it for a single instance of Nextcloud with 2 users). I'm pretty sure someone in this thread told me it's nothing to worry about, but I would like to know why it's happening. 210927 12:23:15 mysqld_safe Logging to '/config/databases/e42e52e45c78.err'. 210927 12:23:16 mysqld_safe Starting mariadbd daemon with databases from /config/databases

I just took the plunge. Will report back if anything strange happens. Something strange happened before I upgraded: the theme went to white (from dark) and it said that some WiFi options I had weren't compatible. I had changed nothing since I last upgraded, so don't know why. Maybe something corrupted in the db (again...)? So yeah: any problems I face may not actually be due to the upgrade, anyhow.

You can see the available tags here: https://hub.docker.com/r/linuxserver/mariadb/tags?page=1&ordering=last_updated I don't know the difference between version-10.5.12-r0 and 10.5.12-r0-ls36 but maybe someone here can advise. If you swap to one of those versions, you'll stay on that version until you change the tag. (I think you may still get minor updates to the container, but not mariadb - someone will have to confirm). In saying that, it seems that "latest" would be one of those two, so it's probably no problem updating this time as the latest image is still some variant of the 10.5.12 version you're on (or even the exact same version), and - again - the problems were because of the 'rebasing' of the image, not an update to mariadb itself. So yeah. It's probably pretty safe to update - but there's also no harm in waiting for a few more people in the thread to speak of their experience.

Sorry, it seems you misunderstood: Step 1 of the fix was to set the tag to a manual version, step 2 was to specify the 'latest' tag, which will always pull down the latest version. If you set the tag to the version you're currently on, it will stay on that version. Any Docker updates will just be to the related container files, not mariadb itself, so shouldn't break anything. In saying that, I have the latest update and it's fine. However, I didn't have a problem when I upgraded to the Alpine base (although it was suggested earlier in this thread that the errors happened only on larger DBs, as they took longer to shut down than was given by the "update" command. The tag swap 'fix' worked because it did a "shutdown" command before upgrading, which gave mariadb enough time to shut down gracefully before the update, so it gave the impression of it doing more than it really did).

You can manually specify a version for mariadb to stay on, and it will stay on it (that's what the 'fix' earlier in this thread involved). However, the reason that things broke last update was because it moved to an Alpine base from Ubuntu. That won't happen again, so future updates should be fine (and may come with security benefits).

Anyone here have any idea how to get this container to support AAC / M4A files? I added some to my library, but they don't even appear in the library after a scan, let alone allow me to play them. Any idea how to get them working? I don't know how to access the files mentioned here: https://wiki.slimdevices.com/index.php/AAC.html And don't know if FAAD2 is installed or not (nor how to install it). Thanks all!

FYI Customer Support have said that my maintenance has now completed and it's now ok for me to log back in again, so I have done so. Will see if the sync finishes and report back if it does/doesn't. Here's the email as it contains some good info:

I updated this morning and have this in the logs: It's not adding any extra lines (like, they're not repeating), and Swag + NextCloud are working fine (the only things that use it - and I don't even remeber if they both do, or just NC... heh)). Is that safe mode anything to worry about? Or is it all good?

The customer support agent that suggested I deauthorize told me not to log back in until they told me to. It's because there is some maintenance occuring on the data stored on their servers, and the file sync can sometimes interfere with that. So the deauthorization stops the file sync so that the maintenance can complete without interruption. By logging back in immediately, the maintenance doesn't have a chance to complete. So I'm waiting for the customer support agent to tell me when it's ok to log back in.

Yeah, I'm sick of these periods of syncing an no-backups. I've been considering buying an old HP Microserver and installing it in a closet at a friend's place to run a weekly rsync backup to. However, with CrashPlan only $12/month, it'll take a little too long to pay off... so I keep giving up on the idea.

I've just received the following from CrashPlan support: I'll report back on any progress.

I'm seeing a synchronization, yes. However, it's been however many days now and it's never hit 100%. It keeps climbing then dropping back to 0%, just as it did in my earlier posts. I've reached out to CrashPlan support to see if they can shed any light on it.

FYI I decided to upgrade to v6.2.26 using the docker tag: linuxserver/unifi-controller:version-6.2.26 I also updated the firmware of my two AP AC LR to v5.43.38 (from v4), although one of them kept failing, and I had to 'cache' it in the controller before the upgrade worked successfully (Settings > Maintenance > Cache). The other (slightly newer hardware) updated fine the first time (before I'd cached the firmware), however. I also had to change my guest network authentication to explicitly use a password, and then re-enter what used to be the "WPA2" password (I don't use a portal, it's just an isolated network I use for untrusted devices). I also changed the Internet > WAN > Advanced > DHCP to point to my pihole DHCP server (don't know if I had to, but there was no value in that box) as well as Network > LAN > Advanced > DHCP UniFi Controller to point to my pihole DHCP sever, too, just in case that was needed as well. Aside from the firmware update hiccup, everything seems to be working well. I can't really see anything missing from the 'new' interface, and am enjoying its layout. I am generally a 'set and forget' user, though, so power users may find the new interface lacking. I'll report back if anything breaks. Thanks for taking the initial plunge @PeteAsking!

Well, not anymore. I'm having the same problem of 'synchronizing file information' endlessly looping. I'm about ready to chuck in the towel with crashplan and just install another Unraid box at a friend's house and run an rsync once a week.

Let us know what you think of it in a couple weeks. I still haven't taken the plunge, although it seems like most of the big problems were sorted in this latest release.

If you've confirmed that your max memory variable is set correctly (see earlier in the thread for the command in CrashPlan that allows you to check), then that's all I had to do to solve my problems. FWIW I'm using 4096 MB memory and backing up 3.6 TB. Most of the time the Docker only uses around 1 GB, but it may have climbed during sync and I missed it (which may be why mine was resetting), so if you can spare the memory, might as well set it high. If you've set the memory correctly, try reaching out to Crashplan support, too - the can take a look at the logs and see if your block sync is failing for another reason.

6 weeks later, how goes it? Any problems from the upgrade to v6? Anything you like about it more than v5? I'm too afraid to even upgrade the firmware on my APs to the new v5 from v4 without also making the jump to controller v6.

Just out of curiosity: are you running it as Bridge or Host? Bridge is preferred and will work fine as long as you set the correct ports and then set the hostname for adoption in the settings. Just go back a page in this topic to see more info on that.

Try restarting the Docker. I believe that should have it upgrade to the latest version (I may be confusing it with another Docker though). If it doesn't upgrade, try a 'force upgrade' in advanced settings (the toggle switch at the top of the Docker page).

See this post: TL;DR increase the limit using the tips n tweaks plugin. There's no magic number, so don't ask for one. The bigger it is, the more RAM you'll need. However, I have mine set to 2097152 (16 GB RAM, no VMs) and it works well for the number of files I"m backing up (and also Plex). Learn more about inotify here: https://man7.org/linux/man-pages/man7/inotify.7.html

Just popping in to say that 30 days later I FINALLY have backups completed again. Thanks again, everyone, for your help.