KoenZomers / RingRecordingDownload

Console Application for Windows, Raspberry Pi, Linux and macOS which allows for downloading of Ring recorded events
Apache License 2.0
20 stars 9 forks source link

Behavior of LastdownloadedRecordingId and resumefromlastdownload #27

Open abulsme opened 1 month ago

abulsme commented 1 month ago

Moving discussion from the "Download Fails after some time" thread:

FirstRunRingVerbose3.txt

Another question while I have you here... Notice on my run for all of May it starts at May 31st, then goes back in time, eventually getting to midway through May 29th before failing.

If I now were to use the -resumefromlastdownload option, where would it start from? It seems like if in situations like this it would always start from the OLDEST video and move toward the newest, then this would have a clear result. After a failure it would pick up where it left off and continue marching toward the present. But since it starts at the newest and works back, if it really started with the last successful, then it would just repeat the part of the 29th it already had, then repeat the 30th and 31st, never realizing it has missed most of that month. Or does it use the date of the most recent video, but only if it had successfully completed every video in the batch? So in this case, since my last fully successful command was the one where I got April 30th, it would just go with everything May 1st and beyond?

Checking the config file, in this case it has:

So neither of the options I mentioned above. Instead this corresponds to the very first video it downloaded in the May batch, which was the last video on May 31st, so looks like if I tried resume, it would start working on June through the present, and never realize it had in fact missed lots of videos in May.

Because of this when I had automation going in the past, I'd have it run very frequently (hourly) with the resumefromlastdownload flag, so it would be harder for it to get interrupted and miss anything.

Seems like to be more robust in this situation you'd want to start with the oldest video and work your way forward in time rather than the other way around. That way if you fail, you just pick up where you left off next time. (Another possibility, having an option to just tell it to grab any video you don't already have in your destination folder, optionally subject to start and end time constraints.)

(I also ran a separate copy for each camera, so it would keep track of the last downloaded separately for each one.)

Sorry to diverge to something separate, this probably should be its own thread. But watching the failures here made me think of this again. Even if this issue gets fixed completely, there are all sorts of reasons you could fail mid-download (server reboots, internet connection goes down, etc) so being able to pick up again from the right spot ends up being important.

Thanks for all your help here!

danespinosa commented 1 month ago

Hi @abulsme i'll look into this next week of 8/12/2024