Full ALPR Database System for Blue Iris!

VideoDad said:
I'm sorry to ask this, but I could use a little more direction on how to get started. I'm not even understanding where this installation script is and how to start it. Also, I have Docker running on the same Windows machine as Blue Iris. Is this sufficient? Can I use WSL as the Linus VM?
Click to expand...
You left out details of your machine's specs.

I use Proxmox to host multiple virtual machines, I run Windows with BI, first Debian with docker to host CodeProject.ai and ALPR, second Debian to host the lastest prsmith777's ALPR so I can test, Home Assistant, and third Debian for SMTP, on a i9-9900t host with 32GB of ram and 500gb ssd and everything works great. I have 5 LPR cameras and 12 other cameras.

ALPR doesn't need a lot of cpu power or ram, but it does need storage space to store the license plate.

I installed WSL on my laptop, but that's as far as I got. After install WSL, it was suppose to install Ubuntu, but it never did. So this is as far as I can help you with WSL.

I would highly recommend Proxmox, but downside is you'll have to reinstall Windows and lose all your current footage.
 
iwanttosee said:
You left out details of your machine's specs.

I use Proxmox to host multiple virtual machines, I run Windows with BI, first Debian with docker to host CodeProject.ai and ALPR, second Debian to host the lastest prsmith777's ALPR so I can test, Home Assistant, and third Debian for SMTP, on a i9-9900t host with 32GB of ram and 500gb ssd and everything works great. I have 5 LPR cameras and 12 other cameras.
Cameras

ALPR doesn't need a lot of cpu power or ram, but it does need storage space to store the license plate.

I installed WSL on my laptop, but that's as far as I got. After install WSL, it was suppose to install Ubuntu, but it never did. So this is as far as I can help you with WSL.

I would highly recommend Proxmox, but downside is you'll have to reinstall Windows and lose all your current footage.
Click to expand...
I have a Dell
iwanttosee said:
You left out details of your machine's specs.

I use Proxmox to host multiple virtual machines, I run Windows with BI, first Debian with docker to host CodeProject.ai and ALPR, second Debian to host the lastest prsmith777's ALPR so I can test, Home Assistant, and third Debian for SMTP, on a i9-9900t host with 32GB of ram and 500gb ssd and everything works great. I have 5 LPR cameras and 12 other cameras.

ALPR doesn't need a lot of cpu power or ram, but it does need storage space to store the license plate.

I installed WSL on my laptop, but that's as far as I got. After install WSL, it was suppose to install Ubuntu, but it never did. So this is as far as I can help you with WSL.

I would highly recommend Proxmox, but downside is you'll have to reinstall Windows and lose all your current footage.
Click to expand...
My Blue Iris PC is a Dell SFF 8050 with a 6th Gen i7 CPU, 16GB RAM, 256GB SSD and a 6TB HDD running Windows 10. No separate GPU. It's running Blue Iris 5.9.9.88, CP.AI and Docker for ALPR DB.

I'm not sure if I'm ready to convert it to a Linux box running a virtualized Windows OS. Is that the only way forward? And would this hardware be capable?
 
VideoDad said:
I have a Dell

My Blue Iris PC is a Dell SFF 8050 with a 6th Gen i7 CPU, 16GB RAM, 256GB SSD and a 6TB HDD running Windows 10. No separate GPU. It's running Blue Iris 5.9.9.88, CP.AI and Docker for ALPR DB.

I'm not sure if I'm ready to convert it to a Linux box running a virtualized Windows OS. Is that the only way forward? And would this hardware be capable?
Click to expand...
In the computer world, there are a LOT of way to accomplish the same thing. Can it work? Probably. Can YOU get it to work? That's for you to find out.

As for hardware, again, I don't know the details of your system nor cameras you have. How is it running now with your current setup? If it runs fine, the you shouldn't have issues with the new ALPR database.
 
iwanttosee said:
In the computer world, there are a LOT of way to accomplish the same thing. Can it work? Probably. Can YOU get it to work? That's for you to find out.

