Very clear instructions. I've made the changes. I don't have night cameras on line yet so it will be tomorrow morning that I hope I wake up to a screen full of images, graphs, and plate data. Thanks much for your guidance.
Full ALPR Database System for Blue Iris!
- Thread starter algertc
- Start date
Drat! I should have spoken up louder and saved a lot of time:
Yep, right on, as usual. The below is also very helpful to me for writing the troubleshooting page. Docs are almost finished. Not likely to add any value for anyone who has been following along, but should be much better for new users. Can serve as a reference too.
I'm also going to record two new install videos (linux/windows) once they're finished and embed them in the install guide pages. Probably will end up being like 60 seconds long with the install scripts, but it's always nice to have a visual to know you're doing it right.
I'm also going to record two new install videos (linux/windows) once they're finished and embed them in the install guide pages. Probably will end up being like 60 seconds long with the install scripts, but it's always nice to have a visual to know you're doing it right.
@smallik Upon closer inspection of your log screenshot, the fact that it's complaining about tags being missing doesn't track with the issue being caused by just the migrations file missing. I'm thinking that may not quite fix it.
I don't really understand how this happened the first time around if you used the install script since it is supposed to check all of these things to make sure that things like this don't happen.
I looked back through the code to see if any changes could have caused the error, and it looks ok to me. It's possible that the connection could have dropped halfway through the download when you originally installed, which caused it to only write a partial file for the schema.sql. A pretty rare situation, but possible, and the only explanation I can think of. I can see from my metrics that other recent installs have worked fine.
Docker containers store data in special locations called Docker volumes. It's possible that reinstalling Docker didn't remove the original database volume, causing the error to persist despite your fresh install of the alpr database.
My new recommendation to you is the following (you should be able to do all of this in the Docker Desktop GUI):
1) Turn off/shut down the containers with the little square button. It may take a few seconds for them to shut down.
2) Delete the containers with the trashcan
3) Navigate to the volumes tab in the left navbar. Delete all of the volumes.
4) Now, we should have a clean slate and you should be able to open powershell and run docker compose up -d from the directory where your files are placed, just like before.
I completely agree, even as a frequent user, that setting up elaborate Docker Compose apps can be daunting because you kind of have to get familiar with the configuration for each specific app, but it's really not as bad as it looks. Also, while less intuitive to install with Docker, it's infinitely more flexible and reliable once you have it going. It keeps everything isolated and standardized so it can live in its own world and handle any issues or failures on its own without you ever having to mess with it.
I'm happy to help in PM if somehow it's still complaining after that.
I don't really understand how this happened the first time around if you used the install script since it is supposed to check all of these things to make sure that things like this don't happen.
I looked back through the code to see if any changes could have caused the error, and it looks ok to me. It's possible that the connection could have dropped halfway through the download when you originally installed, which caused it to only write a partial file for the schema.sql. A pretty rare situation, but possible, and the only explanation I can think of. I can see from my metrics that other recent installs have worked fine.
Docker containers store data in special locations called Docker volumes. It's possible that reinstalling Docker didn't remove the original database volume, causing the error to persist despite your fresh install of the alpr database.
My new recommendation to you is the following (you should be able to do all of this in the Docker Desktop GUI):
1) Turn off/shut down the containers with the little square button. It may take a few seconds for them to shut down.
2) Delete the containers with the trashcan
3) Navigate to the volumes tab in the left navbar. Delete all of the volumes.
4) Now, we should have a clean slate and you should be able to open powershell and run docker compose up -d from the directory where your files are placed, just like before.
I completely agree, even as a frequent user, that setting up elaborate Docker Compose apps can be daunting because you kind of have to get familiar with the configuration for each specific app, but it's really not as bad as it looks. Also, while less intuitive to install with Docker, it's infinitely more flexible and reliable once you have it going. It keeps everything isolated and standardized so it can live in its own world and handle any issues or failures on its own without you ever having to mess with it.
I'm happy to help in PM if somehow it's still complaining after that.
Last edited:
I've been thinking about the TPMS solution, and I think I have a significantly better approach. I consulted a friend with more electronics expertise to ask about making something a bit more custom, and this seems like the way.
The last thing I tried was 2x RTL-SDRs w a Raspberry Pi and a POE hat. Felt like kind of a heavy-handed solution, is sort of expensive for what it is, generates a ton of heat, not very feasible to power with solar, and is prone to SDR inaccuracy.
Here's a rough idea of what I'm thinking instead:
Would be super tiny with minimal heat and very sensitive. Looks like about $30-50 with nice parts. At that price, I'm wondering if maybe I should try a double setup at both ends of the yard for maximum capture probability.
Picture something like this, but fully enclosed and with more rudimentary controls...
The last thing I tried was 2x RTL-SDRs w a Raspberry Pi and a POE hat. Felt like kind of a heavy-handed solution, is sort of expensive for what it is, generates a ton of heat, not very feasible to power with solar, and is prone to SDR inaccuracy.
Here's a rough idea of what I'm thinking instead:
- ESP32 POE OR Teensy 4.1 microcontroller
- Texas Instruments CC1101 Receiver - OR, for $4.50 more, the automotive-rated version, which is rated for high heat
- Antennas: 315 433
- Misc connectors + screws + acrylic
- OLED screen or LED indicators to know if it's working/broken
Would be super tiny with minimal heat and very sensitive. Looks like about $30-50 with nice parts. At that price, I'm wondering if maybe I should try a double setup at both ends of the yard for maximum capture probability.
Picture something like this, but fully enclosed and with more rudimentary controls...
algertc, so, after your post# 660, I did nothing else but follow those instructions. I woke up this morning and after the sun started to illuminate the road, my system began to catch fish (I mean license plates). Yahoo! Before I do anything else, I'm going to save an image of the hard drive so I'll always have a recovery point once I start banging around on things. Thanks so much for the help. One quick question: Is there an option for the ALPR Database to auto refresh if I'm just sitting on the license plate dashboard?
Not for the dashboard, but there is on the next tab down on the ALPR Recognition Feed (aka "Live Feed")