Timecode frame number must be positive and greater than zero.

[s17534]

Hi, I'm using dvr-scan to scan files from my web camera to detect motion.

When using stable version, I'm able to successfully scan all of them - meaning no errors while scanning.

But if I use v1.5.dev1, following error occurs very often:

ERROR: controller.run_dvr_scan(): Timecode frame number must be positive and greater than zero.

Attached screenshots for proof.

[Breakthrough]

Hi @s17534;

This may have been fixed in a recent commit:
758b2d6

This is likely due to the event end times being wrong which can happen when a motion event is exactly the number of frames specified by min-event-len (-l).

Would you be willing to test the latest version including that change? You can download a .whl file and use pip to install it:
https://ci.appveyor.com/api/buildjobs/k3mj7c7u2ih8ya0f/artifacts/dist%2Fdvr_scan-1.5.dev1-py3-none-any.whl

Edit: Latest version uploaded to pip now, install with pip install --pre --upgrade dvr-scan.

Thanks for the report.

[jimmyhsu]

Same exact issue, on windows 1.5 dev1 with CUDA MOG2 as the mode

This was from an earlier attempt as well, same area:

[jimmyhsu]

Hi @s17534;

This may have been fixed in a recent commit: 758b2d6

This is likely due to the event end times being wrong which can happen when a motion event is exactly the number of frames specified by min-event-len (-l).

Would you be willing to test the latest version including that change? You can download a .whl file and use pip to install it: https://ci.appveyor.com/api/buildjobs/k3mj7c7u2ih8ya0f/artifacts/dist%2Fdvr_scan-1.5.dev1-py3-none-any.whl

Thanks for the report.

Oh wow, perfect timing! Is there a windows build of this available with the CUDA MOG2 with appveyor?

I'm actually using this to help solve a crime that happened in the past couple days. Really love this tool! Saved me days of combing through massive amounts of footage.

[Breakthrough]

@jimmyhsu I'm still sorting out some issues with automating CUDA builds, and tried to build a regular one just now but something is broken. Given this is a hugely breaking bug, I'll get a CUDA build going right now and will upload it here. Would you be willing to test it out and let me know if it fixes the bug? Thanks.

P.S. Glad you're finding the tool useful and that it could be of help, feel free to provide any feedback anytime.

[jimmyhsu]

@Breakthrough absolutely! Really appreciate you doing this right now!

[Breakthrough]

@jimmyhsu Just finished uploading:
https://github.com/Breakthrough/DVR-Scan/releases/download/v1.5-beta/dvr_scan-372e87d1-cuda.zip
Edit: Officially released new version of the beta, download: dvr-scan-1.5.dev2-win64-cuda.zip

Note that the parameter is now called mog2_cuda instead of mog_cuda.

---

As to why this bug occured, the last_frames_above_threshold was only set on the next frame with motion, so I believe it was stuck at 0 (explaining why the end times were wrong in @s17534's second screenshot). This led to the duration becoming negative, since each event's end time would then be calculated as being in the past before the current event started.

This didn't crash in v1.4.1 due to differences in how the values were calculated (it was changed to support multithreading), but will result in the event end times being incorrect. Fortunately the video output isn't affected, just the text output, so the event start times + durations reported should still be accurate.

I noticed this when doing some refactoring to remove redundant calculations (as duration can always be derived from end_time - start_time), and upon inspection realized that last_frames_above_threshold wasn't set when a motion event begins. I didn't realize at the time the consequences of that though, so will need to also mark this as a known issue.

[jimmyhsu]

@Breakthrough thanks, testing it now! Will let you know if it runs into any issues.

Explanation makes a lot of sense as well, appreciate the detail!

[jimmyhsu]

@Breakthrough looks like it works and the timecodes are saved, but unfortunately the files with video were all saved with zero bytes

The command used was dvr-scan -i *.mp4 -d output -b mog2_cuda, not sure if this is a cuda issue or something different. If it helps, I'm using an EVGA 3080ti FTW3 to process these.

It appears to have only process one of the files as well

[jimmyhsu]

Actually, it looks like it just stitched all of the events together as if it was one video instead of breaking down the videos separately.

Interesting behavior, makes sense in a way though.

I'll retest with cnt and the stable version stitched into one video, as well overnight and will try running mode mog2 with ffmpeg again

[s17534]

Hi @s17534;

This may have been fixed in a recent commit: 758b2d6

This is likely due to the event end times being wrong which can happen when a motion event is exactly the number of frames specified by min-event-len (-l).

Would you be willing to test the latest version including that change? You can download a .whl file and use pip to install it: https://ci.appveyor.com/api/buildjobs/k3mj7c7u2ih8ya0f/artifacts/dist%2Fdvr_scan-1.5.dev1-py3-none-any.whl

Thanks for the report.

Hi, I've tested latest dvr-scan version linked by you and it properly scanned testing file
and also successfully written output file. So it seems bug is fixed. Thank you very much for this awesome software.

[Breakthrough]

@jimmyhsu thanks for verifying the fix. When specifying multiple input files, all generated output files use only the first filename as a prefix.

Actually, it looks like it just stitched all of the events together as if it was one video instead of breaking down the videos separately.

Motion events should only be stitched together if you are using the -o flag. Did this happen when you used the command dvr-scan -i *.mp4 -d output -b mog2_cuda?

Also note that the CUDA binaries only support MOG2/MOG2_CUDA and not CNT, but the actual method shouldn't affect any other program logic other than how events are detected. Thanks for testing this out!

---

@s17534 thanks for verifying the fix! :)

