TurboStreetCar

Cant install new version because the minimum version is still set to 7.0. I could try removing that from the PLG file and try installing. Maybe ill give that a shot. But it works with the V10.02 just fine on pre V7 unraid.

@VladoPortos Much appreciated. Question, would it be possible for you to update the archive file for version 2024.10.02 for those of us not using Unraid Version 7? I attempted to create my own archive file, but when installing the plugin, it downloads the archive txz from github and overwrites the custom txz archive file. Not sure what the best way to go about this is. To fix on pre Unraid version 7, you must upload a fixed folder.js file, and copy it to the correct directory manually. In my experience, folders still work without the fix, but creating new folders is broken. Ive attached a fixed folder.js file for pre Unraid Version 7. It must be placed into the directory "/usr/local/emhttp/plugins/folder.view/scripts" after installation for anyone attempting to fix in the mean time. folder.js

Are there any plans to implement user permissions? For example an admin user that has access to settings/config, and other users that can only view cameras?

I agree, but i didnt know if the ZFS part needed to be there or not, so i figured id leave it alone.

Figured i would put the whole script here for anyone else looking to make this change. One thing to note, the origional trim function is run with an echo, which outputs to the syslog information about what was trimmed. The later trim function has no echo statement and will not output any data to the syslog. Ive added an echo statement that outputs that information to the syslog. The updated script: #!/usr/bin/php -q <?PHP /* Copyright 2005-2023, Lime Technology * Copyright 2012-2023, Bergware International. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License version 2, * as published by the Free Software Foundation. * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. */ ?> <? $docroot = $docroot ?? $_SERVER['DOCUMENT_ROOT'] ?: '/usr/local/emhttp'; require_once "$docroot/webGui/include/Wrappers.php"; extract(parse_plugin_cfg('dynamix',true)); // cron operation if ($argc==2 && $argv[1]=='cron') { // trim btrfs, xfs //echo shell_exec("fstrim -va 2>/dev/null"); // trim zfs zfs_trim(false); //exit(0); } // add translations $_SERVER['REQUEST_URI'] = 'settings'; $login_locale = _var($display,'locale'); require_once "$docroot/webGui/include/Translations.php"; function write(...$messages){ $com = curl_init(); curl_setopt_array($com,[ CURLOPT_URL => 'http://localhost/pub/plugins?buffer_length=1', CURLOPT_UNIX_SOCKET_PATH => '/var/run/nginx.socket', CURLOPT_POST => 1, CURLOPT_RETURNTRANSFER => true ]); foreach ($messages as $message) { curl_setopt($com, CURLOPT_POSTFIELDS, $message); curl_exec($com); } curl_close($com); } function is_hdd($disk) { $disk = explode('/',$disk); $disk = preg_replace('/^(sd[a-z]+|nvme[0-9]+n1)p?1$/','$1',end($disk)); return file_get_contents("/sys/block/$disk/queue/rotational")==1; } function zfs_info($name) { $trim = preg_replace('/(.$)/',' $1',exec("zfs list -Ho used $name"))."iB"; $bytes = exec("zfs list -Hpo used $name"); exec("zpool list -vHP $name|grep -Po '^\s+\K/\S+'",$devs); foreach ($devs as &$dev) if (is_hdd($dev)) $dev = ''; return "/mnt/$name: $trim ($bytes bytes) trimmed on ".implode(', ',array_filter($devs)); } function zfs_trim($write) { if (!file_exists('/proc/spl/kstat/zfs/arcstats')) return; exec("zfs list -d0 -Ho name",$pools); foreach ($pools as $name) { if ($write) { write("/mnt/$name: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); if (exec("zpool trim -w $name 2>&1")=='') write(zfs_info($name)."\r","\n"); else write("\r"); } else { if (exec("zpool trim -w $name 2>&1")=='') echo zfs_info($name)."\n"; } } } write(_("TRIM operation started")."\n","\n","\n"); echo "Trim Operation Started\n"; // trim btrfs, xfs exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'",$mounts); foreach ($mounts as $mount) { [$target,$source] = explode(' ',$mount); if (is_hdd($source)) continue; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); echo $trim,"\n"; //Echo information to syslog. if ($trim) write("$trim on $source\r","\n"); else write("\r"); } // trim zfs zfs_trim(true); write(_("Finished")."\n",'_DONE_',''); echo "Trim Operation Finished\n"; ?>

Trim just ran on the new script with the cron check commented out as shown above. Script ran as i now expected it to run, gave me output to the ssd_trim.log file specified, and skipped the spinning disks. Looks like its fixed. Marking the above post as the solution and going to make a post in bug reports. Thanks so much!!!!

