Full ALPR Database System for Blue Iris!

Have now deleted everything in the ALPR directory and removed the containers/images. New install (as per GitHub Command) and still see the errors even before any plates sent.
1742669890743.png
 
Built an Ubuntu server VM on a different machine, did the install based on the instructions at alprdatabase.org, and still I see the same issue as was there on my Blue Iris Windows box.

Identify plate correctly with CPAI:
1742736115285.png

Not sure what 'No Stream' indicates - maybe that's my issue? I'm thinking this means the web request (which I don't see in my BI logs) is not working, even though images are being sent to ALPR. The docs mention this:
1742738856892.png

So I reduced to 50% quality and size to 640 x 480, but still getting the same message.
1742738934454.png


Same error message in ALPR:
1742736177769.png



Fresh install on different OS/physical machine:
1742735985135.png
 
Last edited:
Vettester said:
You don't need to use this option unless you want to save a jpeg file to your PC. Here's what I'm using...

View attachment 217411
Click to expand...
Just doing that for now so I can drop them in the AI tool to see what it see's. I found it interesting that only the trigger zone part of the image is sent to AI. As a tuning later, I was wondering if it can be setup with two zones, one for detection and a larger area that gets sent to the AI. I'll try unchecking it for now to see if it makes any difference
 
Vettester said:
No stream typically means there's a network issue.
Click to expand...
That was my first thought, but it all looks okay and is using the same switch as other cameras. But I don't think it's related to this issue since the no stream appears exactly after each attempt to send data to ALPR.
 
Can you post the md5sum of your migrations.sql and schema.sql files?

pdp11:/alprdash-lift# md5sum migrations.sql schema.sql
68299a0cc953f95cf27525b3c3023d41 migrations.sql
c11e379d5e7946a667b01a031086eb70 schema.sql
 
I don't want to clutter up this thread, but if you can take a quick poll of the version of BI you are running, I'd appreciate it.

P

Thread 'Which version of BI are you running with ALPR Database + CPAI?'

If BI and ALPR Database is working well for you, please share which version of BI you are running.

Well = BI behavior is consistent, it handles calls out to CPAI without failures and the motion triggers all work as expected, and you are running on the recommended HW.

For this poll, I am only asking about BI. CPAI and ALPR Database are not being considered.

Pls reply in that thread, thanks
 
PeteJ said:
Can you post the md5sum of your migrations.sql and schema.sql files?

pdp11:/alprdash-lift# md5sum migrations.sql schema.sql
68299a0cc953f95cf27525b3c3023d41 migrations.sql
c11e379d5e7946a667b01a031086eb70 schema.s
Click to expand...
68299a0cc953f95cf27525b3c3023d41 migrations.sql
9caab0fb987b904a13f3e325f5fa5fbe schema.sql
 
@svalvasori, is your install of ALPR Database on Windows or Linux? Those MD5 hashes do seem to match the latest files. Have you tried rerunning the docker commands from your ALPR folder?

docker compose pull
docker compose up -d
 
  • Like
Reactions: algertc
EDIT - SEE UPDATE BELOW

I updated in unraid but I am missing my previous plates in the DB. I tried updating via url/update and restarting the container but it didn't help.

1) Any guidance on how to run the update.sh in unraid?
2) Do I need to update the string in BI Alerts to:
Code: 
{ "ai_dump":&JSON, "Image":"&ALERT_JPEG", "camera":"&CAM", "ALERT_PATH": "&ALERT_PATH", "ALERT_CLIP": "&ALERT_CLIP", "timestamp":"&ALERT_TIME" }

This is the container console contents for REF
1742838077030.png





UPDATE

So I re-downloaded the migrations.sql and schema.sql from git. Then ran in the postgres console
Code: 
psql -U postgres -d postgres -f /migrations/migrations.sql
, rebooted the container and now ALPR seems to be showing old records:

1742840506455.png


Now I need to wait and see if the updated string in item #2 is working.
 
Last edited:
hopalong said:
UPDATE