As for hardware, again, I don't know the details of your system nor cameras you have. How is it running now with your current setup? If it runs fine, the you shouldn't have issues with the new ALPR database.
Click to expand...
I have it all working fine with 9 cameras and the existing ALPR DB with native Windows. I'm just asking @prsmith777 if there is any easy way to setup his new community version but under Windows instead of having to switch to a Linux VM, or Linux running a Windows VM.
 
VideoDad said:
I have it all working fine with 9 cameras and the existing ALPR DB with native Windows. I'm just asking @prsmith777 if there is any easy way to setup his new community version but under Windows instead of having to switch to a Linux VM, or Linux running a Windows VM.
Click to expand...
No native windows support at this time. Will explore options though
 
VideoDad said:
I have a Dell

My Blue Iris PC is a Dell SFF 8050 with a 6th Gen i7 CPU, 16GB RAM, 256GB SSD and a 6TB HDD running Windows 10. No separate GPU. It's running Blue Iris 5.9.9.88, CP.AI and Docker for ALPR DB.

I'm not sure if I'm ready to convert it to a Linux box running a virtualized Windows OS. Is that the only way forward? And would this hardware be capable?
Click to expand...
I have recently migrated 3 installations of BI from bare metal to virtualized instances. It wasn't painless by any means, but with Claude's help I got it all done:
  1. Motivations: security and stability
    1. I wanted to isolate, as much as possible, the BI PC from the rest of my network, while still allowing me to administer the machine and use my existing backup system (Veeam), and while still permitting port-forwarding as the easiest way to enable remote access. If properly isolated, the odds of a compromised VM leaking into the rest of my network is very, very slim.
    2. I wanted to eliminate crapware, bloatware, Clippy, Copilot, unwanted Windows updates, and the stall-on-reboot where the latest update is asking if I want to set up Windows backup, again, after I've declined it 50x. The security implications of this are also pretty huge.
  2. All 3 previously ran BI 6 directly on Win11 Pro.
    1. All three had Docker containers installed directly in Win11, two to run Wyze-Docker containers for RTSP relay (no longer needed) and one to run ALPR-Database
  3. All 3 now run Server 2022 as HyperV hosts with Server 2022 VMs inside to run BI.
    1. The one remaining Docker container for ALPR-Database now runs in a lightweight Debian VM, for better isolation and resource control.
    2. Video storage is on a separate physical disk (or enclosure) from the OS, which I believe nearly all of us are already doing.
    3. I added a 2nd NIC to each box.
      1. The original NIC keeps the original boxes' IP address and serves Blue Iris traffic. The outside world, e.g. web clients, don't know that anything has changed.
      2. The second NIC is my management NIC, on a separate VLAN, where I manage the VM host and backup.
  4. Good things and gotchas I ran into:
    1. On migrations 2 and 3 I realized I could set up the VM first beforemigrating the host to Server 2022, since Win11 Pro (and Win10 Pro) include HyperV already, for free.
      1. I configured the HyperV virtual switch to assign IPs as described above, connected the new NIC to my management VLAN, and ensure that it was working, then disabled the BI NIC/IP from the management group.
      2. I installed Server 2022 inside the VM, did all available updates, installed BI, restored a backup of the BI config, and verified successful communication with all of my cameras, before proceeding. It had no access to the video storage drive (V:\ in my case), but I was able to verify everything else.
      3. I also set up the Debian VM and installed the latest ALPR-Database.
      4. Then I turned off the BI service on the host computer, made the V: drive a "pass-through disk" to the VM, and rebooted the VM. Blue Iris came right back up with very little downtime, and all my historical footage intact.
    2. Once the VM was up and running I was able to start installation of Server 2022 over my Win11 installation.
      1. If you don't reformat your installation drive, you will not destroy your VM! It'll be on the C: drive, right where you created it, and once Server 2022's HyperV is running, you can adopt/import it and have it running in a few seconds.
      2. Your BI instance in the VM will even run, and record video, during the first part of Server 2022 installation! You won't have any downtime until the first reboot.
    3. On some generations of PCs, like my Lenovo box, have a CPU that's incompatible with HyperV on early versions of Server 2022.
      1. This makes the box unbootable as soon as you enable HyperV, requiring a boot into the Windows Recovery Environment to type in commands to disable HyperV to recover the box.
      2. The fix is to install all available Server 2022 updates before enabling HyperV.
    4. Some NICs, like this cheapie TPLink card, don't have signed drivers for Server 2022.
      1. You can get them to install, but you have to create a custom .inf file and disable driver signing for one boot, after which it will load properly.
      2. It will run fine under Win10/Win11, and then fail on first reboot after Server 2022 installation.
    5. Once Server 2022 is installed and updated, adopt/import the BI VM and set it to start up automatically every time the host PC starts.
      1. Also set up the pass-through disk to auto-mount if it ever goes offline and then comes back online. Otherwise, if the VM starts up and it's not available, it will mark it as Offline, and it won't automatically restore the connection, even if you reboot.
    6. So, if you don't run into CPU/HyperV or NIC driver issues, you can do this whole process with less than an hour's worth of true downtime/missed footage.
      1. If you run into either of these, you'll spend a few hours debugging while the VM is down.
