fryfrog

I'm not planning to switch to Protect, will happily maintain this until it literally doesn't work anymore. Hopefully where it currently lives, or as a fork if Pducharme wants to shut it down.

Right now, the `:latest` tag is also `:3.10.11`. If what you're saying is that you updated to 3.10.11 *inside* the container... maybe you can just update the *container* instead and it'll be fine? I doubt it *actually* removed the videos. The rule with Docker is that you *don't* update the software *inside* the container. You update the Docker *image*. The Docker container is *trash*, disposable. It should be able to disappear w/o impacting your settings and data. Those are passed in via your volumes.

Wow, first time ever in the history of Unifi Video! 😛

Speaking of which... I didn't realize I hadn't pushed 3.10.11 to the *release* branch or tagged it. Instead, I've just been running it from `:testing`. Sorry! I've now done it and Docker Hub should have builds... whenever.

I'm still here and using it, there just isn't much to do besides keep it up to date. You're welcome to fork this one, learn how it works and submit improvements. I'll merge them.

Done! It built on my end, but I didn't *run* it myself. Pushed it. See how it does? :)

Hey @debit lagos, what beta releases? For the life of me, I can't find anything useful on their forums anymore. Or are you talking about Unifi, not Unifi Video?

I don't think Unifi Video itself can do that, but maybe unRAID or Docker support quotas? I'd suggest Binging on Google for "unraid quota" or "docker quota".

Srsly, I wish they'd stop making these weird breaking changes. If you fire up a *clean*, new one on `:latest` or `:testing` or `:beta` does *that* work?

So for a moment while 3.10.4 is up, `docker exec` into the container and `ps aux` and look at the mongodb running command. It'll point at a `.conf` file and the name of that file should make it obvious if it is wt or not. I think *in* that conf file will tell you where the db files are. Then you can fire up a latest instance and compare. Probably you'll find the old is using old db and pointing at old db path, new using wt and pointed at new db path. From there, you'd just dump to file, restore from file to wt into the right place and if you're lucky it'll work. Or just clean install and restore.

Ugh, that is the question, eh? I think they may have been fiddling w/ how they decided between old (i forget the name) and wired tiger. For a long time, it looked like it was based on the mongodb version... but then somewhere in 3.10.7 it changed and I never could figure out what they were basing it on. So it was "better" and "safer" to just bump it up to MongoDB 4.0 and let it use wired tiger. I hate trying to figure out wtf they're doing.

I'm not sure how good you are at this stuff, but my guess is that your old working version used the old type of db and the new version is trying to use wired tiger. If you have the skills, you could fire up mongodb w/ the old db, dump it and then stop it. Then fire up w/ the *new* mongodb and import the dumped db. That is how I converted my old mongodb -> wiredTiger. It wasn't *that* hard, but it also wasn't super easy.

The last update to `:latest` (the release branch) was Oct 26. Only `:testing` and `:beta` have been getting updates recently. You could try walking backward a version at a time, :3.10.10, :3.10.8, :3.10.6 maybe? Or just start a clean `:latest` and restore?

When you were on `:latest` and it was working, what version where you using?

Try using the label for the version you were running, to get you fixed up to start. Do you know what that was? My *guess* would be `:3.10.6` because 3.10.7, 3.10.8 and 3.10.10 have been where all the trouble is. From there, I'd probably make a backup and then fire up a clean `:latest` and load the backup.