CoZ

This might be my issue. Why does the docker container template not have those PATHs "built into" the template? Should the template not have a blank entry for Downloads and Incomplete and Music folder that the user than fills in like other docker templates???

That's all you put in your config.yml and it works??? I've been messing with this for days and still get the error: Failed to scan share /Media/Music: Could not find a part of the path '/Media/Music' I've tried it all the way from /mnt/user/Media/Music and still get the same error no matter what configuration I use. Your full path is /musique and that's all??? You didnt' add some PATH to the original docker container or anything like that? Just edited the YML?

I've gone and upgraded the Hardware in my Server. I've removed my NVIDIA GPU to save power and added an Intel QuickSync capable CPU. I've switched over the docker container to use the Intel and remove the NVIDIA reference. Testing it out, it has converted two files already and they are the exact same file size. The original and the encoded file. I'm not sure why they would remain the same file size at the end of the encode as using the NVIDIA plugin shrunk the filesize considerably. Its in the process of converting two more files and I can see that it is, indeed using the Intel GPU:

Well, thank you for that. That was 30 minutes of pucker factor waiting for a reply. lol

Thanks. That did it. I checked the Advanced BIOS Config and it made no mention of that. Where did you dig up that fix?

I thought of that as you were replying. Yes I had an EFI- folder. Just renamed it to EFI.

I can't boot into Unraid. It just boots into the BIOS. That's my issue.

It's the only boot drive showing in the BIOS. No matter what USB2 I stick the Thumb Drive into, it still only reboots into BIOS. Upgraded my hardware from old XEONs to something built this century. So, the USB device worked in previous build. Not sure what to do next as I've exhausted all my USB2 ports. I also disabled fast boot in the BIOS as well.

So then, yes, add the 'retain / default' entry to the Snapshots as well.

Anyone else have an issue with recordings not being deleted as set up by the config file? For instance, I have record: enabled: True events: retain: default: 2 snapshots: enabled: True But, I've still got 7+ days of recordings. Looking at this again, maybe it's just the snapshots / thumbnails that aren't being automatically deleted? Do I have to add a 'retain: default: 2' under the snapshots entry as well?

The only thing I get while in game is "High server load - there maybe some hiccups" message on the lower left. I actually never see any hiccups though and my server is never "maxxed out" either.

Sound like my experience with anyone involved in the Frigate project - they arent' friendly nor do they ever want to help. I feel your pain.

@ONI: Backup your /appdata/enshrouded directory (copy it somehwere else) Take screenshots of your current containers variables (if you aren't going to remember what you had them set up as) Remove the Enshrouded Container Remove the Enshrouded Container template (if it exsists? not sure if there would be one if you manually created or, imported XML) Pull down new Enshrouded container from Community Apps store. Enter in the variables / paths from your previous Enshrouded container. Move back the /appdata/enshrouded directory, overwritting the folder if already present in /appdata @Nodiaque FYI for those of us who imported your XML and/or installed the old version of your container before you added the backup function, pulling down the newest container from C.A. doesn't add those variables for the backup capability. One has to add them manually or, remove the current container and pull down the new container but, backing up everything like above. Just in case someone comes on here asking.

Done.

I'm launching it as I do every other container. Right clicking + Start Container. These are the entire logs when it first starts up: s6-rc: info: service s6rc-fdholder: starting s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service s6rc-fdholder successfully started s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service trt-model-prepare: starting s6-rc: info: service log-prepare: starting s6-rc: info: service log-prepare successfully started s6-rc: info: service nginx-log: starting s6-rc: info: service go2rtc-log: starting s6-rc: info: service frigate-log: starting s6-rc: info: service nginx-log successfully started s6-rc: info: service go2rtc-log successfully started s6-rc: info: service go2rtc: starting s6-rc: info: service frigate-log successfully started s6-rc: info: service go2rtc successfully started s6-rc: info: service go2rtc-healthcheck: starting s6-rc: info: service go2rtc-healthcheck successfully started Generating the following TRT Models: yolov4-416,yolov4-tiny-416 Downloading yolo weights 2024-02-01 10:30:12.079536551 [INFO] Preparing new go2rtc config... 2024-02-01 10:30:13.159361526 [INFO] Starting go2rtc... 2024-02-01 10:30:13.279687971 10:30:13.279 INF go2rtc version 1.8.4 linux/amd64 2024-02-01 10:30:13.280390371 10:30:13.280 INF [api] listen addr=:1984 2024-02-01 10:30:13.280428249 10:30:13.280 INF [rtsp] listen addr=:8554 2024-02-01 10:30:13.280808608 10:30:13.280 INF [webrtc] listen addr=:8555 Creating yolov4-tiny-416.cfg and yolov4-tiny-416.weights Creating yolov4-416.cfg and yolov4-416.weights Done. 2024-02-01 10:30:21.744747617 [INFO] Starting go2rtc healthcheck service... Generating yolov4-416.trt. This may take a few minutes. Traceback (most recent call last): File "/usr/local/src/tensorrt_demos/yolo/onnx_to_tensorrt.py", line 214, in <module> main() File "/usr/local/src/tensorrt_demos/yolo/onnx_to_tensorrt.py", line 202, in main engine = build_engine( File "/usr/local/src/tensorrt_demos/yolo/onnx_to_tensorrt.py", line 112, in build_engine with trt.Builder(TRT_LOGGER) as builder, builder.create_network(*EXPLICIT_BATCH) as network, trt.OnnxParser(network, TRT_LOGGER) as parser: TypeError: pybind11::init(): factory function returned nullptr [02/01/2024-10:30:38] [TRT] [W] Unable to determine GPU memory usage [02/01/2024-10:30:38] [TRT] [W] Unable to determine GPU memory usage [02/01/2024-10:30:38] [TRT] [W] CUDA initialization failure with error: 35. Please check your CUDA installation: http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html Loading the ONNX file... Generating yolov4-tiny-416.trt. This may take a few minutes. Traceback (most recent call last): File "/usr/local/src/tensorrt_demos/yolo/onnx_to_tensorrt.py", line 214, in <module> main() File "/usr/local/src/tensorrt_demos/yolo/onnx_to_tensorrt.py", line 202, in main engine = build_engine( File "/usr/local/src/tensorrt_demos/yolo/onnx_to_tensorrt.py", line 112, in build_engine with trt.Builder(TRT_LOGGER) as builder, builder.create_network(*EXPLICIT_BATCH) as network, trt.OnnxParser(network, TRT_LOGGER) as parser: TypeError: pybind11::init(): factory function returned nullptr [02/01/2024-10:30:41] [TRT] [W] Unable to determine GPU memory usage [02/01/2024-10:30:41] [TRT] [W] Unable to determine GPU memory usage [02/01/2024-10:30:41] [TRT] [W] CUDA initialization failure with error: 35. Please check your CUDA installation: http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html Loading the ONNX file... Available tensorrt models: ls: cannot access '*.trt': No such file or directory s6-rc: warning: unable to start service trt-model-prepare: command exited 2 I had removed the original Frigate container and template and pulled down a "fresh" copy for v13 and installed the NVIDIA Branch when it asked me in Community Apps which branch I wanted to install. So I did not upgrade from 12-13, I started with a new pull down of the container. I wanted to be safe that there would be no issues left over.