Full ALPR Database System for Blue Iris!

Rules engine preview.

1774199989923.png
1774199997856.png


This has the added benefit that the flagged feature might actually become useful with this.

Take these conditions with a grain of salt. Not done. The times seen (24h) one, for ex, will be more granular. Open to any suggestions though.
 
Last edited:
  • Like
  • Love
Reactions: Spooling, VideoDad, MikeLud1 and 2 others
algertc said:
Rules engine preview.

View attachment 240445View attachment 240446

This has the added benefit that the flagged feature might actually become useful with this.

Take these conditions with a grain of salt. Not done. The times seen (24h) one, for ex, will be more granular. Open to any suggestions though.
Click to expand...
This looks pretty neat and can't wait (I mean I can wait, but I don't want to).

Is this in the new architecture application you're working on? I'm also hoping there will be a way to run both the old and new versions concurrently (I assume with separate databases and separate ports but hopefully identical calls), at least until we've assured feature parity, plus it would probably help with debugging while keeping the production system going in the meantime.

Edit: I imagine the flagging or tagging feature could be useful for finding items to be reviewed.
 
@VideoDad Glad to hear it - I was thinking about you when I posted that haha.

Yes, it will all be part of the same update. You could always make a copy of your directory and then spin up a duplicate on another port to run the upgrade on.

I have both my database dump as well as some from others that I haven’t gotten to yet (thanks all for sending). There are a bunch of tests for almost every functionality now that will run every time an update is made to try to ensure that everything functions as it should.

I’d be surprised if any of the existing features stopped working properly. The main thing that is slightly iffy is the whole database migration. My tests will ensure that it succeeds on all the dumps I have, but since people have run some commands altering their databases, I can’t be completely positive it will work without issue. That being said, I did add a check first to verify that your current schema is as the code expects and can take the migration. If for some reason it were different and couldn’t upgrade, it should just tell you it can’t do it. It won’t try anyways and then break it.

Another note about this automation functionality - I still don’t love the “redirect”/rewrite to correct plate functionality that several requested, but since it’s an easy thing to add here now, I will add an edit plate number action to the automations. I like this because it doesn’t require me to explicitly build in and support that workaround, but still offers a solution for those who wanted it. If you now want to create an “automation” on your system that happens to try to correct misreads automatically, nothing will stop you from doing that.


I’m still not finished. Didn’t make as much progress as I wanted yesterday. Claude Opus has been really hit or miss for me lately. One day it works incredibly well - the next it’s like it’s a completely different model. All with the same prompts.

Ended up having to do a lot of the automations stuff manually because of this, so I didn’t get to much else.

The outstanding items as of now that I still want to add are the following:

  • Stolen car check
  • Decide how to do the embeddings for semantic search
  • Backfilling detections from blue iris for new installs
  • Back up/export data
  • Add that crazy data table I shared before as an advanced mode to allow for a more “power user” level viewing and search for the live feed.
  • A system monitoring page. My BI randomly dies every once in a while and it often takes me a bit to notice. I want to add simple health checks for BI and CPAI so that I can get a notification if they ever go down. Additionally this page will show load stats for the computer as well as graph the inference time for the AI to show if performance starts degrading or other trends.


Should be a nice big update for the first time in a while. I’ve built up a pretty horrendous track record for time estimates here, but just bear with me while I find time for this please :)


Any other suggestions welcome
 
Last edited:
  • Like
Reactions: PeteJ and prsmith777
algertc said:
@VideoDad Glad to hear it - I was thinking about you when I posted that haha.

Yes, it will all be part of the same update. You could always make a copy of your directory and then spin up a duplicate on another port to run the upgrade on.

I have both my database dump as well as some from others that I haven’t gotten to yet (thanks all for sending). There are a bunch of tests for almost every functionality now that will run every time an update is made to try to ensure that everything functions as it should.