@shorty_ Ah Ha! I think thats the key right there! I wonder why they have it check for to see if its running as a cron job, and then have it run differently? Maybe thats a bug? I will make those changes and change the schedule to run it again later tonight to see if it runs properly and report back!

OK so i added some debug commands to the ssd_trim script found in /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim. This is the final function of the script now: $myfile = fopen("ssd_trim.log", "a"); $timestamp = date("m/d/Y - H:i:s"); ### Open Log File fwrite($myfile,"Trim Started at $timestamp\n\r"); ### Write Timestamp of beginning of Trim write(_("TRIM operation started")."\n","\n","\n"); // trim btrfs, xfs exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'",$mounts); foreach ($mounts as $mount) { [$target,$source] = explode(' ',$mount); fwrite($myfile,"Checking Source: $source Target: $target\n\r"); ### Write current $source and $target being checked if (is_hdd($source)) continue; fwrite($myfile,"$source Is HDD\n\r"); ### Result of HDD Check write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); if ($trim) fwrite($myfile, "Trimming $source\n\r"); else fwrite($myfile, "Not Trimming $source\n\r"); ### Write to log file when drive is trimmed } // trim zfs zfs_trim(true); write(_("Finished")."\n",'_DONE_',''); fwrite($myfile, "Finished Trim \n\r\n\r\n\r"); ### Write end of trimming operation fclose($myfile); ### Close log file When i run this in a terminal using the command: root@Backup:/usr/local/emhttp/plugins/dynamix/scripts# php ssd_trim The log file received this output: Trim Started at 07/06/2024 - 13:47:42 Checking Source: /dev/md1p1 Target: /mnt/disk1 Checking Source: /dev/nvme0n1p1 Target: /mnt/cache /dev/nvme0n1p1 Is HDD Trimming /dev/nvme0n1p1 Checking Source: /dev/sde1 Target: /mnt/cctv Checking Source: /dev/nvme1n1p1 Target: /mnt/deluge_pool /dev/nvme1n1p1 Is HDD Trimming /dev/nvme1n1p1 Checking Source: /dev/sdb1 Target: /mnt/plex /dev/sdb1 Is HDD Trimming /dev/sdb1 Checking Source: /dev/loop2 Target: /var/lib/docker /dev/loop2 Is HDD Trimming /dev/loop2 Checking Source: /dev/loop3 Target: /etc/libvirt /dev/loop3 Is HDD Trimming /dev/loop3 Finished Trim I received this output ALSO when i click the "Trim Now" button in the scheduler page. HOWEVER........ I changed the schedule to run a trim at 1400 Hours (44 minutes ago, my local time) and it is taking WAY longer to run, AND im receiving "disk full" errors in my Frigate container. SO i checked "system processes" on the tools page, and i see these entries related to SSD Trim: root 888 0.0 0.0 3972 2832 ? S 14:00 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim cron|logger &> /dev/null root 911 0.0 0.0 95616 27620 ? SL 14:00 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim cron root 912 0.0 0.0 2588 900 ? S 14:00 0:00 logger root 913 0.0 0.0 3976 2880 ? S 14:00 0:00 sh -c fstrim -va 2>/dev/null root 914 0.0 0.0 3332 1068 ? D 14:00 0:01 fstrim -va Which leads me to believe, that its running the same script that im running both manually in terminal, and by hitting the Trim Now button. So im not sure whats going on, but it definitely seems to be running a different script on the schedule vs pressing the trim now button, or running that same script in a terminal. Is there anything i can do to more thoroughly check what is the difference between these two different methods of running (seemingly) the same script?

Hmm. I think before i do this, im going to try to add a debug line to the script to write an output to a file to make sure the scheduled trim is running the same script.

Thats what i would expect too, but seems to be different. Maybe its running with a different level of permission or something? Ill admit when it comes to these things its beyond my depth. I can google some code stuff and get by, but ill admit im not sure how to diagnose whats going on. It doesnt seem unraid has user settable mount options. How would i go about trying this? I guess another question, If i have the drives set for "AutoTrim = ON", do i need to run a scheduled trim at all?

Yea I'm not sure why it didn't show cache. When i ran it, it displayed the path, but then it seemed to overwrite that line with the deluge pool line. I just ran it again, and it shows cache now. Cache has always existed and was never disconnected. So not sure why it wasn't listed. Ive attached my diagnostic Zip. @shorty_ I changed the trim schedule this past Sunday, to run it Tuesday instead of on Monday, so that should have taken care of that. backup-diagnostics-20240703-1416.zip

