Frigate on Docker, in Windows Subsystem for Linux (WSL)

[MinimumDowntime]

I wanted to write something up to share with the HA community as it's mentioned only briefly in the Installation of Frigate. Specifically:

Windows is not officially supported, but some users have had success getting it to run under WSL or Virtualbox. Getting the GPU and/or Coral devices properly passed to Frigate may be difficult or impossible. Search previous discussions or issues for help.

I couldn't find much in the way of this, but I'll openly admit I could have just been searching in the wrong places. In any case, if you're like me with a computer running Windows, you may think to yourself "I can run Docker on Windows. Docker can interface with WSL. I should be able to pull off running Frigate." and I'm here to tell you that yes you can, and it's easier than you might think.

I've also been able to get Frigate running with Nvidia GPU Tensor, as well as the Google Coral USB. Granted, the Coral as of this current edit produces some errors in Frigate logs. It never the less works!

Anyway, let's get Frigate running in Windows.

Deploy and Configure WSL

There are two ways to get WSL going in Windows. If you want the fast path to WSL, open up Windows PowerShell (not x86, not ISE, just regular old blue icon Windows PowerShell) as an Admin and execute

wsl --install -d Ubuntu

This command will make WSL available and deploy Ubuntu. Want to see more about this approach? Check out the Microsoft Docs article on it. Want to go the slightly longer way? Read steps 1-3 to get started with WSL.

1. Windows Subsystem for Linux must be enabled in Windows. Just open the Start menu and type "Turn Windows Features on or off". As you type, it will probably come up without you having to finish. Open it up, scroll down, and make sure the two following items are checked:
   • Windows Subsystem for Linux
   • Virtual Machine Platform

This might requite a reboot once installed. I forget.

2. Open up the Microsoft Store. You can do this by going to start and typing "store". Then, search for a Linux distro. You can use Ubuntu, OpenSuse, Kali, and Debian. In my environment, I am using and have only tested it with Ubuntu.

3. Setup WSL by going to start, type 'wsl' and you should see 'run command' with the tux/penguin icon. Click to open it up and then set a username/password and perform any other initial config as necessary.

At this point, WSL/Linux are running on Windows. Neat! Onto Docker.

Deploy and Configure Docker on Windows (v4.13.1 at the time of this writing)

