timestamp on thumbnail title is +1 hour

[BETLOG]

The timestamp on the thumbnail title is always +1 hour compared to system time.

%Y-%M-%D--%h-%m-%s.%u [%k/20] %a

Raspbian GNU/Linux 10 (buster)
5.10.103+ #1529 Tue Mar 8 12:19:18 GMT 2022 armv6l GNU/Linux
RPi Cam Control v6.6.13

Kubuntu 23.10
6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Chrome 119.0.6045.199

[BETLOG]

Lol. I was just thinking: "After seeing this for years I should probably report this"... and I already have.

[roberttidey]

The annotation time stamp is derived from a localtime call which obeys the local time zone setting.

I did test a long time ago and it worked OK then.

What time zone settings do you have on your base raspberry?

[BETLOG]

$ timedatectl
               Local time: Tue 2024-01-30 23:53:29 AEST
           Universal time: Tue 2024-01-30 13:53:29 UTC
                 RTC time: n/a
                Time zone: Australia/Brisbane (AEST, +1000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

It's suspiciously similar to the way sometimes daylight savings gets applied in error to areas that don't do D.L.S. except afaik RPiCWI does it all the time.

even after :

$ sudo dpkg-reconfigure tzdata

Current default time zone: 'Australia/Brisbane'
Local time is now:      Tue Jan 30 23:58:10 AEST 2024.
Universal Time is now:  Tue Jan 30 13:58:10 UTC 2024.

Recording an image shows INcorrect descriptive text, and correct on-image annotation.

[roberttidey]

Can you clarify that last sentence. I'm not sure what you mean.

I'll test that specific time zone when I get a chance.

Edit. It is possible the time library being used to compile RPiCamWeb is behaving differently and not accounting for any changes to DST policies in that region.

[BETLOG]

clarify

When i click 'record image' i get the same incorrect result as motion initiated video. ie: the image overlay shows correct timestamp, but the html GUI incorrectly shows +1 hour.
(basically i was just describing the method i used to confirm that sudo dpkg-reconfigure tzdata didnt have any effect either.)

It is possible the time library

Seems most likely.

[BETLOG]

@roberttidey
...wait.... is the title derived from the filename, or the datetimemodified timestamp?
I've been having issues with files not being converted to mp4 recently, and after manually doing 'sudo /var/www/html/macros/startstopX.sh start' i see that all of the newly created mp4 titles' timestamps are wildly incorrect, and recent.

Shouldn't the title be based on the filename if the filename is already derived from the creation datetimestamp?

[roberttidey]

When a recording is started (or a still image triggered) then the software creates a filename based on the current time using the naming template c_video_path in the config file. This name is used to both name the thumbnail and the video recording files.

The date-time is when the process is started. If buffering is used then there will be video data from before this time and obviously the file itself is only closed when the recording finally terminates.

The title you see on the web pages are effectively the thumbnail name (and therefore also the recording name.

If you have changed the naming template then you could get date-timestamps in a different format.

[BETLOG]

software creates a filename based on the current time
are effectively the thumbnail name (and therefore also the recording name.

ok good, thats what I assumed.

If you have changed the naming template

well yes, but not really:

$ cat /var/www/html/uconfig 
annotation %Y-%M-%D--%h-%m-%s.%u [%k/25] %a
anno_background 1
anno_text_size 14
metering_mode matrix
exposure_mode auto
white_balance auto
raw_layer 0
width 1024
quality 13
video_width 1296
video_height 972
video_fps 25
video_buffer 3000
video_split 300
MP4Box 2
MP4Box_fps 25
image_width 1296
image_height 972
image_quality 13
image_path /var/www/html/media/%Y-%M-%D--%h-%m-%s.jpg
lapse_path /var/www/html/media/%Y-%M-%D--%h-%m-%s.%u.jpg
video_path /var/www/html/media/%Y-%M-%D--%h-%m-%s.mp4
motion_external 0
motion_threshold 125
motion_image /var/www/html/motionMask-1296x972.pgm
motion_stopframes 300
initial_quant 18
encode_qp 18

I guess I'm just still befuddled as to how the web interface thumbnail information can - at random - differ from the filename, annotation, and actual time of recording.
I mean, I do use en_ZA for its datetime formatting, but en_AU otherwise because thats where i live.. The system clock is correct and nothing else I have looked into gives a bad datetime stamp.... but looking at a RPiCWI page I never know if a preview shows the right time or not until I mouseover or open the video and actually check.

pi@pizerocam3:~ $ locale
LANG=en_AU.UTF-8
LANGUAGE=
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC=en_AU.UTF-8
LC_TIME=en_ZA.UTF-8
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY=en_AU.UTF-8
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER=en_AU.UTF-8
LC_NAME=en_AU.UTF-8
LC_ADDRESS=en_AU.UTF-8
LC_TELEPHONE=en_AU.UTF-8
LC_MEASUREMENT=en_AU.UTF-8
LC_IDENTIFICATION=en_AU.UTF-8
LC_ALL=

pi@pizerocam3:~ $ date
Tue Jun 11 20:24:46 AEST 2024
(which is correct)

[roberttidey]

There is no separate database for this info. Everything is derived from the thumbnail name. So at the moment I to am confused about what is happening.

If you could possibly zip up and post a short recording + thumbnail and a screenshot of web screen where it seems out of whack, then I will check further.

[BETLOG]

Next time I notice such a case I will append it here. Thanks.