Im using a WD Purple HDD. It apparently supports trim, but this may be a bug in the scheduled trim function of unraid, as the script checks for "spinning disks", but scheduled trim seems to operate differently then the script in the dynamix folder.

@_Shorty and @JorgeB : that back and fourth you guys just had is a little above my level, so im not sure. I just ran a "trim now" from the schedule page, and this was the results. So it appears the scheduled trim function, is separate from the script at /usr/local/emhttp/plugins/dynamix/scripts. I ran the command @JorgeB mentioned to check the other script and this was the output: root@Backup:/# cat /boot/config/plugins/dynamix/ssd-trim.cron # Generated TRIM schedule: 0 4 * * 2 /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim cron|logger &> /dev/null So it seems to reference the other script when ran. Is there a way i can find out what is actually running when the scheduled trim is triggered? It seems like it must be a different script/command then the script at that location, or else i wouldnt be getting mixed results. Is this potentially a bug that I've inadvertently discovered?

So I did a test, i changed the final function to this: exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'",$mounts); foreach ($mounts as $mount) { [$target,$source] = explode(' ',$mount); echo "before $source \r\n"; if (is_hdd($source)) continue; echo "continue $source \r\n"; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); } And this was the output: root@Backup:/usr/local/emhttp/plugins/dynamix/scripts# php ssd_trim_test before /dev/md1p1 before /dev/nvme0n1p1 continue /dev/nvme0n1p1 before /dev/sde1 <------Does not continue before /dev/nvme1n1p1 continue /dev/nvme1n1p1 before /dev/sdb1 continue /dev/sdb1 before /dev/loop2 continue /dev/loop2 before /dev/loop3 continue /dev/loop3 So it seems when i run the script manually, it skips the drive, but when it runs on schedule, it definitely trims all the drives. So i guess, maybe its a different script that it runs on the schedule?

True, but alot of people are using Frigate, and id imagine some of them are recording to a standard HDD AND are running trim on a schedule. So i feel like i must be doing something wrong if no one else is having this issue. Thanks i may add that to the script. Only problem, is i cant seem to find where its writing things to. It must have a log somewhere, but i cant find it. I've look all over the directories and cant find any output. The only output to the syslog is this: Jul 2 06:56:16 Backup root: /etc/libvirt: 32 GiB (34357972992 bytes) trimmed on /dev/loop3 Jul 2 06:56:16 Backup root: /var/lib/docker: 15.2 GiB (16307412992 bytes) trimmed on /dev/loop2 Jul 2 06:56:16 Backup root: /mnt/plex: 40.3 GiB (43228676096 bytes) trimmed on /dev/sdb1 Jul 2 06:56:16 Backup root: /mnt/deluge_pool: 233.3 GiB (250475106304 bytes) trimmed on /dev/nvme1n1p1 Jul 2 06:56:16 Backup root: /mnt/cctv: 1.2 TiB (1337126363136 bytes) trimmed on /dev/sde1 Jul 2 06:56:16 Backup root: /mnt/cache: 197.6 GiB (212154335232 bytes) trimmed on /dev/nvme0n1p1 But in the script it seems to write alot of things not shown here.

Im having a problem with the integrated "trim" plugin, I created a thread as its somewhat detailed. Ive linked to it below. The issue im having is the scheduled trim, is performing a trim on a HDD, that is alone in a pool designated for use by Frigate to store CCTV Footage. Frigate works perfectly fine, until the scheduled trim runs, and causes "no space available" errors in the container. In the thread below i dove into the script somewhat, and found it checks for if a drive is a spinning drive or SSD, but its still running the trim on the HDD anyway. Any input on how i can prevent the trim from being performed on this particular drive?

Should the trim script know whether a drive is CMR or SMR? Or are you referring to a manual operation?

Looking in the Dynamix SSD Trim script, there is this portion: function is_hdd($disk) { $disk = explode('/',$disk); $disk = preg_replace('/^(sd[a-z]+|nvme[0-9]+n1)p?1$/','$1',end($disk)); return file_get_contents("/sys/block/$disk/queue/rotational")==1; } Ive run the following command: ***CCTV HDD - sde*** root@Backup:# cat /sys/block/sde/queue/rotational 1 ***Cache SSD - sdb*** root@Backup:# cat /sys/block/sdb/queue/rotational 0 So it would seem, that when Trim is scheduled and ran, in this function: write(_("TRIM operation started")."\n","\n","\n"); // trim btrfs, xfs exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'",$mounts); foreach ($mounts as $mount) { [$target,$source] = explode(' ',$mount); if (is_hdd($source)) continue; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); } It checks to see if the disk is a "Spinning disk", and while im not super up on code, it would(should?) only continue the trim if the drive is a SSD. Although, it seems to "Continue" if that returns a "1", which would be a positive indication of a spinning drive. Shouldn't it be that any disk that returns a "1" would be skipped? OR is it desired to run trim on spinning drives as well as SSD's? I figured the "SSD trim" plugin, would be targeted towards SSD's and not HDD's. Also, it runs Trim on all of my drives, outside of array drives, so im not sure this check is actually effecting the trim at all?