So all is well that ends well. If I ever have to do a 4th migration I feel pretty confident that I could have less than an hour of downtime/missed footage. All 3 systems are up and running well, and the overhead of virtualization has had no noticeable impact on performance.

Also, Claude did nearly ALL of the heavy lifting here. After every OS installation my first steps were to enable RDP, then install OpenSSH Server, and then ask Claude for a PowerShell command to give it key-based SSH access, and then it did nearly everything. For boot failure it was giving me PowerShell/RE commands to type in, and for the NIC driver it was rebuilding INF files on my Flash drive for me to plug in, but I never had to consult any documentation. My JetKVM was also super useful here, and my boot failure could have been solved in half the time had I had it hooked up up for that job. And screw Microsoft for getting rid of F8!!!!!!

Specs:
  1. System 1: Core i7-12700 @ 2.1 GHz, 12 cores, 20 logical processors, 48 GB of RAM
    1. 32 GB and 20 virtual processors assigned to BI VM
    2. BI VM handles 30 cameras and reports 15,786 kB/s 405.8 MP/s
    3. I have four 8 TB HDDs and an 18 TB HDD in a 5-spindle/4 column parity Storage Space in a 6-bay USB external enclosure.
      1. I will probably replace the 18 TB disk with an 8 TB disk and move that 18 TB disk to System 2.
      2. The disks were running a bit hot in this enclosure until I reversed the direction of the fans, which dropped the average temperature by 3 - 5 °C and dropped the hottest drive by 7 °C, and they're all now peaking below 43 °C.
      3. I am 3D printing a baffle box for the empty bays to try and re-direct the airflow a bit better.
      4. This 6-bay enclosure replaces my old 4-bay enclosure, with 3 benefits:
        1. This new enclosure has a hard power switch, so it comes back on after a power failure. The old enclosure needed a button press, every single time.
        2. A 5-spindle array allows me to make a parity space with 4 columns, which solves Windows' brain-dead default that kills write performance.
        3. With 6 bays and a 5-spindle array, I can easily replace a drive by inserting, adding, retiring, and removing, with no downtime and no loss of redundancy.
  2. System 2: Core i7-6700 CPU @ 3.40GHz , 4 cores, 8 logical processors, 32 GB of RAM
    1. 16 GB and 8 virtual processors assigned to BI VM
    2. 6 GB and 2 virtual processors assigned to the Debian VM for ALPR, but I think that's overkill
    3. BI VM handles 21 cameras and reports 13,041 kB/s 174.9 MP/s
    4. Storage is a single 18 TB HDD with no redundancy. I will probably move that 18 TB disk over from System 1 and mirror in another USB enclosure.
  3. System 3: Core i7-6700 CPU @ 3.40GHz , 4 cores, 8 logical processors, 24 GB of RAM
    1. 16 GB and 6 virtual processors assigned to BI VM
    2. BI VM handles 13 cameras and reports 6,347 kB/s 174.6 MP/s
    3. Storage is a single 14 TB HDD with no redundancy.
 
