OpenALPR Webhook Processor for IP Cameras
- Thread starter mlapaglia
- Start date
If anyone knows how to check progress on the database conversion from version 5.0.0 onwards, please let me know, using Docker for Windows. CPU use on the container is higher than normal and currently cannot access or see logs after upgrading....
IReallyLikePizza2
Known around here
How's the CPU look? I had 1 core pegged at about 100% for a while, then it moved to a more mixed workload with all cores bouncing around, then went idle and it was done, then my logs came back
Main CPU is loading up between 30-40%, up and down, container CPU usage has been variable, seems to sit at 30-40% for a while, then dropped back to 6%, backup up again later to 35%, now 5 hours in on 25GB size DB, processor.db-shm and -wal files keep appearing then dropping out again. I have to assume something is happening, main DB file size has stayed the same throughout. Machine is a i5-8400 with 32GB RAM and Samsung 980 Pro 1TB, I jokingly refer to it as a new machine because it got built when that processor was released, then I could not face commissioning it, also regret not going for an i7 but there is always next time! The existing machine is i5-4690 so the step up is certainly noticeable, new one barely breaks a sweat with Rekor running, that alone would tax the older one quite a bit depending on feed quality.
Currently moving around between cores, between 10-30% I guess, interested to see what temps this setup runs once I get Blue Iris and co running along with daily software.
**Update on DB upgrade, after 8 hours the log has started and shows this, CPU back down to 0.15%, looks like not much is happening:
Code:
2024-06-15 17:19:17 [17:19:17 INF] Starting Hangfire Server using job storage: 'In-Memory Storage'
2024-06-15 17:19:17 [17:19:17 INF] Using the following options for Hangfire Server:
2024-06-15 17:19:17 Worker count: 20
2024-06-15 17:19:17 Listening queues: 'default'
2024-06-15 17:19:17 Shutdown timeout: 00:00:15
2024-06-15 17:19:17 Schedule polling interval: 00:00:01
2024-06-15 17:19:17 [17:19:17 INF] Server 686e7ee0c79f:1:c7d54d89 successfully announced in 2.4371 ms
2024-06-15 17:19:17 [17:19:17 INF] Server 686e7ee0c79f:1:c7d54d89 is starting the registered dispatchers: ServerWatchdog, ServerJobCancellationWatcher, Worker, DelayedJobScheduler, RecurringJobScheduler...
2024-06-15 17:19:18 [17:19:18 INF] Server 686e7ee0c79f:1:c7d54d89 all the dispatchers started
Last edited:
OK, upgraded right up to version 5.2.0 without issues, apart from doubling the database file size? is that expected behaviour?
If I try to spin up version 5.3.0 I still get the General error: 8 attempt to write to readonly database.
Almost certain this is a permissions issue, I have given permissions and ownership for the folders and files in alprwebhook to the Windows 11 account in use, still no dice
- If I start version 5.3.0 with a blank database, it is fine, reads new plates no problem, so some issue with using the existing database with version 5.3.0. Now I know the notes for this version state:
If I try to spin up version 5.3.0 I still get the General error: 8 attempt to write to readonly database.
Almost certain this is a permissions issue, I have given permissions and ownership for the folders and files in alprwebhook to the Windows 11 account in use, still no dice
- If I start version 5.3.0 with a blank database, it is fine, reads new plates no problem, so some issue with using the existing database with version 5.3.0. Now I know the notes for this version state:- The application inside docker no longer runs as root. You will need to change the owner of the database files or you will get errors about the database being read only.
Last edited:
OK, if anyone out there knows what command to add which will give specific Windows user ownership or permissions for the alprwebhook folder and all that sail in her, please enlighten me. Current Docker Run command line is below:
I am suspecting a variation on CHMOD, final piece of the puzzle, I will write this up for other Windows users running Docker Desktop.
Code:
docker run --net=bridge -e TZ=Etc/GMT-1 -d -p 3859:8080 -v "c:/alprwebhook/app/config/":"/app/config/" mlapaglia/openalprwebhookprocessor:v5.3.0I am running on version 5.2.0 at the moment due to permissions issues! but, I am getting a similar error as above, new vehicle only seen once, total seen count is 2, did you make any progress? I also still see 'disconnected' in settings but plates are getting logged.
Just to note I ran a VACUUM command on my database, took about 20-30 minutes and got it down from 52GB to 25GB again.
Last edited:
IReallyLikePizza2
Known around here
Okay well at least we're in the same boat! I don't think I have a permissions issue going to 5.3.0, but it could be. I'll work on it some more today
Same issues as you, double count and shows disconnected. I just hope this doesn't forever alter the database, I make use of the count quite a lot
Same issues as you, double count and shows disconnected. I just hope this doesn't forever alter the database, I make use of the count quite a lot
Won't be permissions, that causes fail login, you won't even get running with that.
I will test 5.3.0 with the new 'empty' database later and tomorrow, see if that shows same error. Honestly I am seriously thinking just start fresh, the case for keeping historical entries, especially with doubt on accuracy is getting weaker for me.
Just back on fresh database now using 5.3.0, will wait to see results on duplicate issue, won't take long! first car through will be the benchmark
Can confirm duplicate total count issue persists for me on 5.3.0, first seen, last seen today at identical time, total seen shows as 2
Last edited:
IReallyLikePizza2
Known around here
To confirm, you're seeing duplicate plates on 5.3.0 with a net new database?
Yes indeed, 100% accurate. Version 5.3.0, Windows 11, Docker Desktop latest release, all updates installed.
IReallyLikePizza2
Known around here
I wonder if I restore to a backup from before I upgraded, I'd hate this to forever alter the database count
That could be a good plan, not entirely sure whether just the latest release seems to be effected by this, or if it is a docker issue? hard to say, I did not test with 5.2.0 or prior.
IReallyLikePizza2
Known around here
I'm on 5.2.0 and it has the issue
Thanks for confirming, I might test the two previous versions tomorrow and see if they show the same results. I might even be able to confirm if duplicates get applied to historical entries, possibly.