According to this link from WD: https://products.wdc.com/library/SpecSheet/ENG/product-brief-wd-purple-hdd.pdf Says the drive is CMR. Im not sure how that effects trim and accessibility. I feel like this problem should be effecting other people, but im not seeing anyone talk about it. Is it possible that the problem is with how the drive is configured? Would XFS vs BTRFS make a difference? Not sure which should be used, but when i set up the drive it seemed that people preferred XFS. One of the things i did while trying to figure this out, was turn off "autotrim", but it didn't seem to change the effect of the scheduled trim for the errors in the container. I dont get any other errors, from any other container or from any other storage device. However, other then the array, all the other devices are SSD's, so maybe thats why?

Output of requested command: root@Backup:~# hdparm -I /dev/sde | grep TRIM * Data Set Management TRIM supported (limit 10 blocks) root@Backup:~# The drive configuration, incase it helps:

Yes, standard hard drive. Its a WD Purple surveillance drive. Output of the command you requested: root@Backup:~# cat /boot/config/plugins/dynamix/ssd-trim.cron # Generated TRIM schedule: 0 4 * * 2 /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim cron|logger &> /dev/null

Gotcha, just made a post. Figured id post here as i would assume the scheduled trim would be something most people use and seems to cause a conflict. Are you running a scheduled trim?