Last edited:
TheWaterbug said:
I have recently migrated 3 installations of BI from bare metal to virtualized instances. It wasn't painless by any means, but with Claude's help I got it all done:
  1. Motivations: security and stability
    1. I wanted to isolate, as much as possible, the BI PC from the rest of my network, while still allowing me to administer the machine and use my existing backup system (Veeam), and while still permitting port-forwarding as the easiest way to enable remote access. If properly isolated, the odds of a compromised VM leaking into the rest of my network is very, very slim.
    2. I wanted to eliminate crapware, bloatware, Clippy, Copilot, unwanted Windows updates, and the stall-on-reboot where the latest update is asking if I want to set up Windows backup, again, after I've declined it 50x. The security implications of this are also pretty huge.
  2. All 3 previously ran BI 6 directly on Win11 Pro.
    1. All three had Docker containers installed directly in Win11, two to run Wyze-Docker containers for RTSP relay (no longer needed) and one to run ALPR-Database
  3. All 3 now run Server 2022 as HyperV hosts with Server 2022 VMs inside to run BI.
    1. The one remaining Docker container for ALPR-Database now runs in a lightweight Debian VM, for better isolation and resource control.
    2. Video storage is on a separate physical disk (or enclosure) from the OS, which I believe nearly all of us are already doing.
    3. I added a 2nd NIC to each box.
      1. The original NIC keeps the original boxes' IP address and serves Blue Iris traffic. The outside world, e.g. web clients, don't know that anything has changed.
      2. The second NIC is my management NIC, on a separate VLAN, where I manage the VM host and backup.
  4. Good things and gotchas I ran into:
    1. On migrations 2 and 3 I realized I could set up the VM first beforemigrating the host to Server 2022, since Win11 Pro (and Win10 Pro) include HyperV already, for free.
      1. I configured the HyperV virtual switch to assign IPs as described above, connected the new NIC to my management VLAN, and ensure that it was working, then disabled the BI NIC/IP from the management group.
      2. I installed Server 2022 inside the VM, did all available updates, installed BI, restored a backup of the BI config, and verified successful communication with all of my cameras, before proceeding. It had no access to the video storage drive (V:\ in my case), but I was able to verify everything else.
      3. I also set up the Debian VM and installed the latest ALPR-Database.
      4. Then I turned off the BI service on the host computer, made the V: drive a "pass-through disk" to the VM, and rebooted the VM. Blue Iris came right back up with very little downtime, and all my historical footage intact.
    2. Once the VM was up and running I was able to start installation of Server 2022 over my Win11 installation.
      1. If you don't reformat your installation drive, you will not destroy your VM! It'll be on the C: drive, right where you created it, and once Server 2022's HyperV is running, you can adopt/import it and have it running in a few seconds.
      2. Your BI instance in the VM will even run, and record video, during the first part of Server 2022 installation! You won't have any downtime until the first reboot.
    3. On some generations of PCs, like my Lenovo box, have a CPU that's incompatible with HyperV on early versions of Server 2022.
      1. This makes the box unbootable as soon as you enable HyperV, requiring a boot into the Windows Recovery Environment to type in commands to disable HyperV to recover the box.
      2. The fix is to install all available Server 2022 updates before enabling HyperV.
    4. Some NICs, like this cheapie TPLink card, don't have signed drivers for Server 2022.
      1. You can get them to install, but you have to create a custom .inf file and disable driver signing for one boot, after which it will load properly.
      2. It will run fine under Win10/Win11, and then fail on first reboot after Server 2022 installation.
    5. Once Server 2022 is installed and updated, adopt/import the BI VM and set it to start up automatically every time the host PC starts.
      1. Also set up the pass-through disk to auto-mount if it ever goes offline and then comes back online. Otherwise, if the VM starts up and it's not available, it will mark it as Offline, and it won't automatically restore the connection, even if you reboot.
    6. So, if you don't run into CPU/HyperV or NIC driver issues, you can do this whole process with less than an hour's worth of true downtime/missed footage.
      1. If you run into either of these, you'll spend a few hours debugging while the VM is down.
