bigbangus

FYI it works perfect with an external db. Also if you’re using the GPU version with double-take 1.7.0 the status check will cause compreface to fail. I raised the issue on GitHub. That being said, if it’s correctly configured and you avoid the status page in double take, there is no issue. For reference: https://github.com/exadel-inc/CompreFace/issues/691 Sent from my iPhone using Tapatalk

I switched to the mosquitto app. At first it had the same issue, but then I passed the environment variables PUID/GUID 1883/1883 in the docker template and did a 'chown -R 1883:1883 /mnt/user/appdata/mosquitto' and it works fine now. Writes the db no issue. Only downside is the config is a lot more work and you have to manually specify the log and data mappings. So def a little more time consuming, but results are good.

Is this just a permissions issue of my appdata/MQTT folder? I tried the fixes outlined on pages 15-16-17 of this thread but nothing works.

Is it normal to get this warning with the gpu version after processing your first image? 2021-12-20 11:37:09.749 WARN 127 --- [nio-8080-exec-3] o.n.l.cpu.nativecpu.CpuNDArrayFactory : *********************************** CPU Feature Check Warning *********************************** 2021-12-20 11:37:09.749 WARN 127 --- [nio-8080-exec-3] o.n.l.cpu.nativecpu.CpuNDArrayFactory : Warning: Initializing ND4J with Generic x86 binary on a CPU with AVX/AVX2 support 2021-12-20 11:37:09.749 WARN 127 --- [nio-8080-exec-3] o.n.l.cpu.nativecpu.CpuNDArrayFactory : Using ND4J with AVX/AVX2 will improve performance. See deeplearning4j.org/cpu for more details 2021-12-20 11:37:09.749 WARN 127 --- [nio-8080-exec-3] o.n.l.cpu.nativecpu.CpuNDArrayFactory : Or set environment variable ND4J_IGNORE_AVX=true to suppress this warning 2021-12-20 11:37:09.749 WARN 127 --- [nio-8080-exec-3] o.n.l.cpu.nativecpu.CpuNDArrayFactory : *************************************************************************************************

I see the same thing. From what I've tested with all versions (standard, and both gpu options) it will only work with an external db specified. On github the developper said it's compatible with postgres 11 or 13.

So I'm all set using the external db and I think it's probably the way most users should go. For the record I'm on postgres13 with no issues. I'm using pgadmin4 to manage it (had to chmod 5050:5050 my pgadmin4 appdata on first start to get it to work). @corgan I've kind of given up on the internal db but if you need me to continue testing for you I will.

OK but still after deleting all my templates and all my docker compose and all my appdata/compreface... I still have the same problem. See log attached. However, it does work in external db mode w/postgres 11 compreface-gpu.txt

No I'm pulling it from the docker template in the app store... but I do have the original docker compose compreface group of 5 containers still running... is there some kind of conflict there? Should I delete all the original stuff

Here is the docker command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='CompreFace' --net='bridge' -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="UnraidNAS" -e HOST_CONTAINERNAME="CompreFace" -e 'EXTERNAL_DB'='false' -e 'POSTGRES_URL'='jdbc:postgresql://192.168.2.254:5432/compreface' -e 'POSTGRES_PASSWORD'='corgan80982' -e 'POSTGRES_USER'='compreface' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:80]' -l net.unraid.docker.icon='https://raw.githubusercontent.com/corgan2222/unraid-templates/main/img/compreface.png' -p '8800:80/tcp' -v '/mnt/user/appdata/compreface':'/var/lib/postgresql/data':'rw' 'exadel/compreface:0.6.1' 0b36eec7b5d84133acc6634470f94350ecb4a9291ee83aa7626a96415f13a955 Also on your github, I believe the data path is the same: <Data> <Volume> <HostDir>/mnt/user/appdata/compreface</HostDir> <ContainerDir>/var/lib/postgresql/data</ContainerDir> <Mode>rw</Mode> </Volume> </Data>

@corgan big thanks for getting these containers going with the compreface dev on github. However, I am still unable to use either the regular or gpu version as is from the appstore. This is what the GUI looks like in either case: The error I'm getting boil down to (see log attached): 2021-12-14 06:51:54,200 INFO exited: compreface-postgres-db (exit status 1; not expected) 2021-12-14 06:51:55.097 ERROR 484 --- [ main] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Exception during pool initialization. org.postgresql.util.PSQLException: The connection attempt failed. Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled. 2021-12-14 06:51:55.115 ERROR 484 --- [ main] o.s.boot.SpringApplication : Application run failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]: Invocation of init method failed; nested exception is liquibase.exception.DatabaseException: org.postgresql.util.PSQLException: The connection attempt failed. Caused by: liquibase.exception.DatabaseException: org.postgresql.util.PSQLException: The connection attempt failed. Caused by: org.postgresql.util.PSQLException: The connection attempt failed. compreface-log.txt

Just noticed this in the log when I click on my system info. Is this normal? Can't find anything online about it. Dec 8 07:21:24 UnraidNAS kernel: ccp 0000:09:00.1: ccp: unable to access the device: you might be running a broken BIOS. Dec 8 07:21:24 UnraidNAS kernel: kvm: Nested Virtualization enabled Dec 8 07:21:24 UnraidNAS kernel: SVM: kvm: Nested Paging enabled Dec 8 07:21:24 UnraidNAS kernel: SEV supported: 509 ASIDs Dec 8 07:21:24 UnraidNAS kernel: SVM: Virtual VMLOAD VMSAVE supported Dec 8 07:21:24 UnraidNAS kernel: SVM: Virtual GIF supported

OK I'm embarassed. I was making console line calls to hash passwords for Authelia docker run authelia/authelia:latest authelia hash-password 'YOUR NEW PASSWORD' | awk '{print $3}''Your new Password Here' didn't realize it at the time, but this was resulting in containers being launched in the background with no name! So then I found this: https://medium.com/peptr/why-boring-wozniak-will-never-be-generated-as-a-container-name-in-docker-763b755f9e2a which basically explains that dockers without names are just given random name pairings from two static lists. lol Man I'm dangerous behind a keyboard.

I was just messing around on my Unraid GUI working on stuff and saw two containers created 15min ago with 0.0.0.0:9091<>0.0.0.0:9091 port mapping. They were named weird stuff like "boring_wozniak" and some other one I didn't recognize. I just shut down docker and shut down my server and now not sure what to do. Any help is appreciated. Thanks.

So tempting.... But... Any luck? Need any help beta testing this?

@digiblur is it worth including "--restart unless-stopped" in the zigbee2mqtt template or something to that effect. I have TubeZB's POE coordinator and everytime my ubiquiti controller pushes an update across my network, the container stops with "adapter disconnected" in the log. Is there any way zigbee2mqtt can be more resilient? Is that something better managed on the template or with the project itself on github? Thanks!