Hello, im having a problem with drive trim. My arrangement, is using Frigate for CCTV, with its own single hard drive, set up a separate pool outside of the array. I seem to have a problem when scheduled trim occurs, i get errors in the frigate docker log that the drive is out of space (The drive has over 1 TB of free space) when the scheduled Trim runs. Ive attached a segment of my unraid syslog, and a segment of the Frigate Container log that shows how the issue seems to be tied together. Trim, in scheduler is set to happen at 4:00AM on Tuesday. In the frigate log, at 4:42, i begin having the following errors in the log. 2024-07-02 04:42:47.136001501 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly 2024-07-02 04:42:47.136004621 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : [segment @ 0x5637d95e1c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly 2024-07-02 04:42:47.137995300 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : [segment @ 0x5611227abc00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly 2024-07-02 04:42:47.138492208 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138495061 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : [segment @ 0x5637d95e1c00] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138496483 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : [segment @ 0x5611227abc00] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138500204 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : av_interleaved_write_frame(): No space left on device 2024-07-02 04:42:47.138521748 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : [segment @ 0x5611227abc00] Failure occurred when ending segment '/tmp/cache/[email protected]' 2024-07-02 04:42:47.138523115 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : Error writing trailer of /tmp/cache/Garage_Side@%Y%m%d%H%M%S%z.mp4: No space left on device 2024-07-02 04:42:47.138535799 [2024-07-02 04:42:47] watchdog.Garage_Side INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:47.138550217 [2024-07-02 04:42:47] watchdog.Garage_Side INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:47.138551371 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Non-monotonous DTS in output stream 0:0; previous: 282908506, current: 282908506; changing to 282908507. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138552618 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Non-monotonous DTS in output stream 0:0; previous: 923672688, current: 923672688; changing to 923672689. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138571502 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : av_interleaved_write_frame(): No space left on device 2024-07-02 04:42:47.138592472 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Failure occurred when ending segment '/tmp/cache/[email protected]' 2024-07-02 04:42:47.138616921 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : av_interleaved_write_frame(): No space left on device 2024-07-02 04:42:47.138638107 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : Error writing trailer of /tmp/cache/Garage_Right@%Y%m%d%H%M%S%z.mp4: No space left on device 2024-07-02 04:42:47.138662730 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : [segment @ 0x5637d95e1c00] Failure occurred when ending segment '/tmp/cache/[email protected]' 2024-07-02 04:42:47.138683980 [2024-07-02 04:42:47] watchdog.Garage_Right INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:47.138707161 [2024-07-02 04:42:47] watchdog.Garage_Right INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:47.138729570 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : Error writing trailer of /tmp/cache/Garage_Left@%Y%m%d%H%M%S%z.mp4: No space left on device 2024-07-02 04:42:47.138751523 [2024-07-02 04:42:47] watchdog.Garage_Left INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:47.138773905 [2024-07-02 04:42:47] watchdog.Garage_Left INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:57.143311816 [2024-07-02 04:42:57] ffmpeg.Garage_Left.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:42:57.143367651 [2024-07-02 04:42:57] ffmpeg.Garage_Right.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:42:57.147280694 [2024-07-02 04:42:57] ffmpeg.Garage_Left.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:42:57.147285087 [2024-07-02 04:42:57] ffmpeg.Garage_Side.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:42:57.147303503 [2024-07-02 04:42:57] ffmpeg.Garage_Right.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:42:57.147342913 [2024-07-02 04:42:57] ffmpeg.Garage_Left.record ERROR : 2024-07-02 04:42:57.147407979 [2024-07-02 04:42:57] ffmpeg.Garage_Right.record ERROR : 2024-07-02 04:42:57.147410872 [2024-07-02 04:42:57] watchdog.Garage_Left INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:57.147434966 [2024-07-02 04:42:57] watchdog.Garage_Left INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:57.147458919 [2024-07-02 04:42:57] watchdog.Garage_Right INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:57.147483551 [2024-07-02 04:42:57] watchdog.Garage_Right INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:57.147506119 [2024-07-02 04:42:57] ffmpeg.Garage_Side.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:42:57.147526435 [2024-07-02 04:42:57] ffmpeg.Garage_Side.record ERROR : 2024-07-02 04:42:57.147576917 [2024-07-02 04:42:57] watchdog.Garage_Side INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:57.147578381 [2024-07-02 04:42:57] watchdog.Garage_Side INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:43:07.151769949 [2024-07-02 04:43:07] ffmpeg.Garage_Left.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:43:07.151827751 [2024-07-02 04:43:07] ffmpeg.Garage_Left.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:43:07.151849750 [2024-07-02 04:43:07] ffmpeg.Garage_Left.record ERROR : 2024-07-02 04:43:07.151884017 [2024-07-02 04:43:07] watchdog.Garage_Left INFO : Terminating the existing ffmpeg process... 2024-07-02 04:43:07.151904754 [2024-07-02 04:43:07] watchdog.Garage_Left INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:43:07.153795638 [2024-07-02 04:43:07] ffmpeg.Garage_Side.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:43:07.153850342 [2024-07-02 04:43:07] ffmpeg.Garage_Right.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:43:07.153888710 [2024-07-02 04:43:07] ffmpeg.Garage_Side.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:43:07.153915462 [2024-07-02 04:43:07] ffmpeg.Garage_Right.record ERROR : Error initializing output stream 0:0 -- These errors repeatedly continue until exactly 6:55AM. In the Unraid syslog, i have this entry: Jul 2 06:56:16 Backup root: /etc/libvirt: 32 GiB (34357972992 bytes) trimmed on /dev/loop3 Jul 2 06:56:16 Backup root: /var/lib/docker: 15.2 GiB (16307412992 bytes) trimmed on /dev/loop2 Jul 2 06:56:16 Backup root: /mnt/plex: 40.3 GiB (43228676096 bytes) trimmed on /dev/sdb1 Jul 2 06:56:16 Backup root: /mnt/deluge_pool: 233.3 GiB (250475106304 bytes) trimmed on /dev/nvme1n1p1 Jul 2 06:56:16 Backup root: /mnt/cctv: 1.2 TiB (1337126363136 bytes) trimmed on /dev/sde1 Jul 2 06:56:16 Backup root: /mnt/cache: 197.6 GiB (212154335232 bytes) trimmed on /dev/nvme0n1p1 So it would seem, that the scheduled TRIM of the CCTV drive, is what is causing the errors. The Frigate container, otherwise, runs completely error free up until the following week when it again runs the scheduled trim. I originally had the scheduled trim set to run on Monday morning at the same time, i moved the trim to Tuesday to verify they are related, and the problem in the frigate log followed to Tuesday. Is there a way to have the CCTV drive excluded from the scheduled trim?

This log is from last week, But i had Trim in the scheduler set for monday 4AM, and every monday morning, i would have these errors. This week, i changed the trim in scheduler to tuesday, and have no errors. In the frigate docker log, you can see it shut down for appdata-backup at 3:00, and then it starts having drive space errors at 4:57, which i belive is when the trim is acting upon the CCTV drive frigate is recording to. In the unraid syslog, you can see the trim completes at 6:41, which is when all of the disk space errors in the frigate log abruptly stop. Im not sure if i can somehow prevent the scheduled trim from trimming the CCTV drive? My CCTV drive is set up as a pool and is not on the array. Maybe im missing something in its configuration? frigate.log Unraid syslog.log