fryfrog

Try the `:latest` tag, I think it should be 3.10.1. I don't see an actual 3.10.1 tag, so I'll push that now-ish too. I can switch back and forth between 3.10.1 and 3.10.2 just fine, .1 works and .2 doesn't w/ an error about the user table being corrupt.

So w/ just those bare minimum of changes (seen at https://github.com/fryfrog/UniFi-Video-Controller/commits/master), it comes up and my username/password don't work. Logs show the cameras connecting and getting rejected. I'm not sure what is wrong yet.

I finally got all the little things needed for the v3.10.2 update sorted out (nothing crazy, just url changed and patch file needed update). I pushed it to my own docker hub and will run it for a day or two, then push it to the real one.

Last I looked, it was withdrawn... is it good now? Edit: Now I don't see any trace of it having been withdrawn...

Just show us your settings, how ever you know to do that.

-v /data/unifi-video/data:/var/lib/unifi-video \ -v /data/unifi-video/videos:/var/lib/unifi-video/videos \ ^ Docker paths are passed in like that, w/ the *outside* path first and the *inside* path second. Your post doesn't actually show the exact way you're passing them in, just path = path. And they're *reversed* from how they should be if you were reading them right from the `-v` argument. It looks in a specific place for that file and clearly isn't finding it. Because the insides of a Docker container get nuked every time they're updated (or even restarted if you use `--rm` like I do), you lose your config every time. I think you've got your setup wrong. Can you show your run command? When you `docker exec` into it, you should be looking at `/var/lib/unifi-video` and `/var/lib/unifi-video/videos`.

@bluesky509, it sounds like you're not passing in an outside folder for the config to get saved in and so every time you start up, it looks like a fresh install. But the paths you've shown clearly indicate you are, unless you've passed them in that order which would be the *opposite* of correct. You need to do some troubleshooting. The first thing I'd do is look in that outside folder while it is running, is the file there? If it isn't, you've found your issue and need to figure out what is wrong w/ your path mapping. You could `docker exec` into your container and see where the file *really* is and what you've mounted into it.

Trying to get Docker Hub building and tagging issues sorted out w/ @Pducharme so you guys can at least run an older version easily. But I have to admit, I have *no idea* what is going wrong. My own personal setup is working fine. Anyone want to collaborate?

I've been passively watching the problems while on vacation, but it doesn't seem like any specific cause has been nailed down. I run from my own copy of the repo where I try to test before pushing to the main one and mine is working fine, though I did have problems w/ the featureVersion of the mongodb when we advanced it to 3.6 and 4.0. But after stepping that up correctly, my container is happily running mongodb on the inside. The install is *very* old though, so might be using the old form of the db instead of the new? That is what I'll look into when I have the time. And a scratch setup, which I can't see any reason it shouldn't. Anyone good at mongodb and unifi-video want to collaborate on solving this? :/

@stormshaker: In the mean time, you're welcome to experiment by switching to `:testing` or `:beta`. *Right now*, they're what `:latest` would end up being if I pushed all the changes to it.

I think I need to research if 3.10.1 *requires* MongoDB 4.0 before I push the update to `:latest`.

Ha, I picked and pushed all the *support* stuff... but never actually updated the version. Sorry!

@spyd4r, what tag are you using? Both :beta and :testing have MongoDB 4.0. This will *only* run a db at featureversion 3.6 (or 4.0). You need to drop down to the db your existing db supports and upgrade it. In the master and beta branches (:testing and :beta), there are commit points that have 3.4, 3.6 and 4.0. And because the upgrade script was addded *before* those points, all you need to do is start up at each of those points. When you run the 3.4, it'll set your 3.2 db to 3.4 (if needed). When you run the 3.6, it'll set your 3.4 to 3.6 (if needed), finally when you hit the 4.0 image it'll upgrade your 3.6 to 4.0. Or does 4.10.1 *require* mongodb 4.0 to work?

@stormshaker, done but the github -> docker link up isn't working, so I'll ask @Pducharme to trigger it manually.

What do you see in logs, either Docker's or Unifi Video's?

I'd strongly suggest reversing that. *Most* people are going to want the latest version and `:latest` literally implies that. It should track the latest release. I'd create a tag for the last stable of the deprecated line, like `:5.6.x` or something. If you go the route you're suggesting, everyone will have to update their docker run line every time. And people are going to ask about this over and over and over and over.

You're going to need to look into unifi video logs and help figure out the problem. My instance runs fine and w/o anything useful, nothing is going to change.

It is and has been for awhile, unless you're saying they changed the 3.10.0 beta 1 .deb file?

Check the logs, see what is going on.

Unifi Video is only for Unifi Video cameras, correct. Other cameras do not work with it. For that, you'll need something else. The only one I know of is Synology's Surveillance Station, but there are others for sure. I just don't know their names!

Because they use some multicast thing, you can't fire up the container w/ all those port forwards in the normal mode and have it work. You should be able to use the adopt token and such. Or you can fire it up in --network="host" mode to add them, then drop back to normal. https://github.com/pducharme/UniFi-Video-Controller/issues/110 ^ This issue talks about another way where the container gets its own mac and IP, you could try it and see how it goes.

Saying what? Mine was saying something about needing 3.4 features on 3.6. Is it possible your db is even older? You can flip back to the 3.9.9 docker and make changes to the db. You can docker exec into the container and run mongo --quiet --eval "db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )" localhost:7441 to see what version it is set to. mongo --quiet --eval 'db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )' localhost:7441 Will set it to 3.4. But so would the latest beta, have you pulled recently?

FWIW, it was very obvious in the logs. My instance was starting mongodb up over and over and over and over.

You're probably going to have to dig in and see what is what. In one of the beta images, I updated mongodb to 3.6 and that don't fly w/o updating the db itself to be compatible. Mine was at 3.2 features, so it failed. I reverted that and added some stuff to bring db to 3.4. Look at startup output, look at logs, see what is going on.

Done, I also updated it to use mongodb 3.6... so hopefully that works!