Daylight Savings Snafu?

[jlpoolen]

Preface: I have a Reolink RLC-420 which had an incorrect setting for the "set-back" time for Daylight savings time, the time was set back Oct 31st when it should have been set back on November 6th. I was unaware of the incorrect setting until the filing of this issue. This is disclosed to avoid confusion when looking at screenshots herein.

On Sunday morning, November 6th (after Daylight Savings set back earlier in the day), I was reviewing Saturday, November 5th, recordings. I had found a recording of interest which Reolink's software captured at 2:05 AM:

I use Moonfire-nvr to retrieve a full snapshot since Reolink's start and end time of snippets is invariably insufficient. So I went to the Moonfire-nvr web interface to get a better snapshot of the event occurring at Saturday, 11/5 at 2:04 AM PDT. I had performed a refresh of the web page as I usually do when I start a session to review recordings.

What is strange is that I specified a start and stop time of approximately 1 hour (1:05 - 2:06), yet 3 hours worth of video appear. I took screenshots of each of the three videos shortly after they commenced running and aligned the screenshots with the table entries.

To Reproduce Steps to reproduce the behavior:

1. Go to Moonfire-nvr portal
2. Set start and end times, 1 hour apart
3. See 3 hours worth of videos when there should only be one.

Expected behavior A table of videos which total approximately 1 hour.

Server (please complete the following information):

• If using Docker: not using Docker
• If building from git:

  jlpoole@pi:/usr/local/src/moonfire-nvr $ git describe --dirty
  v0.7.4-3-gfd7438d-dirty
  jlpoole@pi:/usr/local/src/moonfire-nvr $

  
  jlpoole@pi:/usr/local/src/moonfire-nvr $ date; moonfire-nvr --version
  Sun 06 Nov 2022 09:13:24 AM PST
  moonfire-nvr 0.7.4
  jlpoole@pi:/usr/local/src/moonfire-nvr $

  - Attach a [log file] -- I can stop and provide a log file if requests.