So all is well that ends well. If I ever have to do a 4th migration I feel pretty confident that I could have less than an hour of downtime/missed footage. All 3 systems are up and running well, and the overhead of virtualization has had no noticeable impact on performance.

Also, Claude did nearly ALL of the heavy lifting here. After every OS installation my first steps were to enable RDP, then install OpenSSH Server, and then ask Claude for a PowerShell command to give it key-based SSH access, and then it did nearly everything. For boot failure it was giving me PowerShell/RE commands to type in, and for the NIC driver it was rebuilding INF files on my Flash drive for me to plug in, but I never had to consult any documentation. My JetKVM was also super useful here, and my boot failure could have been solved in half the time had I had it hooked up up for that job. And screw Microsoft for getting rid of F8!!!!!!

Specs:
  1. System 1: Core i7-12700 @ 2.1 GHz, 12 cores, 20 logical processors, 48 GB of RAM
    1. 32 GB and 20 virtual processors assigned to BI VM
    2. BI VM handles 30 cameras and reports 15,786 kB/s 405.8 MP/s
    3. I have four 8 TB HDDs and an 18 TB HDD in a 5-spindle/4 column parity Storage Space in a 6-bay USB external enclosure.
      1. I will probably replace the 18 TB disk with an 8 TB disk and move that 18 TB disk to System 2.
      2. The disks were running a bit hot in this enclosure until I reversed the direction of the fans, which dropped the average temperature by 3 - 5 °C and dropped the hottest drive by 7 °C, and they're all now peaking below 43 °C.
      3. I am 3D printing a baffle box for the empty bays to try and re-direct the airflow a bit better.
      4. This 6-bay enclosure replaces my old 4-bay enclosure, with 3 benefits:
        1. This new enclosure has a hard power switch, so it comes back on after a power failure. The old enclosure needed a button press, every single time.
        2. A 5-spindle array allows me to make a parity space with 4 columns, which solves Windows' brain-dead default that kills write performance.
        3. With 6 bays and a 5-spindle array, I can easily replace a drive by inserting, adding, retiring, and removing, with no downtime and no loss of redundancy.
  2. System 2: Core i7-6700 CPU @ 3.40GHz , 4 cores, 8 logical processors, 32 GB of RAM
    1. 16 GB and 8 virtual processors assigned to BI VM
    2. 6 GB and 2 virtual processors assigned to the Debian VM for ALPR, but I think that's overkill
    3. BI VM handles 21 cameras and reports 13,041 kB/s 174.9 MP/s
    4. Storage is a single 18 TB HDD with no redundancy. I will probably move that 18 TB disk over from System 1 and mirror in another USB enclosure.
  3. System 3: Core i7-6700 CPU @ 3.40GHz , 4 cores, 8 logical processors, 24 GB of RAM
    1. 16 GB and 6 virtual processors assigned to BI VM
    2. BI VM handles 13 cameras and reports 6,347 kB/s 174.6 MP/s
    3. Storage is a single 14 TB HDD with no redundancy.
Click to expand...
Thanks for all the detail. Given I'm completely in the Windows ecosystem for servers, backup/restore, RDP, etc. and I don't really have any available hardware to switch to Linux. I only have Docker running for ALPR DB.

I guess I'll need to start asking AI how to set that up. Do I need a full Linux OS or is there something like a Linux CLI that would be sufficient? Is the community version from @prsmith777 running directly in Linux and not in Docker? I'm just trying to get a mental model of this.
 
VideoDad said:
Thanks for all the detail. Given I'm completely in the Windows ecosystem for servers, backup/restore, RDP, etc. and I don't really have any available hardware to switch to Linux. I only have Docker running for ALPR DB.

I guess I'll need to start asking AI how to set that up. Do I need a full Linux OS or is there something like a Linux CLI that would be sufficient? Is the community version from @prsmith777 running directly in Linux and not in Docker? I'm just trying to get a mental model of this.
Click to expand...
Im getting close to a Windows version... hang on
 
