Closed jbruchanov closed 4 years ago
There is a tag for 3.10.6
, does that work?
3.10.6 works fine... 3.10.8 seems to have some issue during first initialisation/wizard
Adding to this.. starting on 3.10.6 works however upgrading to :latest prevents me from logging in with the configuration I created on 3.10.6. Downgrading to 3.10.6 after launching on :latest allows me to login again.
God I hate Ubiquiti's whole treatment of upgrades. It'll take me a bit to figure out what is going on, obviously you should use :3.10.6
until then.
I have a fresh install of 3.10.8 and can confirm this is showing a L/P prompt on a fresh install (with nothing prior, unable to login with defaults and have never set up the container so would have nothing else to use
EDIT: have now removed and installed 3.10.6 and I can confirm its worked first time. Definitely an issue with the build but very pleased to have the previous build running!
Yup, same issue. I can see that system.properties is being overwritten or cleared when starting up.
God I hate Ubiquiti's whole treatment of upgrades. It'll take me a bit to figure out what is going on, obviously you should use
:3.10.6
until then.
It looks like it's an issue invoking some Google module... I haven't looked at Ubiquiti's build dock for 3.10.8 but this is what fails.
10/1/2019 1:02:30 PM at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/1/2019 1:02:30 PM at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10/1/2019 1:02:30 PM at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10/1/2019 1:02:30 PM at java.lang.reflect.Method.invoke(Method.java:498)
10/1/2019 1:02:30 PM at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
10/1/2019 1:02:30 PMCaused by: com.google.inject.CreationException: Guice creation errors:
10/1/2019 1:02:30 PM
10/1/2019 1:02:30 PM1) Error injecting constructor, java.lang.NullPointerException
10/1/2019 1:02:30 PM at com.ubnt.airvision.system.SystemConfiguration.<init>(Unknown Source)
10/1/2019 1:02:30 PM at com.ubnt.airvision.A.String.configure(Unknown Source)
10/1/2019 1:02:30 PM while locating com.ubnt.airvision.system.SystemConfiguration
10/1/2019 1:02:30 PM
10/1/2019 1:02:30 PM1 error
10/1/2019 1:02:30 PM at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:183)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109)
10/1/2019 1:02:30 PM at com.google.inject.Guice.createInjector(Guice.java:95)
10/1/2019 1:02:30 PM at com.google.inject.Guice.createInjector(Guice.java:72)
10/1/2019 1:02:30 PM at com.google.inject.Guice.createInjector(Guice.java:62)
10/1/2019 1:02:30 PM at com.ubnt.airvision.Main.getInjector(Unknown Source)
10/1/2019 1:02:30 PM at com.ubnt.airvision.Main.initializeApp(Unknown Source)
10/1/2019 1:02:30 PM at com.ubnt.airvision.Main.start(Unknown Source)
10/1/2019 1:02:30 PM ... 5 more
10/1/2019 1:02:30 PMCaused by: java.lang.NullPointerException
10/1/2019 1:02:30 PM at com.ubnt.common.ooOO.A.super(Unknown Source)
10/1/2019 1:02:30 PM at com.ubnt.airvision.system.SystemConfiguration.o00000(Unknown Source)
10/1/2019 1:02:30 PM at com.ubnt.airvision.system.SystemConfiguration.<init>(Unknown Source)
10/1/2019 1:02:30 PM at com.ubnt.airvision.system.SystemConfiguration$$FastClassByGuice$$90dc632.newInstance(<generated>)
10/1/2019 1:02:30 PM at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
10/1/2019 1:02:30 PM at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:60)
10/1/2019 1:02:30 PM at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
10/1/2019 1:02:30 PM at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)
10/1/2019 1:02:30 PM at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
10/1/2019 1:02:30 PM at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
10/1/2019 1:02:30 PM at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
10/1/2019 1:02:30 PM at com.google.inject.Scopes$1$1.get(Scopes.java:65)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:204)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:198)
10/1/2019 1:02:30 PM at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:198)
10/1/2019 1:02:30 PM at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:179)
10/1/2019 1:02:30 PM ... 12 more
10/1/2019 1:02:30 PMCannot start daemon
10/1/2019 1:02:30 PMjava_start failed
10/1/2019 1:02:30 PMService exit with a return value of 5```
some Google module
Kind of an aside, what and why is Ubiquiti using a Google module?
I fired up a clean VM and get the same as you guys when I use :latest
. I can drop to :3.10.6
and run the wizard, log in, log out and then log back in again. Everything is fine still. Stop it and let it upgrade to :latest
again w/ the db from a successful 3.10.6 initialization... and I can't log in. :/
Well shit, here we go...
From 3.10.8:
bin/mongod --config /usr/lib/unifi-video/conf/mongodv3.0+.conf
From 3.10.6:
bin/mongod --config /usr/lib/unifi-video/conf/mongod-wt.conf
For some reason, it is going back to the not wired tiger database. What. The. Shit.
Ditto. I can confirm the same problem on my end. To make matters worse 3.10.8 seems to have updated the firmware on my cameras and when I roll back to 3.10.6, none of my cameras want to connect. I've tried falling back to 3.10.6 - but get firmware mismatch (between camera and video software)
Originally I was on 3.10.5. But then I mistakenly updated using the GUI update button and not the container. Needless to say the container got stuck at boot up "starting database". I deleted the container and pulled down 3.10.8. The container started up but I couldn't login. My login and password wasn't working. It was at this time I decided ill roll back to 3.10.6. After doing that I'm able to login, but I get the firmware mismatch error.
I am having the same problem now, had one camera not getting adopted so I thought, maybe try the new version ... well now I am stuck between cant login and firmware mismatch.
What do you think is the solution, just wait for 3.10.9+ or will a new docker container help?
thanks and greetings
I think you can do one of two things to fix your current situation.
If you want to use 3.10.8, we need to figure out how to make sure it uses the wired tiger database instead of the old one. My personal one does this, but I suspect it is because I use MongoDB 4.x. I could walk the beta branch up to 3.6 and 4.0 and provide :tags
to gradually upgrade, see if that helps. But if your DB isn't already wired tiger, you'd need to convert it.
You could also go back to 3.10.6 and manually downgrade the firmware on your camera(s).
Can each of you with issues docker exec
into your unifi-video container while running 3.10.6 and then 3.10.8 and do a ps aux | grep mongo
and show the output of both here? That should make it clear if you're using wt or not.
Okay, on :beta
I have pushed a commit that updates MongoDB to 3.6 and another to 4.0. And I've pushed tags for it, and :3.10.8-3.6
, though I don't know if they'll get processed properly. Keep an eye on the builds at https://hub.docker.com/r/pducharme/unifi-video-controller/builds:3.10.8-4.0
Edit: The -
didn't work, so the tags are :3.10.8.3.6
and :3.10.8.4.0
.
thank you for that @fryfrog
I went back further to 3.10.5, as that was my original deployment, still had firmware issues. And then pulled down your latest BETA build and now I can re-manage all my cameras :D :D :D yaaaay ! :)
Thank you very much for doing that
Wow, nice. I wonder if you got the build that had 3.6. Can you exec in and do the ps
?
Edit: It looks like the 4.0 :beta
just finished, so if the tags work they'll come next.
unifi-v+ 204 0.2 0.1 1125920 69040 ? Sl 13:02 0:08 bin/mongod --config /usr/lib/unifi-video/conf/mongod-wt.conf
Well, at least it did exactly as expected!
@fryfrog Love your work Sir. So happy my system is back online. I didn't have anything in the database, so not sure what other users will experience, but im happy I dont have to climb a ladder and reset all the cameras :)
You wouldn't have had to do that, you can just go right to the web interface on a camera, log in and force download an old firmware version! :)
So the problem I had is ... for some reason, the password that got pushed out to the cameras wasn't what I set it to be on the 3.10.5 controller. So when the controller went down I couldn't access the cameras individually. Couldn't ssh, web ... the only way was to reset or wait for controller 3.10.8 software to work, or a new docker version to be released.
Lucky I saved the password files from my data directory on 3.10.5 and I've been using those file to get access to the cameras on other container versions. Still can't SSH though. So my next task is going to be to reset passwords on cameras to something that I know works ;)
Okay, on
:beta
I have pushed a commit that updates MongoDB to 3.6 and another to 4.0. And I've pushed tags for it,:3.10.8-3.6
and:3.10.8-4.0
, though I don't know if they'll get processed properly. Keep an eye on the builds at https://hub.docker.com/r/pducharme/unifi-video-controller/builds
If I use the beta tag, I have version 3.10.8 running and can login + Cameras are working!
Thank you very much!
Here is the output of ps aux | grep mongo
root@2c8448662c89:/# ps aux | grep mongo
unifi-v+ 196 2.1 1.1 1126680 90340 ? Sl 11:49 0:01 bin/mongod --config /usr/lib/unifi-video/conf/mongod-wt.conf
root 407 0.0 0.0 16448 1104 pts/0 S+ 11:49 0:00 grep --color=auto mongo
Rookie here, having same problem.
Build a new NAS on a Synology 918+. Running through Docker. The first version I tried was latest (3.10.8.) I'm having trouble trying to go back to 3.10.6, running the start in ssh, it constantly wants to go to and download the latest.
Where can I comment out the command that is doing that?
Sounds like you're starting up your old docker container every time. Stop it. Delete it. And then instantiate a new one with the following command. Make sure you change the folder mapping to your needs:
sudo docker run \
--detach \
--name unifi-video \
--cap-add SYS_ADMIN \
--cap-add DAC_READ_SEARCH \
--security-opt apparmor:unconfined \
-p 10001:10001 \
-p 1935:1935 \
-p 6666:6666 \
-p 7080:7080 \
-p 7442:7442 \
-p 7443:7443 \
-p 7444:7444 \
-p 7445:7445 \
-p 7446:7446 \
-p 7447:7447 \
-v /volume1/data:/var/lib/unifi-video \
-v /volume1/videos:/var/lib/unifi-video/videos \
-v /volume1/logs:/var/log/unifi-video \
-e TZ=America/Chicago \
-e PUID=99 \
-e PGID=100 \
-e DEBUG=1 \
pducharme/unifi-video-controller:beta
Can you please help me getting the container back up and running? I am still having the problem signing back in. Tried tags 3.10.6 and beta as well. In the past I used to upgrade by emptying the data folder (except videos) and then updating the image, starting with an empty data folder and importing my backup. For some reason the controller asks for a username/password, even when I start with an empty data folder. Is that still the right procedure? thanks a lot! Till
So, actually I got back online by reverting back to 3.10.5 which has the wizard and imported my backup and scanned the video folder. Should I now be able to apply the beta image without removing the data folder?
In your running :3.10.5
container, docker exec
in and ps aux | grep mongo
and show me what it is running. If mentions -wt
for WiredTiger, I'd try going to :3.10.6
and see if it works.
The tags w/ -
in their name didn't work, so I made them :3.10.8.3.6
(which finished and proves it works) and :3.10.8.4.0
. I would walk forward like :3.10.6
, confirm it works. Then :3.10.8.3.6
and confirm it works, then to :3.10.8.4.0
and confirm it works.
In your running :3.10.5 container, docker exec in and ps aux | grep mongo and show me what it is running. If mentions -wt for WiredTiger, I'd try going to :3.10.6 and see if it works.
unifi-v+ 139 1.8 0.8 963520 66912 ? Sl 21:21 0:01 bin/mongod --config /usr/lib/unifi-video/conf/mongodv3.0+.conf
Hmm. Doesn't look like wt. Does 3.10.6 have the broken wizard as well? Otherwise I can again backup, remove data, run 3.10.6 and import?
I'm not sure what controls weather it starts up w/ the old db or new db style, it could be the version of monogodb? You could spin up a clean :3.10.6
and see what it starts as. Or now start up a clean :3.10.8.4.0
and see what it does. Actually, let me try that on my VM. :)
When I fire up 3.10.8.4.0, I can log in w/ the old l/p I set, so I bet the wizard works. Trying that now.
No... :(
Okay, so what does work for me is start up w/ :3.10.6
and do the wizard, then stop it and start up with :beta
and it just works.
I rolled back to 3.10.5, created my account, stopped and deleted container, removed the ":3.10.5" from the last line, and boom running 3.10.8
Humm, you didn't even have to use :beta
?
So I managed to get it working as well. My upgrade procedure to 3.10.8:
@fryfrog is it safe to update from 3.10.6 to 3.10.8 or any of the iterations or safe to hold off for now?
I'm not sure, mine has been fine the whole time. If you're running 3.10.6 and it works, you can try :beta
which will be 3.10.10 w/ MongoDB 4.0 and see what happens. Or you could try `:testing: which should be 3.10.10 w/ the old MongoDB 3.4. It wouldn't be crazy to make a copy of your database folder, just to make things safer and easier.
I'm not sure, mine has been fine the whole time. If you're running 3.10.6 and it works, you can try
:beta
which will be 3.10.10 w/ MongoDB 4.0 and see what happens. Or you could try `:testing: which should be 3.10.10 w/ the old MongoDB 3.4. It wouldn't be crazy to make a copy of your database folder, just to make things safer and easier.
I can confirm that 3.10.6 -> 3.10.8.3.4 does not work, same login issue as with the previous latest. 3.10.6 -> 3.10.8.40 does however work, after login updates firmware and working now problems.
Next test will be 3.10.10!
Weirdly, I had same issue as described, though even with beta e4ddc2e I was able to create account, but not login. On Chrome, it worked just fine on Firefox which I never used before installing e4ddc2e, though after clearing "everything" via dev console, I was able to log in.
My container got crushed after attempting to upgrade from 3.10.6 to latest tag. I've attempted to create a new container in verious versions (3.10.6, 3.10.8, 3.10.8.4.0) which fail to start also
My container got crushed after attempting to upgrade from 3.10.6 to latest tag. I've attempted to create a new container in verious versions (3.10.6, 3.10.8, 3.10.8.4.0) which fail to start also
Did you remember to add the folder mappings?
My container got crushed after attempting to upgrade from 3.10.6 to latest tag. I've attempted to create a new container in verious versions (3.10.6, 3.10.8, 3.10.8.4.0) which fail to start also
Did you remember to add the folder mappings?
ofcourse i'm not that silly
Can you guys just straight up try :beta
from scratch? I finally fired it up in a VM and it runs me through the wizard and ends up working just fine. I stopped and started it again, still works fine.
And I can again go from :3.10.6
fresh to :beta
no trouble.
So I've gone ahead and pushed the mongodb 4.0 to :latest
.
I installed the :beta this afternoon and restored my backup from an earlier version. All my cameras were in the "Managing" state. I had to unmanage all of them and re-add them. Once I did that, everything is working, but I am still seeing this error:
ERROR [uv.db.svc] Failed to acquire client connection null in MongoDb-Connecting
I've been seeing that for the past few versions, though, and not just with the Docker container.
Have moved from 3.10.8.4.0 to latest and no issues found...
apart from not being able to playback timeline higher then 1x speed (although not sure if this is a new issue or was in previous versions). Could also be something with my setup>
New installation of 3.10.10 works fine for me. So I guess we can close this issue.
@jbruchanov in reference to #165, that is still not the case for upgrades. Perhaps it's only working on new installations - but upgrades are broken.
Trying to run on Synology DS918+ (DSM 6.2.2-24922 Update 3)
running
PUID=1028 is valid value for my docker account, data folders are created and docker user as set as the owner
Executing it fails
Service exit with a return value of 5
Starting it again and opening https://web:7443/ (not port 7080, it never worked for me) stays few moments on "Update database" screen and then I can see a login screen. However I can't login withubnt
/ubnt
(I would expect to have a wizard though as it's fresh data folder, not an update).I tried to add
is_default=true
into/system.properties
and restart. It doesn't help unfortunatelly and ends again with the 'Service exit with a return value of 5'.system.properties
is though updated by it and it's empty again.Attaching logs from synology docker.
Any ideas what might be wrong ? Using version 3.10.6 works fine unifi-video-latest.csv.txt