I’d be surprised if any of the existing features stopped working properly. The main thing that is slightly iffy is the whole database migration. My tests will ensure that it succeeds on all the dumps I have, but since people have run some commands altering their databases, I can’t be completely positive it will work without issue. That being said, I did add a check first to verify that your current schema is as the code expects and can take the migration. If for some reason it were different and couldn’t upgrade, it should just tell you it can’t do it. It won’t try anyways and then break it.

Another note about this automation functionality - I still don’t love the “redirect”/rewrite to correct plate functionality that several requested, but since it’s an easy thing to add here now, I will add an edit plate number action to the automations. I like this because it doesn’t require me to explicitly build in and support that workaround, but still offers a solution for those who wanted it. If you now want to create an “automation” on your system that happens to try to correct misreads automatically, nothing will stop you from doing that.


I’m still not finished. Didn’t make as much progress as I wanted yesterday. Claude Opus has been really hit or miss for me lately. One day it works incredibly well - the next it’s like it’s a completely different model. All with the same prompts.

Ended up having to do a lot of the automations stuff manually because of this, so I didn’t get to much else.

The outstanding items as of now that I still want to add are the following:

  • Stolen car check
  • Decide how to do the embeddings for semantic search
  • Backfilling detections from blue iris for new installs
  • Back up/export data
  • Add that crazy data table I shared before as an advanced mode to allow for a more “power user” level viewing and search for the live feed.
  • A system monitoring page. My BI randomly dies every once in a while and it often takes me a bit to notice. I want to add simple health checks for BI and CPAI so that I can get a notification if they ever go down. Additionally this page will show load stats for the computer as well as graph the inference time for the AI to show if performance starts degrading or other trends.


Should be a nice big update for the first time in a while. I’ve built up a pretty horrendous track record for time estimates here, but just bear with me while I find time for this please :)


Any other suggestions welcome
Click to expand...
I really hope you'll reconsider and add a table of common misreads to each known plate and add the ability to autocorrect the plates.

The main use case I have is not an error with the recognition. I have few neighbors who have license plate frames that cover the bottom of the letters. Think E looking like F, or I looking like T. The front plates do not have this issue because the frame isn't there or is smaller. So when the front-facing camera captures the plate it sees the correct letter (E or I) but the rear-facing camera sees F or T. No amount of tweaking the OCR algorithm would fix this 100%

When manually correcting the plate (constantly) it would be really nice to be able to have the option to add the bad detection to the misread table. Then when the misread plate is detected in the future, it is autocorrected. People that don't want this feature could just not add it to the misread plate table.

Alternatively, if you want to require it be done via rules, it would be really nice if the ability to create such an "autocorrect rule" could still be an option we could choose during manual correction (just like the choices for correcting all plates and deleting the plate). So instead of it being a table of misreads tied the correct plate, it would be an autogenerated rule.

I'm just saying this autocorrect is a feature that multiple people have requested to save a lot of regular manual correction. Anything that could eliminate that tedium would be a welcome feature.

I still think the misread table would be an easier, cleaner implementation but I could live with the rule implementation as long it could be (optionally) created during the manual correction.

Think about it...
 
  • Like
Reactions: prsmith777 and PeteJ
VideoDad said:
I really hope you'll reconsider and add a table of common misreads to each known plate and add the ability to autocorrect the plates.

The main use case I have is not an error with the recognition. I have few neighbors who have license plate frames that cover the bottom of the letters. Think E looking like F, or I looking like T. The front plates do not have this issue because the frame isn't there or is smaller. So when the front-facing camera captures the plate it sees the correct letter (E or I) but the rear-facing camera sees F or T. No amount of tweaking the OCR algorithm would fix this 100%

When manually correcting the plate (constantly) it would be really nice to be able to have the option to add the bad detection to the misread table. Then when the misread plate is detected in the future, it is autocorrected. People that don't want this feature could just not add it to the misread plate table.