TheWaterbug said:
I have recently migrated 3 installations of BI from bare metal to virtualized instances. It wasn't painless by any means, but with Claude's help I got it all done:
  1. Motivations: security and stability
    1. I wanted to isolate, as much as possible, the BI PC from the rest of my network, while still allowing me to administer the machine and use my existing backup system (Veeam), and while still permitting port-forwarding as the easiest way to enable remote access. If properly isolated, the odds of a compromised VM leaking into the rest of my network is very, very slim.
    2. I wanted to eliminate crapware, bloatware, Clippy, Copilot, unwanted Windows updates, and the stall-on-reboot where the latest update is asking if I want to set up Windows backup, again, after I've declined it 50x. The security implications of this are also pretty huge.
  2. All 3 previously ran BI 6 directly on Win11 Pro.
    1. All three had Docker containers installed directly in Win11, two to run Wyze-Docker containers for RTSP relay (no longer needed) and one to run ALPR-Database
  3. All 3 now run Server 2022 as HyperV hosts with Server 2022 VMs inside to run BI.
    1. The one remaining Docker container for ALPR-Database now runs in a lightweight Debian VM, for better isolation and resource control.
    2. Video storage is on a separate physical disk (or enclosure) from the OS, which I believe nearly all of us are already doing.
    3. I added a 2nd NIC to each box.
      1. The original NIC keeps the original boxes' IP address and serves Blue Iris traffic. The outside world, e.g. web clients, don't know that anything has changed.
      2. The second NIC is my management NIC, on a separate VLAN, where I manage the VM host and backup.
  4. Good things and gotchas I ran into:
    1. On migrations 2 and 3 I realized I could set up the VM first beforemigrating the host to Server 2022, since Win11 Pro (and Win10 Pro) include HyperV already, for free.
      1. I configured the HyperV virtual switch to assign IPs as described above, connected the new NIC to my management VLAN, and ensure that it was working, then disabled the BI NIC/IP from the management group.
      2. I installed Server 2022 inside the VM, did all available updates, installed BI, restored a backup of the BI config, and verified successful communication with all of my cameras, before proceeding. It had no access to the video storage drive (V:\ in my case), but I was able to verify everything else.
      3. I also set up the Debian VM and installed the latest ALPR-Database.
      4. Then I turned off the BI service on the host computer, made the V: drive a "pass-through disk" to the VM, and rebooted the VM. Blue Iris came right back up with very little downtime, and all my historical footage intact.
    2. Once the VM was up and running I was able to start installation of Server 2022 over my Win11 installation.
      1. If you don't reformat your installation drive, you will not destroy your VM! It'll be on the C: drive, right where you created it, and once Server 2022's HyperV is running, you can adopt/import it and have it running in a few seconds.
      2. Your BI instance in the VM will even run, and record video, during the first part of Server 2022 installation! You won't have any downtime until the first reboot.
    3. On some generations of PCs, like my Lenovo box, have a CPU that's incompatible with HyperV on early versions of Server 2022.
      1. This makes the box unbootable as soon as you enable HyperV, requiring a boot into the Windows Recovery Environment to type in commands to disable HyperV to recover the box.
      2. The fix is to install all available Server 2022 updates before enabling HyperV.
    4. Some NICs, like this cheapie TPLink card, don't have signed drivers for Server 2022.
      1. You can get them to install, but you have to create a custom .inf file and disable driver signing for one boot, after which it will load properly.
      2. It will run fine under Win10/Win11, and then fail on first reboot after Server 2022 installation.
    5. Once Server 2022 is installed and updated, adopt/import the BI VM and set it to start up automatically every time the host PC starts.
      1. Also set up the pass-through disk to auto-mount if it ever goes offline and then comes back online. Otherwise, if the VM starts up and it's not available, it will mark it as Offline, and it won't automatically restore the connection, even if you reboot.
    6. So, if you don't run into CPU/HyperV or NIC driver issues, you can do this whole process with less than an hour's worth of true downtime/missed footage.
      1. If you run into either of these, you'll spend a few hours debugging while the VM is down.
