Full ALPR Database System for Blue Iris!

@algertc the Insight Most active time does not show the correct Most active time.

1736097989926.png
 
  • Like
Reactions: algertc
algertc said:
I will be adding a page to view the logs from inside the app soon. You can check by attaching to the container. Try reducing your JPEG size/quality in blue Iris and checking the rest of the settings. I encountered that error a few times too when setting up a new cam. That’s fully a BI thing.
Click to expand...
Most of the time I have no issue, but every so often it shows BI retrying 5 times, then not updating the record count. The image size is only 1920 x 1080 and that size is working usually. The BI settings were for a 10 second timeout and 5 retries. I notice that the calls from BI seem to be immediate, so I'm not sure the timeout means anything. I've tried changing it to a 60 second timeout and 3 retries. I'll see if that matters.

Is there any other log that shows what is happening in the database when the API is processing the record and failing?

Code: 
2025-01-05 08:09:00 Current plate_reads count: 6876, threshold: 33000
2025-01-05 08:09:01 Received plate read data: {
2025-01-05 08:09:01   plate_number: '6TST589',
2025-01-05 08:09:01   Image: '/9j/4AAQSkZJ'... 456772 more characters,
2025-01-05 08:09:01   camera: 'LPR-rear',
2025-01-05 08:09:01   timestamp: '2025-01-05T16:08:51.074Z'
2025-01-05 08:09:01 }
2025-01-05 08:09:01 Database connection established
2025-01-05 08:09:01 Current plate_reads count: 6876, threshold: 33000
 
VideoDad said:
Most of the time I have no issue, but every so often it shows BI retrying 5 times, then not updating the record count. The image size is only 1920 x 1080 and that size is working usually. The BI settings were for a 10 second timeout and 5 retries. I notice that the calls from BI seem to be immediate, so I'm not sure the timeout means anything. I've tried changing it to a 60 second timeout and 3 retries. I'll see if that matters.

Is there any other log that shows what is happening in the database when the API is processing the record and failing?

Code: 
2025-01-05 08:09:00 Current plate_reads count: 6876, threshold: 33000
2025-01-05 08:09:01 Received plate read data: {
2025-01-05 08:09:01   plate_number: '6TST589',
2025-01-05 08:09:01   Image: '/9j/4AAQSkZJ'... 456772 more characters,
2025-01-05 08:09:01   camera: 'LPR-rear',
2025-01-05 08:09:01   timestamp: '2025-01-05T16:08:51.074Z'
2025-01-05 08:09:01 }
2025-01-05 08:09:01 Database connection established
2025-01-05 08:09:01 Current plate_reads count: 6876, threshold: 33000
Click to expand...

That looks like was successful? Can you confirm that you are seeing that in the logs, and the data doesn't actually end up in the database?

That would be really strange. Does it still say no stream when it fails?
 
I'll check again tonight and get more details of both the BI log and the API log, but the record count did not change, even after the 5 retries from BI (or maybe it was 3 now that I reduced it).
 
VideoDad said:
I'll check again tonight and get more details of both the BI log and the API log, but the record count did not change, even after the 5 retries from BI (or maybe it was 3 now that I reduced it).
Click to expand...
I think there’s a setting I can change to avoid this issue in the first place for people. It has to do with the size of the payload for communication between the frontend and backend of the app. I think this might be the reason because it wouldn’t cause it to send an error response, but just never send anything at all, causing the timeout and retries from BI.

In the meantime, I would try to reduce the size even more and see if it persists. I have mine at like 740 or something. I find it’s plenty if you have 24/7 recording.

I’d be curious to ask the BI people to check the code around the “no stream” error to see what exactly that means.
 
Something that just came to mind which would be nice is auto-tag functionality based on configurable rules.

The way I would use it is probably during the early morning like 12:00-3:30am and automatically tag those as late-night or something of that sort. I didn’t add the protect functionality in the last update like I said, but auto protect based on rules could be nice too. I don’t really look at the app that often for myself, so something that watches over the feed and collects evidence of anything sus would be nice.
 
  • Like