So I re-downloaded the migrations.sql and schema.sql from git. Then ran in the postgres console psql -U postgres -d postgres -f /migrations/migrations.sql, rebooted the container and now ALPR seems to be showing old records:
Click to expand...

Yes, this is the only way to do it on unRAID. The update.sh script won’t work. If the database tables have changed, you’ll always need to run migrations.sql manually from the console.
What I usually do is check on GitHub before updating to see if migrations.sql has changed. If it has, I run Db update on the above way.
 
  • Like
Reactions: algertc and hopalong
olympia said:
Yes, this is the only way to do it on unRAID. The update.sh script won’t work. If the database tables have changed, you’ll always need to run migrations.sql manually from the console.
What I usually do is check on GitHub before updating to see if migrations.sql has changed. If it has, I run Db update on the above way.
Click to expand...
Thanks for verifying. The unraid section on the alpr webpage needs info. @algertc I am more than happy to assist in that. Let me know if I can help.
 
  • Like
Reactions: algertc
Columbo said:
I'm loving the work being done here! Im looking to get mine set up when I come back from a holiday, so I am pretty new to this.

Two questions:
How are you handling plates from different states/countries? Are you bunching them all in one?

What about MAC addresses? Sure, some cars dont have them, some only transmit them when a device is connected and others have randomised addresses, but councils do use these for traffic monitoring. Then police could use them to track a car (albeit only in high profile cases or if they are used to doing this).
Click to expand...

The OCR works the same for all states/countries, including those with multiple line number plates. @MikeLud1 has taken care to ensure this works, and I have tried to continue that in the AI training export.

As far as mac addresses go, you're talking about BLE or WiFi. It's not so much a matter of make/model, as nearly all cars nowadays have Bluetooth, nor a matter of their randomness, as even law enforcement can't really pinpoint a vehicle by its mac address. It's more of a BLE/WiFi protocol challenge, and staying within the bounds of the FCC regulations. The goal with the TPMS, for example, is not to be able to provide the TPMS ID to law enforcement, but to be able to associate the TPMS ID to a license plate that you can then use. The same would be true for any other sort of uniquely identifiable RF.

We will experiment with WiFi/Bluetooth after we have a verdict on the usability of the TPMS system, as that is our most promising form of PII.
 
algertc said:
When I get a chance to work on this, I'll update the scripts to have them check themselves this way. Ty for the idea.
Click to expand...
I've done this:
Bash: 
root@alpr:/opt/ALPR_Database# docker compose down
[+] Running 3/3
 ✔ Container alpr_database-app-1  Removed                                                                                      1.2s
 ✔ Container alpr_database-db-1   Removed                                                                                     11.2s
 ✔ Network alpr_database_default  Removed                                                                                      0.3s
root@alpr:/opt/ALPR_Database# docker compose pull
[+] Pulling 2/2
 ✔ db Pulled                                                                                                                   0.8s
 ✔ app Pulled                                                                                                                  0.8s
root@alpr:/opt/ALPR_Database# docker compose up -d
[+] Running 3/3
 ✔ Network alpr_database_default  Created                                                                                      0.1s
 ✔ Container alpr_database-db-1   Started                                                                                      1.8s
 ✔ Container alpr_database-app-1  Started                                                                                      2.4s
root@alpr:/opt/ALPR_Database#
md5:
root@alpr:/opt/ALPR_Database# md5sum *.sql
68299a0cc953f95cf27525b3c3023d41 migrations.sql
9caab0fb987b904a13f3e325f5fa5fbe schema.sql


And still have the No Stream 500 response. Not one plate has be successful in posting to the app. Is it possible this is because I'm a fresh install and not an update? Some issue that hasn't been caught with most people doing updates? If not, I've done two fresh installs, one on my Windows BI machine and this one on a separate linux VM, both showing the same error which points me to BI. But I have no idea where to look. I've reduced the recorded images to as small and poor as they go and still see the error. Any ideas of other places to look would be great as I really want this to work.

Cheers.
 
You must log in or register to reply here.
Top Bottom