I'm running the below script daily. Trying to use --min-age flag to let things sit locally for a while (thanks for the very helpful scripts, @Animosity022 !)
Finding that Sonarr/Radarr by default seems to keep the downloaded file's date, or has settings to change it to original air date. In both cases the date is often far in the past, escaping my 4 day range, so the file is often moved sooner than I'd like.
I understand --min-age is looking at modification date, confirmed with rclone lsl.
Is there a solution that allows me to do this without changing the file's date? The original dates are helpful down the road in Plex.
What is your rclone version (output from rclone version)
v1.53.0-DEV
Which OS you are using and how many bits (eg Windows 7, 64 bit)
os/arch: linux/amd64
go version: go1.14.7
Which cloud storage system are you using? (eg Google Drive)
Google Drive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
I'm not sure how you'd accomplish that as by changing the date, it would make things odd.
What's the reason for doing that as having the modtime going back to air date feels like it would break more than it would help. I've never used that as I'd like to understand why you'd think it would be helpful in Plex as it doesn't care to my knowledge.
I only care about file date for Plex "recently aired" section. I don't want to surface a bunch of old stuff there. I assumed that was the purpose of Sonarr/Raddar "change file date" option. But come to think of it... Plex is probably not using file date for that anyways.
All I really want to happen is letting the files sit for a few days so Plex can do intro analysis locally. Also new content is most likely to be consumed within a few days. So nice to have it local.
So if I download something that's 3 years old, it may have an Access, Change, and Birth date of today, but the Modify date is 3 years ago. It's keeping the Usenet upload date.
rclone looks at the Modify date, which is more than 4 days ago, and decides to move it (as expected), even though it's only been on my drive for less than a day.
So just wondering if others have bumped up against this and how they handle it.
Leaving solution for anyone searching in the future.
The issue is how download clients typically handle archives. When unpacking they will preserve the original Modified date.
In my case the client was nzbget. They provide an extension script in the docs for exactly this purpose. Can be added /scripts in your nzbget directory and can run it on all new downloads from Settings > Extension Scripts.
Now it will add today's date to all new downloads after the unpack.
You could also add a post-processing script to Sonarr to touch the files and do the same thing, although I didn't try that.
SabNZBd has a setting under the "Special" menu in the settings too called "ignore_unrar_dates" which does the same thing.
"Normally unpacked files will get the date/time stamp they have in the archive. If you set this option, the files will get the date/time of unpacking."
In case anybody is wondering (edit: it's disabled by default)