So all is well that ends well. If I ever have to do a 4th migration I feel pretty confident that I could have less than an hour of downtime/missed footage. All 3 systems are up and running well, and the overhead of virtualization has had no noticeable impact on performance.

Also, Claude did nearly ALL of the heavy lifting here. After every OS installation my first steps were to enable RDP, then install OpenSSH Server, and then ask Claude for a PowerShell command to give it key-based SSH access, and then it did nearly everything. For boot failure it was giving me PowerShell/RE commands to type in, and for the NIC driver it was rebuilding INF files on my Flash drive for me to plug in, but I never had to consult any documentation. My JetKVM was also super useful here, and my boot failure could have been solved in half the time had I had it hooked up up for that job. And screw Microsoft for getting rid of F8!!!!!!

Specs:
  1. System 1: Core i7-12700 @ 2.1 GHz, 12 cores, 20 logical processors, 48 GB of RAM
    1. 32 GB and 20 virtual processors assigned to BI VM
    2. BI VM handles 30 cameras and reports 15,786 kB/s 405.8 MP/s
    3. I have four 8 TB HDDs and an 18 TB HDD in a 5-spindle/4 column parity Storage Space in a 6-bay USB external enclosure.
      1. I will probably replace the 18 TB disk with an 8 TB disk and move that 18 TB disk to System 2.
      2. The disks were running a bit hot in this enclosure until I reversed the direction of the fans, which dropped the average temperature by 3 - 5 °C and dropped the hottest drive by 7 °C, and they're all now peaking below 43 °C.
      3. I am 3D printing a baffle box for the empty bays to try and re-direct the airflow a bit better.
      4. This 6-bay enclosure replaces my old 4-bay enclosure, with 3 benefits:
        1. This new enclosure has a hard power switch, so it comes back on after a power failure. The old enclosure needed a button press, every single time.
        2. A 5-spindle array allows me to make a parity space with 4 columns, which solves Windows' brain-dead default that kills write performance.
        3. With 6 bays and a 5-spindle array, I can easily replace a drive by inserting, adding, retiring, and removing, with no downtime and no loss of redundancy.
  2. System 2: Core i7-6700 CPU @ 3.40GHz , 4 cores, 8 logical processors, 32 GB of RAM
    1. 16 GB and 8 virtual processors assigned to BI VM
    2. 6 GB and 2 virtual processors assigned to the Debian VM for ALPR, but I think that's overkill
    3. BI VM handles 21 cameras and reports 13,041 kB/s 174.9 MP/s
    4. Storage is a single 18 TB HDD with no redundancy. I will probably move that 18 TB disk over from System 1 and mirror in another USB enclosure.
  3. System 3: Core i7-6700 CPU @ 3.40GHz , 4 cores, 8 logical processors, 24 GB of RAM
    1. 16 GB and 6 virtual processors assigned to BI VM
    2. BI VM handles 13 cameras and reports 6,347 kB/s 174.6 MP/s
    3. Storage is a single 14 TB HDD with no redundancy.
Click to expand...
Did you try my ALPR Community? Havent heard any feedback on it. It is a huge improvement from original, IMO.
 
prsmith777 said:
Did you try my ALPR Community? Havent heard any feedback on it. It is a huge improvement from original, IMO.
Click to expand...
I did install from your fork, or at least I had Claude do it. I had Claude make some changes so that I could add it as a 4th tab on ui3.htm:

1791236999520.png


It requires a separate login, and I haven't figure out how to link back to the BI clip like It used to do, but in general I like it!

It would be nice to unify the login with ui3, but I don't think Ken would want to take on the work required to make that happen.

Right now my ALPR-D is running in a separate VM, so it's got a different [internal] IP address, so credential sharing/checking gets even harder.

Right now 3 out of my 4 LPR cameras are un-mounted for reasons not related to this discussion, so I haven't actually played with the new system very much yet. That will come, soon!
 