Alternatively, if you want to require it be done via rules, it would be really nice if the ability to create such an "autocorrect rule" could still be an option we could choose during manual correction (just like the choices for correcting all plates and deleting the plate). So instead of it being a table of misreads tied the correct plate, it would be an autogenerated rule.

I'm just saying this autocorrect is a feature that multiple people have requested to save a lot of regular manual correction. Anything that could eliminate that tedium would be a welcome feature.

I still think the misread table would be an easier, cleaner implementation but I could live with the rule implementation as long it could be (optionally) created during the manual correction.

Think about it...
Click to expand...

I think you and I have the same kind of neighbors. Mine also likes to go skiing and never wash their truck's plate. I would also love to have this feature, for the same reasons.
 
I concur that using an automation would work for correcting so long as there is there is an easy way to create one during the correct plate process. One of the neighbors has a hitch ball that obstructs a letter on the rear plate but is not an issue on the front. So auto correcting that rear plate would be helpful!

Would it also be beneficial to somehow flag auto-corrected plates? That way when looking at the live feed you know that one was corrected for the rare case that an auto-correct might be wrong?

It would also be beneficial to list multiple plates for one vehicle so all those reads show under stats as one “plate” metric. New cars in my state get a temp plate for up to 45 days before their true plate is issued. And every 10 years or so the state issues a new plate for the vehicle that has a different alphanumeric.

As it is now, once a cars permanent plate is issued, I either have to live with it being in the database two ways, or go in and correct the temp tag to the new plate. Or I’ll see a new car frequenting our street only to figure out one of the neighbors just got new plates.

Just spitting out ideas to see the groups thoughts!


Sent from my iPhone using Tapatalk
 
One thing you could do is to find one instance of the old (retired) plate in the plates read table and treat it as a correction to the new plate. Toggle the setting for doing all plate reads and they'll now all point to the new plate.

So if it was 7OLD777 and is now 8NEW888, then all the previous reads would become 8NEW888. The total counts and last seen, etc. should be consolidated under the new plate.
 
VideoDad said:
I really hope you'll reconsider and add a table of common misreads to each known plate and add the ability to autocorrect the plates.

The main use case I have is not an error with the recognition. I have few neighbors who have license plate frames that cover the bottom of the letters. Think E looking like F, or I looking like T. The front plates do not have this issue because the frame isn't there or is smaller. So when the front-facing camera captures the plate it sees the correct letter (E or I) but the rear-facing camera sees F or T. No amount of tweaking the OCR algorithm would fix this 100%

When manually correcting the plate (constantly) it would be really nice to be able to have the option to add the bad detection to the misread table. Then when the misread plate is detected in the future, it is autocorrected. People that don't want this feature could just not add it to the misread plate table.

Alternatively, if you want to require it be done via rules, it would be really nice if the ability to create such an "autocorrect rule" could still be an option we could choose during manual correction (just like the choices for correcting all plates and deleting the plate). So instead of it being a table of misreads tied the correct plate, it would be an autogenerated rule.

I'm just saying this autocorrect is a feature that multiple people have requested to save a lot of regular manual correction. Anything that could eliminate that tedium would be a welcome feature.

I still think the misread table would be an easier, cleaner implementation but I could live with the rule implementation as long it could be (optionally) created during the manual correction.

Think about it...
Click to expand...
I also would like to request this.
 
VideoDad said:
One thing you could do is to find one instance of the old (retired) plate in the plates read table and treat it as a correction to the new plate. Toggle the setting for doing all plate reads and they'll now all point to the new plate.

So if it was 7OLD777 and is now 8NEW888, then all the previous reads would become 8NEW888. The total counts and last seen, etc. should be consolidated under the new plate.
Click to expand...

This is how I’ve done it a few times now. Feels “wrong” when looking at an entry under the old plate and seeing the new plate listed although I know why I changed it. I figured someone smarter than I might have an idea for an official functionality for this :)