---

TODOs for next release before this is closed out:

• Document this as a known issue for the current beta release
• Document a known issue that end times are wrong in v1.4
• Re-release a new beta version (final release is planned for end of this month once code signing has been finalized)

[jimmyhsu]

@Breakthrough no problem, and yes it did stitch them together automatically, that was the exact command line used.

I used 1.4.1 with CNT overnight in parallel on a combined file and we've got their faces and the crime in action! Thanks for making this, it's saved so much time manually combing through all the footage by hand and will help everyone else affected.

We think we may actually be able to catch them as they were wearing and carrying very distinctive items (at minimum, we can claim the insurance 100%).

As an FYI, the second run with MOG2_CUDA still has an issue outputting 0 byte files, not sure what's going on there still.

[Breakthrough]

Glad it was able to help you out!

What you're describing re: the concatenation and 0-byte files is really strange, and I could definitely use your help with resolving that one. I've tried the same command just now and I get all events in separate files. Would you be able to provide debug logs (add --verbosity debug)? You don't need to scan the whole video, just letting it scan the first few frames should be sufficient.

A few more questions that might help debug this (all regarding v1.5):

1. Does the same thing happen in v1.5 when using CNT?
2. Did you see the correct output (one event per file) with v1.4?
3. Do the names of all the 0-byte files follow the correct format (NAME.DSME_0000.avi)?
4. What is the resulting name of the single video file that contains all the events?
5. Does the same thing happen when you only scan a single input video?

Since accuracy isn't important here, you can try setting --downscale-factor=3 to speed up the tests, and just need to run the commands long enough to reproduce the issue. If there's any other information you think might help me to reproduce the issue, please do mention it.

Thanks!

---

This is interesting as well since there should be no code paths that can actually lead to zero byte files anymore (each file created on demand when the first frame to write to it is received) [1]. The fact that you're also seeing concatenation happen is also quite troubling, since the only way that should happen is if -o is not specified [2]. I'm hoping the answers to the above questions can narrow the scope of the investigation a bit, since it's not clear how this is even possible.

[1] https://github.com/Breakthrough/DVR-Scan/blob/v1.5/dvr_scan/scanner.py#L949=
[2] https://github.com/Breakthrough/DVR-Scan/blob/v1.5/dvr_scan/scanner.py#L952=

[jimmyhsu]

@Breakthrough can do, I'll try to get to this either tomorrow or the day after—should this be in a different issue for clarity as it seems to be a totally different issue?

[Breakthrough]

@jimmyhsu yes please, separate issue would be great, thanks!

[Breakthrough]

Released new version of v1.5-beta (identifier is v1.5-dev2) with this fix, can grab the new version using pip now or from Github:
https://github.com/Breakthrough/DVR-Scan/releases/tag/v1.5-beta

[Breakthrough]

Thanks all for your help with this one. v1.5 has officially been released 🎉

@jimmyhsu would love to know if you still run into the issue with the final release of v1.5. I did some more testing and was not able to reproduce the issue, so hoping the issue has been resolved. (If not please do feel free to open a new issue!)