TheWaterbug said:
I did install from your fork, or at least I had Claude do it. I had Claude make some changes so that I could add it as a 4th tab on ui3.htm:
Click to expand...
Summary, from Claude:
ALPR as the 4th UI3 tab — what we changed

Four pieces, in three places:

1. ALPR app — one line, on ALPRBroadway (/home/administrator/alpr-target/) In next.config.js, replaced X-Frame-Options: DENY with Content-Security-Policy: frame-ancestors 'self' . That's the entire app-side change. It lives on a local branch local/embed-in-bi off the pinned tag (the repo is a detached-HEAD fork at v0.1.41), so version bumps don't silently carry or lose it. Rebuild with docker build -t alpr-dashboard:local . then docker compose up -d app — there's no build: stanza in compose.

2. Separate subdomain instead of a path prefix alpr.Weylan-Yutani.com gets its own nginx server_name block → proxy_pass . We deliberately avoided /alpr/* under the blueiris hostname because the app has 33+ hardcoded absolute paths (/api/..., /storage/..., /models/...) plus raw WebSocket/EventSource usage in PlateTableWrapper.jsx and LiveRecognitionViewer.jsx, none of which Next's basePath rewrites. Same outcome, far smaller patch surface. Both hostnames share one public IP via SNI routing, and one win-acme cert with both as SANs.

3. The tab itself — ui3-local-overrides.js on BlueIrisBroadwayVM The key constraint: ui3.js binds its .topbar_tab click handler once at load time, before the overrides file runs, so a tab appended there is invisible to it. So the ALPR tab carries its own independent handler that shows a fixed-position #alpr_pane holding a lazily-sourced <iframe> and hides #layoutleft/#layoutbody/#layoutbottom. BI's three native tabs get a second click handler added (jQuery permits multiple) purely to close our pane on the way back. The iframe src is set on first click, not page load, so BI pages don't hit the ALPR VM every time.

4. The audio bug Hiding those three layout divs doesn't stop UI3's camera audio; it kept playing over the ALPR tab. The fix: showAlprPane()saves settings.ui3_audioMute into mutedStateBeforeAlpr, forces it to "1", and calls pcmPlayer.SetAudioVolumeFromSettings(). hideAlprPane() restores the saved value and calls that setter again. It save/restores rather than just unmuting on exit — otherwise it would clobber someone who already had audio muted. Both pcmPlayer calls are guarded in case it doesn't exist yet.
Click to expand...
 
TheWaterbug said:
I did install from your fork, or at least I had Claude do it. I had Claude make some changes so that I could add it as a 4th tab on ui3.htm:

View attachment 250001

It requires a separate login, and I haven't figure out how to link back to the BI clip like It used to do, but in general I like it!

It would be nice to unify the login with ui3, but I don't think Ken would want to take on the work required to make that happen.

Right now my ALPR-D is running in a separate VM, so it's got a different [internal] IP address, so credential sharing/checking gets even harder.

Right now 3 out of my 4 LPR cameras are un-mounted for reasons not related to this discussion, so I haven't actually played with the new system very much yet. That will come, soon!
Click to expand...
Within ALPR, you can add your BI password in the .env file. It then will access BI natively in the app

BLUEIRIS_HOST=http://YOUR_BI_SERVER:PORT
BLUEIRIS_USERNAME=your_bi_username
BLUEIRIS_PASSWORD='your_bi_password'
 
  • Like
Reactions: TheWaterbug
prsmith777 said:
Within ALPR, you can add your BI password in the .env file. It then will access BI natively in the app

BLUEIRIS_HOST=http://YOUR_BI_SERVER:PORT
BLUEIRIS_USERNAME=your_bi_username
BLUEIRIS_PASSWORD='your_bi_password'
Click to expand...
It would be nice to have multiple user access. Ideally it would be tied to the same user database that lives within BI, but I'm not sure how that could be done without Ken's support.

Maybe if BI is already signed in from that browser, ALPR-D could detect if that user has read access to the LPR cameras?
 
You must log in or register to reply here.
Top Bottom