Sent from my iPhone using Tapatalk
 
This all sounds great! Not sure if what you're planning on could detect the following scenario?

We recently had some people break into a neighbors house. A couple of them were on foot and the getaway vehicle was driving back and forth waiting to pick them up. Would there be someway of flagging a suspicious vehicle like this? I guess the criteria would be that it's a new plate detection, but it's been seen X many times within Y window of time?
 
algertc said:
@VideoDad Glad to hear it - I was thinking about you when I posted that haha.

Yes, it will all be part of the same update. You could always make a copy of your directory and then spin up a duplicate on another port to run the upgrade on.

I have both my database dump as well as some from others that I haven’t gotten to yet (thanks all for sending). There are a bunch of tests for almost every functionality now that will run every time an update is made to try to ensure that everything functions as it should.

I’d be surprised if any of the existing features stopped working properly. The main thing that is slightly iffy is the whole database migration. My tests will ensure that it succeeds on all the dumps I have, but since people have run some commands altering their databases, I can’t be completely positive it will work without issue. That being said, I did add a check first to verify that your current schema is as the code expects and can take the migration. If for some reason it were different and couldn’t upgrade, it should just tell you it can’t do it. It won’t try anyways and then break it.

Another note about this automation functionality - I still don’t love the “redirect”/rewrite to correct plate functionality that several requested, but since it’s an easy thing to add here now, I will add an edit plate number action to the automations. I like this because it doesn’t require me to explicitly build in and support that workaround, but still offers a solution for those who wanted it. If you now want to create an “automation” on your system that happens to try to correct misreads automatically, nothing will stop you from doing that.


I’m still not finished. Didn’t make as much progress as I wanted yesterday. Claude Opus has been really hit or miss for me lately. One day it works incredibly well - the next it’s like it’s a completely different model. All with the same prompts.

Ended up having to do a lot of the automations stuff manually because of this, so I didn’t get to much else.

The outstanding items as of now that I still want to add are the following:

  • Stolen car check
  • Decide how to do the embeddings for semantic search
  • Backfilling detections from blue iris for new installs
  • Back up/export data
  • Add that crazy data table I shared before as an advanced mode to allow for a more “power user” level viewing and search for the live feed.
  • A system monitoring page. My BI randomly dies every once in a while and it often takes me a bit to notice. I want to add simple health checks for BI and CPAI so that I can get a notification if they ever go down. Additionally this page will show load stats for the computer as well as graph the inference time for the AI to show if performance starts degrading or other trends.


Should be a nice big update for the first time in a while. I’ve built up a pretty horrendous track record for time estimates here, but just bear with me while I find time for this please :)


Any other suggestions welcome
Click to expand...
Still bearing with you, but hoping for news soon.
 
I'm also waiting to see what new things come, especially in regards to BI v6 and ALPR-Database. What I'm noticing at the moment, is it seems that BI is not consistently sending the JPEG image that coincides with the plate coordinates it is using to do the ALPR on. It's a small sample size at the moment, but 3 out 4 (so far) of the JSON POSTs I've capture have the wrong coordinates for the corresponding JPEG. Is there a different variable other than &ALERT_JPEG that will make sure the JPEG matches to the detected ALPR plate?
 
mrlindstrom said:
I'm also waiting to see what new things come, especially in regards to BI v6 and ALPR-Database. What I'm noticing at the moment, is it seems that BI is not consistently sending the JPEG image that coincides with the plate coordinates it is using to do the ALPR on. It's a small sample size at the moment, but 3 out 4 (so far) of the JSON POSTs I've capture have the wrong coordinates for the corresponding JPEG. Is there a different variable other than &ALERT_JPEG that will make sure the JPEG matches to the detected ALPR plate?
Click to expand...
The changelog for update 6.0.4.5.might be relevant to this issue... if there are secondary issues form the 2nd bullet below.

1775659895160.png
 