**Camera (please complete the following information):**
![Reolink_Client_2022-11-06_08-47-32](https://user-images.githubusercontent.com/227313/200183549-9cc0123b-3c1e-4f2b-9a0a-33f565f3029c.png)

**Desktop (please complete the following information):**
 - OS: Windows 7
 - Browser: Firefox 
 - Version: 106.0.2 (64-bit) (needs to be updated)

**Additional context**

Running Moonfire-nvr on Raspberry Pi 4: jlpoole@pi:~ $ date; uname -a Sun 06 Nov 2022 08:53:56 AM PST Linux pi 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l GNU/Linux jlpoole@pi:~ $

jlpoole@pi:/usr/local/src/moonfire-nvr $ git log -1 commit fd7438dd2818469820547165a505519ebeadba58 (HEAD -> master, origin/master, origin/HEAD, show-current) Author: Scott Lamb slamb@slamb.org Date: Wed Apr 13 21:45:45 2022 -0700

ignore port number in ws origin check

Fixes #219

The date on the Raspberry Pi is correct for my timezone:

jlpoole@pi:/usr/local/src/moonfire-nvr $

date Sun 06 Nov 2022 09:07:59 AM PST jlpoole@pi:/usr/local/src/moonfire-nvr $

[jlpoolen]

Here's a further twist, when I tried to specify a ~2 minute segment starting at 01:05, what is displayed is 00:05

Perhaps this is a browser cache issue or something happening on the JavaScript side? I'll restart Firefox and attempt again.

[scottlamb]

I'm on my phone right now and can't look closely, but it wouldn't surprise me to learn we have a time zone bug in the UI layer. The JavaScript time libraries available are really sketchy wrt time zone changes unfortunately.

[jlpoolen]

Interesting, when I tried to focus on a 2 minute segment which should be at 1:05 AM PDT, Saturday 11/5, I entered a start time of 01:05:50 and an end time of 01:06:36. What is displayed on the table are my specified times.

So, I appear to be off 1 hour based on the timestampe burned into the video. I therefore try to compensate, and change my "01:" to "02:" on both start and end times. What is then displayed in the table are values of 03 instead of 02.

Then I tried just changing the start time to "01:" so I have specified 1 hour + 1 minute, and then three table entries appear offering just over 2 hours instead of the expected 1 hour. If I click the 2nd table entry, I can then access the video I want with the burned-in time of "01:05".

So, I'm almost at a "it works for me" work-around, the problem I still face is I like to be able to view a video, set my start and end times based upon what I actually want to preserve. In this case, I can display the video, but it is in a huge segment, e.g. ~ 1 hour. I want to be able to save only a 46 second section. I tried the Max Video settings, but found there to be a 1 hour minimum.

What would be helpful for me is the ability to extract a 0 minute 46 second video starting at the burned-in time of 1:05:50. (Documents a guy hopping a fence to avoid detection of the security lights.)

[scottlamb]

I'm at a computer now and see the same broken behavior on fall back day.

Fortunately the backend's time handling is solid. If I needed that clip right now, I would go to the video clip with the correct start time and save the URL via the browser's context menu. E.g., clicking here in Chrome:

and ending up with e.g. https://nvr.home.slamb.org/api/cameras/225c6eeb-9f77-4ddf-ab8e-b5788642fa3c/main/view.mp4?s=2706893-2706958.3968834-354968834&ts=false in the clipboard. Then I'd compare to the API documentation for view.mp4. Look at the part after the . here. It says it starts at 3,968,834 90,000ths after the start of segment 2,706,893 and continues until 354,968,834 90,000ths of a second after the start of that same segment. If I wanted the clip to only be 46 seconds long, I'd take that first number (3,968,834), add 46 * 90,000 (getting 8,108,834), change the second number to that, resulting in the new URL https://nvr.home.slamb.org/api/cameras/225c6eeb-9f77-4ddf-ab8e-b5788642fa3c/main/view.mp4?s=2706893-2706958.3968834-8108834&ts=false. I'd paste that into the URL bar and save the clip.

[jlpoolen]

Thank you, Scott. Yes, it looks like the video is there, just having a problem getting it accessible through the web browser.

I'm having problems following your instructions. I tried with Firefox, but could not get a precision timecode, e.g. the 90k number ("90k Precision") following a decimal point, so I tried with Chrome and cannot discern what you mean by the "browser's context menu". When I try copying the the Video Address, I do not get the 90k Precision. Here's what goes into my clipboard when I Copy Video Address from Chrome:

http://pi:8080/api/cameras/f7689025-966d-4ca7-b045-5470ca33f6bf/main/view.mp4?s=421652-421708&ts=false

Now, I do see a listing via this URL: http://pi:8080/api/cameras/f7689025-966d-4ca7-b045-5470ca33f6bf/main/recordings

So, I thought perhaps I might find the video file using the criteria of 421652, but no luck:

Could the fact that I am using a version of Moonfire-nvr as of April rather than the current high watermark be what is causing my URLs not to have high precision 90k seconds? I've been reticent to upgrade until I know I can commit a couple of hours or 1/2 day of potential downtime. (We have a lot happening in Penny Lane camera coverage (5 cameras), including a Lady Godiva bicyclist who mooned the cameras in protest. The story that is evolving about The Midnight Gardener, the person my cameras have been documenting as as possible suspect for theft, is becoming legend within our historic district and beyond.)

[scottlamb]

The URL http://pi:8080/api/cameras/f7689025-966d-4ca7-b045-5470ca33f6bf/main/view.mp4?s=421652-421708&ts=false goes from the exact beginning of segment 421652 to the exact end of segment 421708. If you want it to go for e.g. 1 second, you can append a .-90000 to the s parameter (http://pi:8080/api/cameras/f7689025-966d-4ca7-b045-5470ca33f6bf/main/view.mp4?s=421652-421708.-90000&ts=false) and it should do so.

Could the fact that I am using a version of Moonfire-nvr as of April rather than the current high watermark be what is causing my URLs not to have high precision 90k seconds?

The URL format hasn't changed in a while. It's just about the clip you're starting from. I selected a specific start time that was in the middle of a recording, so mine had a .blah-blah already.

[scottlamb]

Oh, here's an alternate workaround that may be easier: restart Moonfire with the environment variable TZ set to a time zone that doesn't do daylight saving time, e.g. TZ=UTC. [Edit: and refresh the browser window.] No messing with URLs then.

[jlpoolen]

Just to pin this down, I successfully accessed the 56 second segment I wanted by:

1) calculating 90,000 times the number of seconds I wanted. I chose 56 for a product of: 5040000 2) inserted after the second number of the URL, i.e. 421708, a "." plus a minus "-" followed by the product: 5040000.

So my url becomes: http://pi:8080/api/cameras/f7689025-966d-4ca7-b045-5470ca33f6bf/main/view.mp4?s=421652-421708.-5040000&ts=false

You're modify the URL by inserting a dot followed by a negative number.

Thank you, Scott.

[jlpoolen]

Oh, here's an alternate workaround that may be easier: restart Moonfire with the environment variable TZ set to a time zone that doesn't do daylight saving time, e.g. TZ=UTC. [Edit: and refresh the browser window.] No messing with URLs then.

The downside is that if you are sharing the site with people not familiar with timezone differences, this could confuse them. I share my site with people who are not technically inclined, so keeping the time to Pacific Time removes an obstacle.

[scottlamb]

Glad you got what you needed for now.

I'd love to fix this properly, even to the level of having a date time chooser that lets you disambiguate the fall back hour (2am to 3am correction: 1am to 2am) in a slick way. It's not easy right now though with the typically used libraries. The JS Temporal API being standardized now will provide a firmer foundation at least. Even then though I don't know if the mui folks (whose datetime picker component I'm using) care about this level of detail. Before the latest UI rewrite, I did have a way you could type a zone offset into the time text box. Maybe it wouldn't be too hard to reintroduce that.