4. Install Docker Desktop from here. Once Docker is running, open it up and click the small Gear icon in the top right by the sign in button. This will take you to Docker Settings. In the General tab (where you'll land by default) you'll see "Use the WSL 2 based engine". Also on the general tab at the bottom, make sure 'use docker compose v2' is checked off.

5. Next, head into Resources above the General tab. Then select "WSL Integration". Make sure that "enable integration with my default WSL distro' is checked and that the distro you installed from above is listed, and enabled.

At this point, we have WSL running and we have Docker integrated with it. Finally, it's time to pull down Frigate and configure it.

Deploy and Configure Frigate

Confirmed working with versions:

• v0.12.0
• v0.12.1
• v0.13.0
• v0.13.1
• v0.13.2

6. Per Frigate installation on Docker, Compose is the preferred installation method. The good news is that the initial compose as laid out can be used with very slight tweaks. Specifically:
   • you might not have devices you are passing into the container. In which case, this section can be removed/commented out entirely.
   • we need to alter the Volumes section. Given the first three lines, we'll need to alter to allow the Frigate Docker Container, access to the WSL instance.

BEFORE

• /etc/localtime:/etc/localtime:ro
• /path/to/your/config.yml:/config/config.yml
• /path/to/your/storage:/media/frigate

AFTER

• \\wsl$$\Ubuntu\etc\localtime:/etc/localtime:ro
• \\wsl$$\Ubuntu\home\USERNAME\frigate\config.yml:/config/config.yml
• \\wsl$$\Ubuntu\home\USERNAME\frigate\clips:/media/frigate

Again, this is telling the Frigate container in Docker, how to access resources that exist in the WSL instance. In fact, you might recognize part of this as a UNC Network Path because it is! Curious? Open up File Explorer in Windows, and type in "\\wsl$". Doing so allows you to navigate into the WSL distro. just use "\\wsl$" with a single $ instead of $$ as listed above in the docker compose. As far as the rest of the Compose is concerned, configure everything else such as the password, ports, etc. as you see fit. The USERNAME will be the account you configured when you setup WSL with a password a few steps back. You can also verify the path by using the UNC Path to navigate into the directory and verify the name.

8. We need to now define a Frigate configuration file (config.yml). Let's head into the WSL path as defined above by opening windows File Explorer and navigating into \\wsl$\Ubuntu\home\USERNAME\frigate. If you don't have a Frigate folder, now is a great time to create it. Then, head into that directory and create a new file called config.yml. At this point, you should be able to define a config.yml file that contains your MQTT server, cameras, etc. and everything that you see in the setup instructions, YouTube videos, and elsewhere.

9. Now let's spin up the container using our Docker Compose file. Open up a PowerShell window (connected to your Windows host, not your WSL instance) if you don't already have one open (see the paragraph above step 1 on choosing the "right" PowerShell to open if you have question). Navigate to the directory where you compose file is located. You can do this by typing "cd c:\folder\path" where c:\folder\path is the directory the file is stored. Now type/paste in "docker-compose up -d". You should see a result returned such as "Running". Interested in what this command and other relevant Docker arguments mean? Check out https://docs.docker.com/engine/reference/commandline/compose_up/

10. Head back into Docker within Windows, and go to Containers. You should see the name of your folder the Docker Compose was located in and a sub item of "frigate" now running. At this point, Frigate is now running in Docker and all troubleshooting/subsequent configuration should follow any other threads you find online.

Hardware Acceleration

The other thing that might cross your mind with a Windows computer is taking advantage of a dedicated GPU to use within WSL. Fortunately, there are only a couple things that are required

• Your WSL instance must be V2, you can check this at a command prompt in Windows by typing and executing:

wsl -l -v

and verifying you see "2" next to the distro you configured above.

• You must be running at least Windows 21H2
  • This version of Windows was released on 10/4/2021 so chances are if you've updated since then you're probably okay. But if you want to double check, open the start menu, type "winver" and open up to see which version you have.
  • If you want to read more about Windows update release history, check out the Microsoft doc here
  • You have the latest drivers for your GPU installed. In my case, I'm using a Nvidia GTX1080

Once you've met these requirements, open up your WSL command prompt by going to Start, typing "WSL" and opening up the command prompt. There, type "nvidia-smi". You should return a result that looks something like this:

In the above screenshot, I've highlighted and circled the ID for the GPU in the event you have multiple GPUs and want to pick and choose what gets passed into WSL.

Then in your Docker Compose file, you'll want to add the following section. You'll notice I commented out #device_ids, and instead opted for count: all. Count takes either an integer or the string of "all".

    deploy:    # <------------- Add this section
      resources:
        reservations:
          devices:
            - driver: nvidia
              #device_ids: ['0'] # this is only needed when using multiple GPUs
              count: all # number of GPUs
              capabilities: [gpu]

As an example, here's the Docker Compose file with that section added.

Finally, in your config.yml we'll need to add arguments for hardware acceleration. Per Frigate Documentation on Nvidia GPUs I'm just going to use h264. To see a list of supported codecs, in Docker, navigate into the Terminal for the Frigate container. Then use

ffmpeg -decoders | grep cuvid

to see a list of supported codecs. In my case, I have an Nvidia GPU so per documentation I can simply use "preset-nvidia-h264"

Again, we'll use "docker-compose up -d" at the Windows PowerShell command line in the directory the compose file is located to rebuild the container using the new compose that makes use of the GPU. Then in WSL, we'll type "nvidia-smi" once again, only this time we should see the ffmpeg process attached for each camera we have HW Accel arguments defined in our config.yml.

Limiting WSL Host Resources

If you've done the above, something you may notice after a couple days of use is that your Windows host, has near maxed out it's memory usage! This is because WSL will continue to consume resources as it needs them. So you will more than likely want to set a ceiling on what WSL is capable of consuming. Solving this is incredibly simple.

1. Navigate to C:\Users\YOURUSERNAMEHERE
2. Create a file called ".wslconfig"
3. Modify/Paste the following based on your respective requirements

[wsl2]
memory=16GB #WSL only consume up to 16gb of memory
processors=4 #WSL will only make use of 4 processors

In the above config, only the CPU/Memory for WSL is capped and everything after the # is a note per line. Want to know what else you can configure? Check out the following Microsoft Doc on Advanced Settings Configuration in WSL

At this point, either restart your Windows host or just restart WSL with PowerShell (as an Admin) for changes to take effect:

Restart-Service LxssManager

Using a Google Coral USB Detector

It should be noted, while the following works, I am as of this writing currently producing sporadic errors in Frigate that result in either the detection service restarting or the container restarting. However these events seemingly have not adversely affected recording, performance, or anything that jeopardizes Frigate's ability to function. From what I've seen, no more than 5 seconds of downtime occurs as a result of this. Secondly, it appears the Coral will not auto-attach as described in Step 7 below. After a reboot of the Windows host the command must be executed to re-establish connectivity. I suspect this can be automated and am working on doing so. I'll update this section if I can get that working.

With WSL2, it's possible to attach USB devices to your Windows host and pass them through to the WSL instance using the open source project known as usbipd-win that Microsoft is advertising as the recommended path forward. With a single USB Coral, my inferencing times average about 15-17ms vs. the 75-80ms I had with two CPUs.

But when it comes to setting this up. Things seem to be ever so slightly different based on whether you are running Windows 10 vs. Windows 11 per the Microsoft documentation.

• Windows 10: Seems like it requires some setup
• Windows 11: Seems like it just works out of the box

The good news is that the Windows 10 setup is in fact pretty minimal

1. Intall the usbipd-win msi to your Windows host (v3.2.0 at the time of this writing)
2. Once installed, open a terminal on Windows. Issue the following command which should return any attached USB devices on your Windows host:

usbipd wsl list

At this point, the Windows side of things are done. Now we need to configure WSL instance so it can receive/listen to when we mount the USB Coral. But it's worth calling out some conflicting documentation here and which one to choose.

• The Microsoft documentation listed above in the Install the USBIP tools and hardware database in Linux tells you to issue:

sudo apt install linux-tools-generic hwdata
sudo update-alternatives --install /usr/local/bin/usbip usbip /usr/lib/linux-tools/*-generic/usbip 20

• The usbipd-win WSL Support documentation tells you to issue:

sudo apt install linux-tools-virtual hwdata
sudo update-alternatives --install /usr/local/bin/usbip usbip `ls /usr/lib/linux-tools/*/usbip | tail -n1` 20

Specifically, the very first line in those respective commands is the only problem I ran into. Note the very small difference of "generic" vs. "virtual" in those commands. When I followed the Microsoft documentation, the command starts returning output before eventually throwing an error that the listed dependencies/packages can't be found. But following the usbipd-win WSL Support documentation, everything works as expected. So I'm going to advise that you use the usbipd-win documentation's respective commands. To do that:

3. Open a terminal to your WSL instance. Verify the kernel version returned is 5.10.60.1 or greater:

uname -a

4. In the same terminal connected to your WSL instance, install USB/IP client tools

sudo apt install linux-tools-virtual hwdata
sudo update-alternatives --install /usr/local/bin/usbip usbip `ls /usr/lib/linux-tools/*/usbip | tail -n1` 20

5. Back in your Windows terminal (step 2, above) find the Bus ID of the attached Coral device. If you aren't sure which is the Coral device. Unplug it, run the command, plug the Coral in, run it again and spot the difference.

6. (OPTIONAL) If you received a warning somewhere along the way in a Windows terminal about needing to use bind and force commands. Make sure you run those first and no less from an administrative terminal in Windows. Run the following where IDENTIFIERHERE is the Bus ID of the Coral. For example, usbipd wsl attach --busid 4-3

usbipd wsl bind --force --busid IDENTIFIERHERE

7. From an administrative terminal in Windows, run ONE of the two following commands. For example, usbipd wsl attach --busid 4-3 --auto-attach.

usbipd wsl attach --busid IDENTIFIERHERE --auto-attach
usbipd wsl attach --hardware-id VID:PID --auto-attach

8. Verify the Coral USB is mounted with the following commands in Windows and WSL. You should see a device that cites the Google Coral USB Accelerator in the name/description of the result. If you don't see this, unattach the device, and reattach. It's crucial this device shows correctly mounted, otherwise docker will never serve it correctly to the Frigate container.

From Windows

usbipd wsl list

From WSL

lsusb

At this point, modify your Frigate configuration to use the Google Coral detector(s) per Frigate documentation of Edge-TPU Detector. Restart Frigate with the new config, head over to Logs/System to verify Frigate has picked up your Coral and you're done!

Using Nvidia GPUs and TensorRT Detectors

With the advent of Frigate 0.12, not only can you use your Nvidia GPU for Hardware Acceleration as outlined above. But also as your detectors. When I began using Frigate, I allocated two CPUs to it. They each averaged about 75-80ms inferencing time. With an Nvidia GTX1080, inferencing time now averages 5-7ms. Before we get started, if Frigate is currently running in Docker/WSL you'll want to stop the container before starting model training, much less building the needed TensorRT specific container for Frigate. Secondly, if this is your only GPU and you enjoy gaming. You might experience decreased frame rates and less than optimal gaming performance while the Frigate container is utilizing GPU inferencing.

1. Open up a shell to your WSL instance. I personally use Windows Terminal to make bouncing between my Windows host and Ubuntu/WSL instance easier to keep track of. Then follow the documentation for generating models by running the following commands at the WSL command line.

mkdir trt-models
wget https://github.com/blakeblackshear/frigate/raw/master/docker/tensorrt_models.sh
chmod +x tensorrt_models.sh

At this point, if you use File Explorer you can go into WSL and verify the folder was created and tensorrt_models.sh are both in your \\wsl$\Ubuntu\home\YOURUSERNAMEHERE directory.

Let's head back to your WSL command line. Then we'll run the final command to begin training

docker run --gpus=all --rm -it -v `pwd`/trt-models:/tensorrt_models -v `pwd`/tensorrt_models.sh:/tensorrt_models.sh nvcr.io/nvidia/tensorrt:22.07-py3 /tensorrt_models.sh

If your card doesn't support FP16 operations you might see some warnings get generated from running the above. In which case, you can just delete the files and start over. You can do that with:

sudo rm -rf trt-models/

Let's try it one more time, with a single additional argument per the documentation of "-e USE_FP16=False"

docker run --gpus=all --rm -it -v `pwd`/trt-models:/tensorrt_models -v `pwd`/tensorrt_models.sh:/tensorrt_models.sh nvcr.io/nvidia/tensorrt:22.07-py3 /tensorrt_models.sh -e USE_FP16=False

Once you return to a blinking command line, your models are trained and your GPU is ready to go. We just need to do some slight alteration of the Docker Compose from above.

First, we need to use a Tensor RT specific instance of Frigate
BEFORE

image: ghcr.io/blakeblackshear/frigate:stable

AFTER

image: ghcr.io/blakeblackshear/frigate:stable-tensorrt

Second, we need to introduce a new line item to our Volumes section:
BEFORE

- \\wsl$$\Ubuntu\etc\localtime:/etc/localtime:ro
- \\wsl$$\Ubuntu\home\USERNAME\frigate\config.yml:/config/config.yml
- \\wsl$$\Ubuntu\home\USERNAME\frigate\clips:/media/frigate

AFTER

- \\wsl$$\Ubuntu\etc\localtime:/etc/localtime:ro
- \\wsl$$\Ubuntu\home\USERNAME\frigate\config.yml:/config/config.yml
- \\wsl$$\Ubuntu\home\USERNAME\frigate\clips:/media/frigate
- \\wsl$$\Ubuntu\home\USERNAME\trt-models:/trt-models:ro

Then we'll use "docker-compose up -d" at the Windows PowerShell command line in the directory the compose file is located to rebuild the container using the new compose that makes use of the GPU and TensorRT instance of Frigate. Once Frigate starts, you'll want to update your config.yml/detectors section per the documentation. Once you've done this, save your config, and then restart Frigate to finalize your flip towards TensorRT based inferencing.

You can verify things are running smoothly by heading into Logs and ensuring you don't see errors. Finally, check out System to see

Just wanted to throw this out there and hope someone finds it helpful.

[NickM-27]

Thanks for the post! Have you been able to get your GPU passed in for hardware acceleration? That's another important part 👍

[MinimumDowntime]

Updated to include how to create a WSL Config file to cap resources for the WSL instance.

[MinimumDowntime]

Updated to reflect Frigate 0.12 and alternative ways of passing the DEPLOY section for Nvidia GPUs

[MinimumDowntime]

Updated to include Nvidia TensorRT inferencing within WSL

[MinimumDowntime]

Updated to include using USB Coral Accelerator within WSL

Unfortunately, it looks like despite this initially running successfully. Errors are thrown in Frigate that line up with the random disconnects that happens between Windows and WSL as cited in Frigate/USBIP communities.

[MinimumDowntime]

Been running with a USB Coral the last several days with only the occasional container crash/restart. It looks as though nine days after I updated my previous comment directly above, I completely missed that usbipd-win released 3.2.0 which seems to have got the Google Coral USB looks to be fairly stable within WSL. The following both happen sporadically in Frigate:

• Occasionally Frigate restarts the detection service. Total downtime is about 4-5 seconds. Apart from a smooth startup and finding the TPU, logs go as follows:
  • HandleQueuedBulkIn transfer in failed. Invalid argument: USB transfer error 4 [LibUsbDataInCallback]
  • Fatal Python error: Aborted
  • Two Thread errors (paraphrasing this)
  • Detection appears to be stuck. Restarting detection process...
• The container crashed once or twice, and self-restarts

So again, this seems to be functional and Frigate seems to be running with ...uhh. I can't believe this fits... minimum downtime.

It's worth calling out that this experience is SLIGHTLY different than the original scenario wherein the [LibUsbDataInCallback] occurred, and then Windows would detach the Coral USB from WSL. Now at least Windows keeps the Coral mounted throughout both of the above bullet points within Frigate. Documentation above has been updated to reflect all of this.

[WhiteNoseThunderPants]

This is awesome, has anyone done this with an intel gpu and a google coral yet?

[enzo2]

What would be the equivalent command like nvidia-smi for integrated Intel GPUs, and for AMD/Radeon? (I have both)

[NickM-27]

intel_gpu_top and radeontop

[Aryankids]

I am running WSL2 for a couple of years for my Home Assistant. As we all know Frigate integrates very well with HA. But all my attempts to pass through a USB from the host (windows) failed.
You might like to know, I could manage to make a USB available to WSL2 using USBIP_WSL but when I tried to use Coral on top of it that miserably fails. I raised a couple of bugs on both sides i.e. Google Coral and USBIP but it seems there is no intention for any of these teams to get the issue sorted. HTH.

[MinimumDowntime]

Just wanted to provide an update to this thread that I have a Google Coral USB Accelerator successfully working in WSL and being utilized by Frigate.

Correction. After a few hours it looks like I'm in the same camp with everyone else. Errors thrown now line up with comments experienced in the Frigate and USBIP GitHub communities

[MinimumDowntime]

Wanted to update this thread that since usbipd-win 3.2.0 was released, passing a USB Coral into WSL is more stable. Frigate has some sporadic issues, but it is functional. Documentation has been updated above to reflect this.

[Mehrez13]

hello, I have some issue in my docker-compose file but can find where is the probleme. Can you help me?

version: "3.9"
services:
frigate:
container_name: frigate
#privileged: true # this may not be necessary for all setups
restart: unless-stopped
image: ghcr.io/blakeblackshear/frigate:stable
shm_size: "64mb" # update for your cameras based on calculation above
volumes:
- \wsl$$\Ubuntu-18.04\etc\localtime:/etc/localtime:ro
- \wsl$$\Ubuntu-18.04\home\hicham\frigate\config.yml:/config/config.yml:ro
- \wsl$$\Ubuntu-18.04\home\hicham\frigate:/media/frigate
- type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear
target: /tmp/cache
tmpfs:
size: 1000000000
ports:
- "5000:5000"
- "8554:8554" # RTSP feeds
- "8555:8555/tcp" # WebRTC over tcp
- "8555:8555/udp" # WebRTC over udp
environment:
FRIGATE_RTSP_PASSWORD: "PASSWORD"

[NickM-27]

You need to provide logs or something otherwise there's no way to help

[backcountrymountains]

There is also the possibility of creating a Hyper-V Debian VM and using DDA to pass through an entire PCIe coral device. I don't think the VM is using /dev/dri/card0 (the virtual graphics interface provided by Hyper-V) for decode but my hypervisor CPU usage is 2% at idle. My inference time is ~7ms. I'm only running one stream at 2304x1296. It's a Lenovo desktop with an i7-12700 and 64 GB ram.

Result of DDA survey (powershell survey-dda.ps1):

Coral PCIe Accelerator
Express Endpoint -- more secure.
    And its interrupts are message-based, assignment can work.
PCIROOT(0)#PCI(1C04)#PCI(0000)

My devices in docker compose:

devices:
      - /dev/apex_0:/dev/apex_0 
      - /dev/dri/card0

This is the table in the frigate/system tab:

Process	P-ID	FPS	CPU %	Memory %
ffmpeg	11423	5.2	18.9%	1.3%
Capture	529	5.2	2.0%	0.7%
Detect	514	0 (0 skipped)	0.3%	0.9%

The VM is set up to use 10 processors. The CPU of ffmpeg here results in only 2% CPU usage on the Hypervisor.

VAINFO in the frigate/system tab returns:

error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/hyperv_drm_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

[MinimumDowntime]

Well that's awesome to see someone has made progress on the DDA (Discrete Device Assignment) front 😄

[backcountrymountains]

What's unfortunate is that GPU-PV doesn't play nice with DDA in Hyper-V VMs (ffmpeg -hwaccel cuda segfaults) so I can't get hardware encode/decode unless I DDA a discrete video device. WSL works amazingly well with GPU-PV (jellyfin!) but has no DDA functionality to pass through a Coral. I can get the tensorrt detection working in WSL but it makes my GPU work a bit more than I'd like and I'm trying to do other stuff with it (Baldur's Gate 3!).

I'm hoping that WSL getting VAAPI might allow me to use the Intel iGPU in a Hyper-V VM so I can use hardware acceleration encode/decode.

I just want one computer that can do all of the things! Someday.

[MinimumDowntime]

Baldur's Gate 3!

hah. I don't play, but I absolutely get the reference/hardware requirements point you're making. Also, good idea. I've updated the TensorRT section above to highlight you might experience some gaming performance woes whilst utilizing GPU inferencing.

I'm hoping that WSL getting VAAPI might allow me to use the Intel iGPU in a Hyper-V VM so I can use hardware acceleration encode/decode.

Oh! Now THAT is a great idea! Glad to see someone else out there playing in this very specific Windows oriented space. If you make any progress it sounds deserving of its own Show n Tell thread 😃

[justinhsa]

Hello, when running "docker-compose up -d" in WSL Ubuntu, I got the following:

[+] Building 0.0s (0/0) docker:default [+] Running 0/0 ⠋ Container frigate Creating 0.0s Error response from daemon: create \\wsl$\Ubuntu\etc\localtime: "\\\\wsl$\\Ubuntu\\etc\\localtime" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path

How do I modify the volume paths in my docker-compose.yml to avoid this error? Any help would be appreciated. Host OS is Win11 22H2, and the Docker Desktop version is v4.24.0. My docker-compose.yml:

version: "3.9"
services:
frigate:
container_name: frigate
privileged: true # this may not be necessary for all setups
restart: unless-stopped
image: ghcr.io/blakeblackshear/frigate:0.13.0-beta2
shm_size: "64mb" # update for your cameras based on calculation above
devices:
volumes:
- \\wsl$$\Ubuntu\etc\localtime:/etc/localtime:ro
- \\wsl$$\Ubuntu\home\justinhsa\frigate\config.yml:/config/config.yml
- \\wsl$$\Ubuntu\home\justinhsa\frigate\clips:/media/frigate
- type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear
target: /tmp/cache
tmpfs:
size: 1000000000
ports:
- "5000:5000"
- "8554:8554" # RTSP feeds
- "8555:8555/tcp" # WebRTC over tcp
- "8555:8555/udp" # WebRTC over udp
environment:
FRIGATE_RTSP_PASSWORD: "abcdefgh"

[justinhsa]

Never mind. Figured out I have to run "docker-compose up -d" in Windows Powershell, not in Ubuntu shell.

[MinimumDowntime]

Glad to hear you got this sorted. I've gone ahead and updated the post above to call this out for others who may venture down this path. Thanks for your help!

[smith3d]

Hi there,

I'm getting error not a valid Windows Path

PS D:\docker\frigate> docker-compose up -d
[+] Building 0.0s (0/0) docker:default
[+] Running 0/0

• Container frigate-devcontainer Creating 0.0s
  Error response from daemon: \wsl$\Ubuntu\home\USERNAME\frigate\config.yml%!(EXTRA string=is not a valid Windows path)
  PS D:\docker\frigate>

seems like i can't use

volumes:
  - \\wsl$$\Ubuntu\home\USERNAME\frigate\config.yml:/config/config.yml
  - \\wsl$$\Ubuntu\home\USERNAME\frigate\clips:/media/frigat
  
 I have been using Frigate on my Windows 11, somehow since the last update, it break the docker.

[rodrigoratan]

I use relative paths:

volumes:
- /etc/localtime:/etc/localtime:ro
- ../frigate_config:/config:rw
- ../frigate_data/media:/media/frigate:rw
- ../frigate_data/db:/db:rw

frigate_config and frigate_data should be placed in the same parent folder where frigate with docker composer is.

[MinimumDowntime]

I use relative paths:

Huh. How about that. I was so focused trying to make this work initially, I never thought to try this. Excellent work @rodrigoratan 👍

[kshweikeh]

I have a problem that the UI keeps loading on port 5000
and here is the log :

2023-11-16 09:20:33 Traceback (most recent call last):
2023-11-16 09:20:33 File "/usr/local/go2rtc/create_config.py", line 23, in
2023-11-16 09:20:33 with open(config_file) as f:
2023-11-16 09:20:33 FileNotFoundError: [Errno 2] No such file or directory: '/config/config.yml'
2023-11-16 09:20:32 2023-11-16 06:20:32.948214443 [INFO] Preparing go2rtc config...
2023-11-16 09:20:32 2023-11-16 06:20:32.948833456 [INFO] Starting Frigate...
2023-11-16 09:20:32 2023-11-16 06:20:32.949619722 [INFO] Starting NGINX...
2023-11-16 09:20:33 2023-11-16 06:20:33.183227691 [INFO] The go2rtc service exited with code 1 (by signal 0)
2023-11-16 09:20:33 2023-11-16 06:20:33.955265296 *************************************************************
2023-11-16 09:20:33 2023-11-16 06:20:33.955269064 *************************************************************
2023-11-16 09:20:33 2023-11-16 06:20:33.955270526 *** Your config file is not valid! ***
2023-11-16 09:20:33 2023-11-16 06:20:33.955271855 *** Please check the docs at ***
2023-11-16 09:20:33 2023-11-16 06:20:33.955272812 *** https://docs.frigate.video/configuration/index ***
2023-11-16 09:20:33 2023-11-16 06:20:33.955273986 *************************************************************
2023-11-16 09:20:33 2023-11-16 06:20:33.955274801 *************************************************************
2023-11-16 09:20:33 2023-11-16 06:20:33.955300059 *** Config Validation Errors ***
2023-11-16 09:20:33 2023-11-16 06:20:33.955300966 *************************************************************
2023-11-16 09:20:33 2023-11-16 06:20:33.955301660 [Errno 2] No such file or directory: '/config/config.yml'
2023-11-16 09:20:33 2023-11-16 06:20:33.956736719 [2023-11-16 06:20:33] frigate.app INFO : Starting Frigate (0.12.1-367d724)
2023-11-16 09:20:33 2023-11-16 06:20:33.956934921 Traceback (most recent call last):
2023-11-16 09:20:33 2023-11-16 06:20:33.956937018 File "/opt/frigate/frigate/app.py", line 351, in start
2023-11-16 09:20:33 2023-11-16 06:20:33.956937918 self.init_config()
2023-11-16 09:20:33 2023-11-16 06:20:33.956938780 File "/opt/frigate/frigate/app.py", line 80, in init_config
2023-11-16 09:20:33 2023-11-16 06:20:33.956939495 user_config = FrigateConfig.parse_file(config_file)
2023-11-16 09:20:33 2023-11-16 06:20:33.956940305 File "/opt/frigate/frigate/config.py", line 1070, in parse_file
2023-11-16 09:20:33 2023-11-16 06:20:33.956940968 with open(config_file) as f:
2023-11-16 09:20:33 2023-11-16 06:20:33.956941733 FileNotFoundError: [Errno 2] No such file or directory: '/config/config.yml'
2023-11-16 09:20:33 2023-11-16 06:20:33.956942317
2023-11-16 09:20:33 2023-11-16 06:20:33.956943086 *************************************************************
2023-11-16 09:20:33 2023-11-16 06:20:33.956943913 *** End Config Validation Errors ***
2023-11-16 09:20:33 2023-11-16 06:20:33.956944688 *************************************************************
2023-11-16 09:20:34 2023-11-16 06:20:34.198030496 [INFO] Preparing go2rtc config...
2023-11-16 09:20:34 Traceback (most recent call last):
2023-11-16 09:20:34 File "/usr/local/go2rtc/create_config.py", line 23, in
2023-11-16 09:20:34 with open(config_file) as f:
2023-11-16 09:20:34 FileNotFoundError: [Errno 2] No such file or directory: '/config/config.yml'
2023-11-16 09:20:34 2023-11-16 06:20:34.394672251 [INFO] The go2rtc service exited with code 1 (by signal 0)
2023-11-16 09:20:35 2023-11-16 06:20:35.046751189 172.17.0.1 - - [16/Nov/2023:06:20:35 +0000] "GET / HTTP/1.1" 200 6641 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0" "-"
2023-11-16 09:20:35 2023-11-16 06:20:35.087189189 2023/11/16 06:20:35 [error] 134#134: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 172.17.0.1, server: , request: "GET /api/config HTTP/1.1", upstream: "http://127.0.0.1:5001/config", host: "localhost:5000", referrer: "http://localhost:5000/"
2023-11-16 09:20:35 2023-11-16 06:20:35.087194205 172.17.0.1 - - [16/Nov/2023:06:20:35 +0000] "GET /api/config HTTP/1.1" 502 559 "http://localhost:5000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0" "-"
2023-11-16 09:20:35 2023-11-16 06:20:35.129823269 [INFO] Service Frigate exited with code 1 (by signal 0)
2023-11-16 09:20:35 s6-rc: info: service legacy-services: stopping
2023-11-16 09:20:35 s6-rc: info: service legacy-services successfully stopped
2023-11-16 09:20:35 s6-rc: info: service nginx: stopping
2023-11-16 09:20:35 s6-rc: info: service go2rtc-healthcheck: stopping
2023-11-16 09:20:35 2023-11-16 06:20:35.141917306 [INFO] The go2rtc-healthcheck service exited with code 256 (by signal 15)
2023-11-16 09:20:35 s6-rc: info: service go2rtc-healthcheck successfully stopped
2023-11-16 09:20:35 2023-11-16 06:20:35.342473179 [INFO] Service NGINX exited with code 0 (by signal 0)
2023-11-16 09:20:35 s6-rc: info: service nginx successfully stopped
2023-11-16 09:20:35 s6-rc: info: service nginx-log: stopping
2023-11-16 09:20:35 s6-rc: info: service frigate: stopping
2023-11-16 09:20:35 s6-rc: info: service frigate successfully stopped
2023-11-16 09:20:35 s6-rc: info: service go2rtc: stopping
2023-11-16 09:20:35 s6-rc: info: service frigate-log: stopping
2023-11-16 09:20:35 s6-rc: info: service nginx-log successfully stopped
2023-11-16 09:20:35 s6-rc: info: service go2rtc successfully stopped
2023-11-16 09:20:35 s6-rc: info: service go2rtc-log: stopping
2023-11-16 09:20:35 s6-rc: info: service frigate-log successfully stopped
2023-11-16 09:20:35 s6-rc: info: service go2rtc-log successfully stopped
2023-11-16 09:20:35 s6-rc: info: service log-prepare: stopping
2023-11-16 09:20:35 s6-rc: info: service s6rc-fdholder: stopping
2023-11-16 09:20:35 s6-rc: info: service log-prepare successfully stopped
2023-11-16 09:20:35 s6-rc: info: service legacy-cont-init: stopping
2023-11-16 09:20:35 s6-rc: info: service s6rc-fdholder successfully stopped
2023-11-16 09:20:35 s6-rc: info: service legacy-cont-init successfully stopped
2023-11-16 09:20:35 s6-rc: info: service fix-attrs: stopping
2023-11-16 09:20:35 s6-rc: info: service fix-attrs successfully stopped
2023-11-16 09:20:35 s6-rc: info: service s6rc-oneshot-runner: stopping
2023-11-16 09:20:35 s6-rc: info: service s6rc-oneshot-runner successfully stopped

And I am pretty sure about the path of my config file
How can I fix this problem

[MinimumDowntime]

I cannot stress enough how much I'm not trying to insult your intelligence when I ask "Are you sure about the location of the config file?" I would double check this by navigating to the UNC path.

I ask because the log very much suggests that is the issue. But having made several mistakes when I was originally trying to get this going/simultaneously draft this thread. I thought it might be worth sharing some of my own initial troubleshooting and observations before I even started this thread. Here are some of my initial 🤦‍♂️

• I accidentally created a folder called "config.yml"
• The above also led to getting some of the folder structure wrong between tries of getting it initially running
• Once I had the config path set, the errors I started receiving were more along the lines of required configuration in the file that were missing

But even if port 5000 is ever so briefly hosting Frigate, the good news is that it sounds like you're close.

[m-laj]

Thank you for these comprehensive instructions. Saved me many hours!

I am running Windows 11 / WSL2 and have had success passing the Coral USB to WSL2 using the command:

usbipd attach --busid IDENTIFIERHERE --auto-attach --wsl

The problem I'm running into is that this command needs to be given every time the machine starts up or the USB device is not passed through to WSL (and so far I've failed to get this to work as a Task Scheduler task).

Is this to be expected? Any ideas on how to handle this?

[MinimumDowntime]

My apologies on the delay in response. Always great to hear when your work has helped someone else 😄

I too recently ran into this (3 days ago!) and haven't spent a great deal of time troubleshooting other than the pseduo-code that feels like:

1. On startup (or on login, whichever is cleaner)
2. Start a PowerShell script
3. That PowerShell script should be a loop that checks for the availability of WSL as WSL is not immediately available
4. Once WSL is available, mount the Coral

I'll try to see if I can get this going this weekend or sooner. In meantime, I'll update the discussion above. Thanks again for your kind words and help 👍

[MinimumDowntime]

Alright, spent the last few hours on this and figured I'd update this thread with my experience so far.

When I originally got this working, it was done with usbipd v3.2. As of usbipd v4+, "sharing a device is persistent; it survives reboots.". This obviously gave me some hope as I was looking at it, so I went ahead with upgrading. But rebooting my Windows host results in a technicality:

• The device remains shared after a reboot
• The device does not attach after a reboot

But upon a complete reading of usbipd's readme, it does qualify that:

Attaching devices to a client is non-persistent. You will have to re-attach after a reboot, or when the device resets or is physically unplugged/replugged.

All of that said, here's where I'm at with things:

1. I will update the discussion above with new installation steps once I've had this running successfully for a couple days with usbipd 4.1
   • A few steps above need to be updated to reflect changes in usbipd v4.1 (for example, client side tooling is no longer required. Which means no conflicting documentation to deal with and thus, no modifications to WSL required to get this going. All resulting in making things for people getting started with this.)
   • The syntax of the commands has changed
2. I will resume auto-attach testing once I complete the previous step

[MinimumDowntime]

Just reporting back in. Thus far, I haven't been able to reliably do this post reboot. For the sake of thinking aloud, it feels like there are a few possible hooks we'd care about in this process.

• A script that loops for 5 or so minutes after user logon
  • this is just playing the odds
• A script that looks for WSL availability
  • this seems like the most fitting thing, but I'm having trouble reliably parsing output/errors in powershell
• A script that looks for Docker container status
  • this seems too late, the container is always going to try to start/be starting. So this becomes, if it's in a status of start/starting then we are assuming WSL is available and it's failing to find the missing TPU

From my limited understanding of Docker, if there was a script associated with the compose/container it would execute in the context of the container/WSL and not the physical Windows host

Open to suggestions/discussion.

[j2eubank]

have followed directions for coral tpu and can see the device in both windows and wsl (the vid is correct, comes as global unichip corp in wsl) but upon container start frigate is telling me it can't find the tpu.

Any ideas for troubleshooting?

2024-02-15 13:16:53.175712047 [2024-02-15 13:16:49] frigate.detectors.plugins.edgetpu_tfl INFO : Attempting to load TPU as usb
frigate | 2024-02-15 13:16:53.175985145 [2024-02-15 13:16:53] frigate.detectors.plugins.edgetpu_tfl ERROR : No EdgeTPU was detected. If you do not have a Coral device yet, you must configure CPU detectors.
frigate | 2024-02-15 13:16:53.175987745 Process detector:coral:
frigate | 2024-02-15 13:16:53.176866438 Traceback (most recent call last):
frigate | 2024-02-15 13:16:53.176868838 File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 160, in load_delegate
frigate | 2024-02-15 13:16:53.176892638 delegate = Delegate(library, options)
frigate | 2024-02-15 13:16:53.176894438 File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 119, in init
frigate | 2024-02-15 13:16:53.176897338 raise ValueError(capture.message)
frigate | 2024-02-15 13:16:53.176909738 ValueError
frigate | 2024-02-15 13:16:53.176938138
frigate | 2024-02-15 13:16:53.176939838 During handling of the above exception, another exception occurred:
frigate | 2024-02-15 13:16:53.176940738
frigate | 2024-02-15 13:16:53.176941838 Traceback (most recent call last):
frigate | 2024-02-15 13:16:53.176942938 File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
frigate | 2024-02-15 13:16:53.176943838 self.run()
frigate | 2024-02-15 13:16:53.176945038 File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
frigate | 2024-02-15 13:16:53.176946038 self._target(*self._args, **self._kwargs)
frigate | 2024-02-15 13:16:53.176947838 File "/opt/frigate/frigate/object_detection.py", line 102, in run_detector
frigate | 2024-02-15 13:16:53.176949438 object_detector = LocalObjectDetector(detector_config=detector_config)
frigate | 2024-02-15 13:16:53.176950638 File "/opt/frigate/frigate/object_detection.py", line 53, in init
frigate | 2024-02-15 13:16:53.176951738 self.detect_api = create_detector(detector_config)
frigate | 2024-02-15 13:16:53.176964238 File "/opt/frigate/frigate/detectors/init.py", line 18, in create_detector
frigate | 2024-02-15 13:16:53.176965238 return api(detector_config)
frigate | 2024-02-15 13:16:53.176966738 File "/opt/frigate/frigate/detectors/plugins/edgetpu_tfl.py", line 41, in init
frigate | 2024-02-15 13:16:53.176967938 edge_tpu_delegate = load_delegate("libedgetpu.so.1.0", device_config)
frigate | 2024-02-15 13:16:53.176975637 File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 162, in load_delegate
frigate | 2024-02-15 13:16:53.176976937 raise ValueError('Failed to load delegate from {}\n{}'.format(
frigate | 2024-02-15 13:16:53.176978337 ValueError: Failed to load delegate from libedgetpu.so.1.0

[MinimumDowntime]

You're welcome 😄

[MinimumDowntime]

I forgot to follow up on this! In my casual searching, I came across the following thread:

google-coral/edgetpu#536

I haven't tried the suggested workarounds yet, but this sounds A LOT LIKE what we've both experienced.

[j2eubank]

Yeah, this sounds the same. It's very odd behavior, I've only had it happen twice and a detach resolves
I'm going to give this a try though.

[jimmyhhnguyen]

I've tried detaching and attaching a dozen times, and the company name never changes to Google. Is there another workaround for this?

[j2eubank]

Attach and be sure to run lsusb in wsl to ensure you see it (even though named incorrectly). Start frigate and you should see it likely fail to start in the logs (no edge tpu found). Stop frigate, detach and attach it again.

[qubanga]

Thanks a lot for this guide. I have followed it to get Nvidia hwaccell for decode/encode which works like a charm.

However I struggle to get the detect hw support working with tensorrt.

nvidia-smi in WSL outputs:

Which seem to indicate that the GPU is available in WSL.

The frigate log have no errors an talks about GPU:
2024-03-19 11:21:09.803064075 [INFO] Preparing Frigate...
2024-03-19 11:21:09.812231375 [INFO] Starting Frigate...
2024-03-19 11:21:11.053611729 [2024-03-19 11:21:11] frigate.app INFO : Starting Frigate (0.13.2-6476f8a)
2024-03-19 11:21:11.330288519 [2024-03-19 11:21:11] peewee_migrate.logs INFO : Starting migrations
2024-03-19 11:21:11.334376718 [2024-03-19 11:21:11] peewee_migrate.logs INFO : There is nothing to migrate
2024-03-19 11:21:11.338941318 [2024-03-19 11:21:11] frigate.app INFO : Recording process started: 309
2024-03-19 11:21:11.341232118 [2024-03-19 11:21:11] frigate.app INFO : go2rtc process pid: 98
2024-03-19 11:21:11.360333817 [2024-03-19 11:21:11] frigate.app INFO : Output process started: 320
2024-03-19 11:21:11.370507217 [2024-03-19 11:21:11] frigate.app INFO : Camera processor started for 932L_uthus: 325
2024-03-19 11:21:11.375717417 [2024-03-19 11:21:11] frigate.app INFO : Capture process started for 932L_uthus: 326
2024-03-19 11:21:11.497801612 [2024-03-19 11:21:11] detector.tensorrt INFO : Starting detection process: 318
2024-03-19 11:21:11.739667803 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : Loaded engine size: 146 MiB
2024-03-19 11:21:11.895866998 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : [MemUsageChange] Init cuBLAS/cuBLASLt: CPU +6, GPU +8, now: CPU 272, GPU 1132 (MiB)
2024-03-19 11:21:11.903295097 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : [MemUsageChange] Init cuDNN: CPU +1, GPU +8, now: CPU 273, GPU 1140 (MiB)
2024-03-19 11:21:11.912355797 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : [MemUsageChange] TensorRT-managed allocation in engine deserialization: CPU +0, GPU +145, now: CPU 0, GPU 145 (MiB)
2024-03-19 11:21:11.925092297 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : [MemUsageChange] Init cuBLAS/cuBLASLt: CPU +0, GPU +8, now: CPU 127, GPU 1132 (MiB)
2024-03-19 11:21:11.925202097 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : [MemUsageChange] Init cuDNN: CPU +1, GPU +8, now: CPU 128, GPU 1140 (MiB)
2024-03-19 11:21:11.926734897 [2024-03-19 11:21:11] frigate.detectors.plugins.tensorrt INFO : [MemUsageChange] TensorRT-managed allocation in IExecutionContext creation: CPU +0, GPU +30, now: CPU 0, GPU 175 (MiB)

However the system tab in frigate says no GPU detected but says tensorrt is used and the interference speed is better than with default CPU but not on pair with a 1070 GPU.

Does anyone have any pointers to what is going on? Any more logs I can look at?

[MinimumDowntime]

This is unfortunately uncharted and unknown territory for me. I'm not sure I even understand how I could go about attempting to reproduce this.

[bobloadmire]

trying to set this u on intel system, but unfortunately wsl intel_gpu_top returns "not found"

[j2eubank]

Did you run "wsl --install"

[bobloadmire]

yes