I updated to that version but it didn't seem to have an effect, so it must be somewhere else where the JPEG is being chosen separate from the license plat coords.
 
Anyone run into a issue where their database freezes?

Every 24-48hrs my container will freeze and I have to restart the container manually. I just reinstalled W11 and reinstalled docker fresh and it’s still doing it
 
adventuredphoto said:
Anyone run into a issue where their database freezes?

Every 24-48hrs my container will freeze and I have to restart the container manually. I just reinstalled W11 and reinstalled docker fresh and it’s still doing it
Click to expand...
Yup. It's got either a runaway process or a memory leak or both, and the Docker contain will ramp up to 400% CPU and/or many GBs for RAM and bring the machine to its knees.

I did a brief amount of googling on how to put a watchdog on the container to restart in when this happens, but I didn't get very far, hoping that the problem might magically fix itself.

Does anyone know how to watchdog a container? I tried this one, but it didn't do anything that I could detect, and then I saw that it was last updated 5 years ago.

This one was updated 11 months ago, so maybe it's worth a shot.

edit: ah, now I remember why I didn't try the second one. Setup seems non-trivial, and I think it relies on also setting up other services, such as Uptime Kuma, so I stopped reading.

Maybe I'll start reading the instructions again.
 
Last edited:
TheWaterbug said:
Yup. It's got either a runaway process or a memory leak or both, and the Docker contain will ramp up to 400% CPU and/or many GBs for RAM and bring the machine to its knees.

I did a brief amount of googling on how to put a watchdog on the container to restart in when this happens, but I didn't get very far, hoping that the problem might magically fix itself.

Does anyone know how to watchdog a container? I tried this one, but it didn't do anything that I could detect, and then I saw that it was last updated 5 years ago.

This one was updated 11 months ago, so maybe it's worth a shot.

edit: ah, now I remember why I didn't try the second one. Setup seems non-trivial, and I think it relies on also setting up other services, such as Uptime Kuma, so I stopped reading.

Maybe I'll start reading the instructions again.
Click to expand...
Yep same exact thing is happening here
 
For some reason I'm not seeing these performance issues, my container has been up 4 days and cpu usage sits around 3% with some spikes to 11%, but nothing crazy. RAM usage is at 54MB. I did have to do some manual fixes on the DB to fix some of the greenfield issues, so maybe that helped fix some other performance ones?

I believe this has the list of things I adjusted:

SQL: 
-- 1) Fix plate_notifications.id so it auto-increments
CREATE SEQUENCE plate_notifications_id_seq;

ALTER TABLE plate_notifications
ALTER COLUMN id SET DEFAULT nextval('plate_notifications_id_seq');

ALTER SEQUENCE plate_notifications_id_seq
OWNED BY plate_notifications.id;

SELECT setval(
    'plate_notifications_id_seq',
    COALESCE((SELECT MAX(id) FROM plate_notifications), 1)
);

-- 2) Ensure plate_notifications has the proper primary key on id
ALTER TABLE plate_notifications
ADD CONSTRAINT plate_notifications_pkey PRIMARY KEY (id);

-- 3) Ensure plate_notifications.plate_number is unique
ALTER TABLE plate_notifications
ADD CONSTRAINT plate_notifications_plate_number_key UNIQUE (plate_number);

-- 4) Fix known_plates so ON CONFLICT (plate_number) works
ALTER TABLE known_plates
ADD CONSTRAINT known_plates_pkey PRIMARY KEY (plate_number);

-- 5) Fix plate_reads so id is the primary key
ALTER TABLE plate_reads
ADD CONSTRAINT plate_reads_pkey PRIMARY KEY (id);

-- 6) Fix plate_tags so the join table has a composite primary key
ALTER TABLE plate_tags
ADD CONSTRAINT plate_tags_pkey PRIMARY KEY (plate_number, tag_id);

-- 7) Fix tags.id so it auto-increments
CREATE SEQUENCE tags_id_seq;