Reactions: MikeLud1 and Vettester
algertc said:
Something that just came to mind which would be nice is auto-tag functionality based on configurable rules.

The way I would use it is probably during the early morning like 12:00-3:30am and automatically tag those as late-night or something of that sort. I didn’t add the protect functionality in the last update like I said, but auto protect based on rules could be nice too. I don’t really look at the app that often for myself, so something that watches over the feed and collects evidence of anything sus would be nice.
Click to expand...
For auto-tagging have a rule that you can set if a plate shows up 3 (make it adjustable) times in 15 (make it adjustable) minutes tag it as Suspicious (have it user editable)
 
Last edited:
VideoDad said:
Most of the time I have no issue, but every so often it shows BI retrying 5 times, then not updating the record count. The image size is only 1920 x 1080 and that size is working usually. The BI settings were for a 10 second timeout and 5 retries. I notice that the calls from BI seem to be immediate, so I'm not sure the timeout means anything. I've tried changing it to a 60 second timeout and 3 retries. I'll see if that matters.
Click to expand...

I see this happening on my side as well and the ratio is also seems to be a bit worst (it doesn't seem to be only occasionally). I also log the BI alerted plates by Home Assistant into a text file (alerts sent by BI to HA via MQTT) and the total count for today was 24 so far and only 20 of these were captured and recorded by ALPR database.
Where do you see the quoted logs?
Also, where in BI is it possible to reduce the size of the alert pictures?
 
olympia said:
Where do you see the quoted logs?
Click to expand...
The first place is in the BI logs with any line that starts "Web:". Check any lines where the return code isn't 200 success.

The next place is in the Docker Desktop. Go to the containers and open the Log tab. About all I notice is the call retries multiple times and then doesn't increment the total record count.

I'm losing quite a few and I'd like to have this resolution for my email notifications, so I don't want to reduce it.

I tried calling the API directly with one of the failed calls and it went through. So it doesn't seem like size is the only variable.
 
My current failure rate from BI web calls is about 47%.
Cam3b Web: No stream: 409
Cam3a Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3a Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3a Web: 201 Created
Cam3b Web: 201 Created
Cam3a Web: No stream: 409
Cam3a Web: 201 Created
Cam3b Web: No stream: 409
Cam3a Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3a Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3a Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3a Web: No stream: 400
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam1a Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3a Web: No stream: 400
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam1a Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3a Web: 201 Created
Cam3a Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 400
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam1a Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam1a Web: No stream: 409
Cam3a Web: No stream: 400
Cam3b Web: 201 Created
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: 201 Created
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 400
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam3b Web: No stream: 409
Cam1a Web: No stream: 409
47% Failure Rate

​
 
Hmmm, maybe the root cause of the similar issue is different for you and me.
Actually it seems like the known plates are getting ignored on the live feed for me for some reason and at least at the moment I can't seem to see "web: no stream" error in BI as you.

However, I do see the following error in my postgresql log: "ERROR: column kp.ignore does not exist at character 69" - I guess this could be related to the new ignore feature and my db migration was not successful? @algertc do you have a hint here?

​

 
olympia said:
Hmmm, maybe the root cause of the similar issue is different for you and me.
Actually it seems like the known plates are getting ignored on the live feed for me for some reason and at least at the moment I can't seem to see "web: no stream" error in BI as you.

However, I do see the following error in my postgresql log: "ERROR: column kp.ignore does not exist at character 69" - I guess this could be related to the new ignore feature and my db migration was not successful? @algertc do you have a hint here?

​

Click to expand...
Your known plates table didn't get the new 'ignore' column. Try pulling the latest including the migration.sql.
 
Vettester said:
This is a camera configuration and/or network issue. It has nothing to do with the ALPR database app.
Click to expand...
So what settings do I need to change? How can I debug it? I see the API receiving the request but just not completing the task. I've updated BI to a later version 5.8.* with no change in behavior.
 
VideoDad said:
So what settings do I need to change? How can I debug it?
Click to expand...
I'm not sure how to resolve it, but if you open up your log file in a BI status window and type "stream" in the filter, you can see it occurring in real time. I've got two LPR cameras, one uses the new UI and the other is a few years old and I'm only seeing it on the newer cam. I've tried a bunch of configuration options to no avail. I think the next step is to email Ken.

Screen Shot 2025-01-09 at 2.14.45 PM.png
 
VideoDad said:
Your known plates table didn't get the new 'ignore' column. Try pulling the latest including the migration.sql.
Click to expand...
I had that issue the first time I was trying to update, but then then known plates page didn't even appear. When I ran migration.sql again, I've got back the known plates table, so I don't think this is the issue, but I will try running it again.

Edit: when I run migrations.sql again I get this:
Code: 
# psql -U postgres -d postgres -f migrations.sql     
psql:migrations.sql:1: NOTICE:  extension "pg_trgm" already exists, skipping
CREATE EXTENSION
psql:migrations.sql:2: NOTICE:  extension "fuzzystrmatch" already exists, skipping
CREATE EXTENSION
psql:migrations.sql:6: NOTICE:  column "priority" of relation "plate_notifications" already exists, skipping
ALTER TABLE
psql:migrations.sql:9: NOTICE:  column "camera_name" of relation "plate_reads" already exists, skipping
ALTER TABLE
psql:migrations.sql:11: ERROR:  column "ignore" of relation "known_plates" already exists
 
Last edited:
I just stumbled across this app, it looks awesome! Trying to get it working, the setup was a piece of cake but I can't seem to get BI to send the data over to it. If I look in the logs, I think the error is "Web: No stream: 500". Any suggestions? I've verified my api key is correct on both ends, url (and ip address) is correct, etc.
 
rfoust said:
I just stumbled across this app, it looks awesome! Trying to get it working, the setup was a piece of cake but I can't seem to get BI to send the data over to it. If I look in the logs, I think the error is "Web: No stream: 500". Any suggestions? I've verified my api key is correct on both ends, url (and ip address) is correct, etc.
Click to expand...
Oh wait, I figured out how to see the logging on the docker container. So looks like the info did get sent correctly, but it was followed by this:

2025-01-10 08:34:42 app-1 | camera: 'GreenwayLPR',
2025-01-10 08:34:42 app-1 | timestamp: '2025-01-10T13:34:26.366Z'
2025-01-10 08:34:42 app-1 | }
2025-01-10 08:34:45 app-1 | Error processing request: Error: getaddrinfo ENOTFOUND db
2025-01-10 08:34:45 app-1 | at <unknown> (/app/node_modules/pg-pool/index.js:45:11)
2025-01-10 08:34:45 app-1 | at async f (/app/.next/server/app/api/plate-reads/route.js:1:2775)
2025-01-10 08:34:45 app-1 | at async te.do (/app/node_modules/next/dist/compiled/next-server/app-route.runtime.prod.js:18:17826)
2025-01-10 08:34:45 app-1 | at async te.handle (/app/node_modules/next/dist/compiled/next-server/app-route.runtime.prod.js:18:22492)
2025-01-10 08:34:45 app-1 | at async doRender (/app/node_modules/next/dist/server/base-server.js:1455:42)
2025-01-10 08:34:45 app-1 | at async responseGenerator (/app/node_modules/next/dist/server/base-server.js:1814:28)
2025-01-10 08:34:45 app-1 | at async NextNodeServer.renderToResponseWithComponentsImpl (/app/node_modules/next/dist/server/base-server.js:1824:28)
2025-01-10 08:34:45 app-1 | at async NextNodeServer.renderPageComponent (/app/node_modules/next/dist/server/base-server.js:2240:24)
2025-01-10 08:34:45 app-1 | at async NextNodeServer.renderToResponseImpl (/app/node_modules/next/dist/server/base-server.js:2278:32) {
2025-01-10 08:34:45 app-1 | errno: -3008,
2025-01-10 08:34:45 app-1 | code: 'ENOTFOUND',
2025-01-10 08:34:45 app-1 | syscall: 'getaddrinfo',
2025-01-10 08:34:45 app-1 | hostname: 'db'
2025-01-10 08:34:45 app-1 | }
 
You must log in or register to reply here.
Top Bottom