Phoenix Down

Then you better add some print statements

The point is to log your stdout & stderr to a logfile, so that even if the process does get shot in the head, you can still go look in the log file to see what happened up until the moment the process was killed.

Also look into the "at" command.

Not everything needs to be configurable if it's never going to change.

Try just: cp -R mnt/user/metadates/movies/. mnt/user/movies/ It's not a shell script. No need to put "bash" in front.

Check out this guide: https://hub.shinobi.video/articles/view/DmWIID78VtvEfnf

Sounds like you might be transcoding the video stream, which always requires a ton of CPU power and is just not worth it IMHO. Find out what format video stream your IP cam produces, and then set the video format in Shinobi to match. For me, it's H.264. During active recording, my 8 core CPU uses less than 1% utilization for 2 cameras. In this case, Shinobi is just taking the video streams from the cameras and saving them to disk, which takes very little CPU power.

Right, but it doesn't appear to be working as advertised. Hence taking matters into your own hands

What if you crawl the process tree and kill each child process individually? It's a bit heavy handed, but should take care of any orphaned child processes.

Yes. No.

Mount button is grayed out and "Pass Thru" column (and most every column) is just "-". I suppose I need to have a MicroSD card inserted to activate the Pass Thru option?

Good info, thank you! How do you go about marking an unassigned device as pass through? I poked around the UD settings but I'm not seeing anything.

Hi all. I have a SD/MicroSD card reader, and the MicroSD port shows up as its own device under UD, but I never use it. I'd like to hide it in UD. Is this possible?

Good info, thanks I don't think I ever looked at the "-i" switch.

You could write a small Perl script to do it. Maybe something like this: #!/usr/bin/env perl use strict; use warnings; use Carp; use English; # Read the file my $file = "/mnt/user/text/mytestfile.txt"; my $fh; open $fh, "<", $file or croak("\nERROR: Cannot open '$file' for reading: $OS_ERROR\n\n"); my @rawdata = <$fh>; close $fh; # Update each line my @newdata; foreach my $line (@rawdata) { $line =~ s/#FF8C2F/#42ADFA/g; push @newdata, $line; } # Update the file with the updated data open $fh, ">", $file or croak("\nERROR: Cannot open '$file' for writing: $OS_ERROR\n\n"); foreach my $line (@newdata) { print $fh $line; } close $fh;

It's a bit more heavyweight solution, but you can always write your own wrapper that does logging, timeouts, interlocking, and notifications. Then you can run all of your crons using this wrapper.

I seem to recall reading about this particular error and something to do with the "use camera timestamp" settings or something like that. It's been a while.

I hear you, orphaned processes are a pain in the rear. After you send the SIGTERM, do you wait at all before sending SIGKILL?

I had a similar problem, but with scheduled recordings not starting after a day or two. Still no true resolution, but found an accidental workaround. I use the CA Appdata Backup/Restore v2 to back up all of my Docker data. The default behavior is that it turns off the docker while backing up the data then turns them back on. It only takes a few seconds, but effectively restarts the Shinobi docker daily. The schedule recordings have been working fine every day since.

First of all, as I've learned the hard way, support and development for this rclone container is basically dead. Most people have moved on to the rclone plugin, which is actively developed and supported, and its support thread is pretty active. Also, one side effect I found is that doesn't matter what I do, the container writes to the docker image somewhere everytime rclone runs, which wakes up my SSDs (cache pool). With that said, to answer your question: you run it from the container's console. When it gets to this part: Use auto config? * Say Y if not sure * Say N if you are working on a remote or headless machine or Y didn't work y) Yes n) No DO NOT choose "yes". Choose "no" instead, and it will give you a link to Google website to get the access code.

@Squid can provide the real answer, but I suspect that User Script may be sending a SIGKILL to stop the script. When you are running your script interactively and you push Ctrl-C, a SIGINT signal is sent to your script. If your script has a signal handler (which the atexit exit handler is), this signal can be caught, which allows your script to do a more graceful exit. In your case, that includes sending an email before exiting. However, a script with a signal handler can misbehave, either by choosing to or failing to exit after intercepting the SIGINT. This is where SIGKILL comes in. That's the signal that is sent when you run "kill -9 $PID". SIGKILL cannot be caught by a signal handler. It just shoots the script in the head immediately without waiting for a response. Generally speaking, it's better to send a SIGINT first to allow a process to exit gracefully. And after a certain amount of time (i.e. 10 secs) and the process still has not exited, then send a follow-up SIGKILL to kill it immediately. If I'm right and User Scripts only sends SIGKILL, then perhaps this is a feature request you can put in for User Script.

Thanks for the tip! Since I've now realized that rclone won't sync partial/open files, there is no point in trying to sync so frequently. Now I have the sync schedule aligned with the video file creation (set to be 5 minutes max per video). So my cron schedule is now: */5 * * * * And my script is: sleep 5 rclone sync ...

Simple question: If the "clearLog" option is not turned on, does a script's log file ever get rotated or does it just keep growing until /tmp is full?

When you mount a rclone remote to "/mnt/disks/", where are those files physically located on the local machine? Is it on a specific array disk? Or is it essentially just a bunch of symlinks to the files in the remote?

@mgutt: sync does work just fine and that's what I've been doing. I'm only considering mount because of the potential lower latency (i.e. rclone sync crons can only go as low as once per minute). But that idea may have been thwarted, as it doesn't look like rclone will sync any files that is still being written to (as @Stupifier mentioned in his post). From the rclone sync log: 2020/07/22 10:30:08 ERROR : Attempt 1/3 failed with 2 errors and: can't copy - source file is being updated (size changed from 842 to 1025570) The QNAP cloud sync app does sync partial files, so I just assumed that rclone does as well. @testdasi: I assume you are referring to @DZMM's guide here? That seems like a great solution for people who want to have a directory with files that are both local and remote but transparent to the end user. That actually reminds me of how Unraid handles files in cache and array. It's transparent to the user regardless whether the file is in cache or in array, and the mover can move the files around. But as you said, since I'm only using the remote as a sync destination and never read from it, perhaps "rclone sync" is enough. @Stupifier: Thanks for the reply. What you said about not mounting to "/mnt/user" or "/mnt/user0" totally makes sense. However, @DZMM's guide mentioned above specifically instructs you to create various mount points inside "/mnt/user". Why isn't that frowned upon? @testdasi - feel free to chime in here as well. I looked at Cloudplow, it seems like it does the same/similar thing as @DZMM's scripts? I don't use Plex, NZBGet, or Unionfs, so this is just my impression from a quick read on their Github page.