ALTER TABLE tags
ALTER COLUMN id SET DEFAULT nextval('tags_id_seq');

ALTER SEQUENCE tags_id_seq
OWNED BY tags.id;

SELECT setval(
    'tags_id_seq',
    COALESCE((SELECT MAX(id) FROM tags), 1)
);

-- 8) Fix tags so id is the primary key
ALTER TABLE tags
ADD CONSTRAINT tags_pkey PRIMARY KEY (id);
 
mrlindstrom said:
For some reason I'm not seeing these performance issues, my container has been up 4 days and cpu usage sits around 3% with some spikes to 11%, but nothing crazy. RAM usage is at 54MB. I did have to do some manual fixes on the DB to fix some of the greenfield issues, so maybe that helped fix some other performance ones?

I believe this has the list of things I adjusted:

SQL: 
-- 1) Fix plate_notifications.id so it auto-increments
CREATE SEQUENCE plate_notifications_id_seq;

ALTER TABLE plate_notifications
ALTER COLUMN id SET DEFAULT nextval('plate_notifications_id_seq');

ALTER SEQUENCE plate_notifications_id_seq
OWNED BY plate_notifications.id;

SELECT setval(
    'plate_notifications_id_seq',
    COALESCE((SELECT MAX(id) FROM plate_notifications), 1)
);

-- 2) Ensure plate_notifications has the proper primary key on id
ALTER TABLE plate_notifications
ADD CONSTRAINT plate_notifications_pkey PRIMARY KEY (id);

-- 3) Ensure plate_notifications.plate_number is unique
ALTER TABLE plate_notifications
ADD CONSTRAINT plate_notifications_plate_number_key UNIQUE (plate_number);

-- 4) Fix known_plates so ON CONFLICT (plate_number) works
ALTER TABLE known_plates
ADD CONSTRAINT known_plates_pkey PRIMARY KEY (plate_number);

-- 5) Fix plate_reads so id is the primary key
ALTER TABLE plate_reads
ADD CONSTRAINT plate_reads_pkey PRIMARY KEY (id);

-- 6) Fix plate_tags so the join table has a composite primary key
ALTER TABLE plate_tags
ADD CONSTRAINT plate_tags_pkey PRIMARY KEY (plate_number, tag_id);

-- 7) Fix tags.id so it auto-increments
CREATE SEQUENCE tags_id_seq;

ALTER TABLE tags
ALTER COLUMN id SET DEFAULT nextval('tags_id_seq');

ALTER SEQUENCE tags_id_seq
OWNED BY tags.id;

SELECT setval(
    'tags_id_seq',
    COALESCE((SELECT MAX(id) FROM tags), 1)
);

-- 8) Fix tags so id is the primary key
ALTER TABLE tags
ADD CONSTRAINT tags_pkey PRIMARY KEY (id);
Click to expand...
Interesting. I'll give it a shot. If anyone wants to know how to run this is paste it into a notepad doc and save it as fix_schema.sql
Then run the following in powershell

Get-Content fix_schema.sql | docker exec -i alprdb-db-1 psql -U postgres -d postgres
 
TheWaterbug said:
Yup. It's got either a runaway process or a memory leak or both, and the Docker contain will ramp up to 400% CPU and/or many GBs for RAM and bring the machine to its knees.

I did a brief amount of googling on how to put a watchdog on the container to restart in when this happens, but I didn't get very far, hoping that the problem might magically fix itself.

Does anyone know how to watchdog a container? I tried this one, but it didn't do anything that I could detect, and then I saw that it was last updated 5 years ago.
Click to expand...

I use Home Assistant to monitor the RAM usage on my Proxmox that host Debian VM that runs Docker and runs both ALRP database and CodeProject.
From Home Assistant, I can either restart the entire Debian VM or restart the container using SSH commands.
 
You must log in or register to reply here.
Top Bottom