roleoroleo / yi-hack-Allwinner-v2

Custom firmware for Yi 1080p camera based on Allwinner platform
MIT License
846 stars 96 forks source link

Date / Time Problem #246

Closed SmartM-ui closed 4 months ago

SmartM-ui commented 3 years ago

Hi, By leaving the timezone setting blank, the date in the event records have the correct date (real time 00.56 - Time reported: 00:56):

Schermata 2021-09-03 alle 01 06 49

but the local time is two hours behind (real time sep 03 01:02:23 - time reported: sep 02 23:02:23

Schermata 2021-09-03 alle 01 02 31

and also in the motion_files (see the end date) it is two hours behind (Real Time: 03.09.2021 00:58:22 - Time Reported: 2021.09.02 22:57:12)

Schermata 2021-09-03 alle 01 04 10

If I set the timezone with the Italian value, the date in the event log is two hours ahead.

How should I set the value for the timezone to have a synchronization of all dates / times?

Thanks

roleoroleo commented 3 years ago

How did you set timezone in the yi app?

SmartM-ui commented 3 years ago

How did you set timezone in the yi app?

Hi @roleoroleo

timezone in YIhome: UTC +1:00

roleoroleo commented 3 years ago

Plase, try to set timezone = GMT in the app. Check this post: https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/203#issuecomment-918762012

SmartM-ui commented 3 years ago

Plase, try to set timezone = GMT in the app. Check this post: #203 (comment)

Perfect. I didn't set the same value, but I set UTC +0 in the YIHome app and set the correct timezone to YI-HACK. Now the time is correct everywhere

roleoroleo commented 3 years ago

The name should be "Coordinated universal time".

SmartM-ui commented 3 years ago

The name should be "Coordinated universal time".

That's right, I set Coordinated universal time! Thanks

Jon8RFC commented 2 years ago

@roleoroleo Am I missing a step? I'm getting confused because it's not working as expected... Yi Home 1080p IFUS 9.0.36.02_202105081647 y211ga

UPDATE: Is this part something on the Yi-Hack side that could be updated, or something with Yi's firmware, which can't be touched? https://forum.filezilla-project.org/viewtopic.php?t=48775 https://forum.filezilla-project.org/viewtopic.php?t=37273#p136743 I see a few threads about servers not handling MDTM correctly.

Even if I disable NTPD, times don't seem to match up, universally. There seem to be different variables. For example, if the time is December 4, 2021 23:05:00 (GMT-6) and I've set the following and then rebooted: Yi-Hack: CST6CDT,M3.2.0,M11.1.0 Yi-Hack NTPD: disabled Yi app: Coordinated universal time

I'm rounding off numbers and keeping them consistent after observing the changes, for simplicity in showing the issue... Bolded are changes. I'm sorry for the wall of text, but I wanted you to see what changes.

My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes, not read/write) modified time shows "12/4/2021 17:05:00" (6 hours behind)

Now, if I remove the timezone set in Yi-Hack configuration page, save, power cycle completely (not a soft reboot): My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sun Dec 5 05:05:00 GMT 2021" (6 hours ahead) Recording folder being recorded to is "2021Y12M05D05H" (6 hours ahead) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 23:05:00" (correct)

Now, if I change the Yi app timezone to UTC-06:00, power cycle, nothing seems to change.

Now, if I change the Yi-Hack timezone to CST6CDT,M3.2.0,M11.1.0, save, power cycle: My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 17:05:00" (6 hours behind)

Now, if I "Disable Cloud", "Enable Recording without Cloud", "Enable NTPD", save, power cycle: My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 18:05:00" (5 hours behind)

Now, if I change the Yi app timezone to Coordinated universal time, power cycle, nothing changes.

Now, if I re-enable "Cloud" (keeping NTPD enabled), save, power cycle: My computer shows "December 4, 2021 23:05:00" (correct) Yi-Hack web status shows "Sat Dec 4 23:05:00 CST 2021" (correct) Recording folder being recorded to is "2021Y12M04D23H" (correct) Filezilla client to Yi-Hack FTP recorded file (dynamically changes) modified time shows "12/4/2021 18:05:00" (6 hours behind)

canuckray commented 2 years ago

@roleoroleo , I am also having issues with timestamp / time zone on my Yi 1080 Home.

BUT.... the issue only presents itself on the date/timestamp overlay that is overlaid on the rtsp stream.

My setup is:

The result:

Yi Hack web reports the local time correctly - 10:14am (I am GMT-4, so GMT would be 2:14pm) However, the timestamp overlay on the rtsp stream shows 8 hours ahead! It's as if it has added 4 hours to GMT, rather than subtracted 4 hours. (it is showing 18:14, as shown below).

I have tried different combinations of Yi time zone, NTP on/off, Yi Hack time zone, and cannot get these to agree.

image

roleoroleo commented 2 years ago

Your problem is different because is related to the overlay. And I don't know hot to solve it because it depends on the yi firmware.

But check if the "rmm" process has the correct environment variables. Login with ssh. Find the process id: ps | grep rmm Check the environment: cat /proc/<PID>/environ

canuckray commented 2 years ago

Thanks for the quick reply - appreciate it. The output is below. Looks cryptic to me, but maybe something will jump out at you.

image

roleoroleo commented 2 years ago

TZ variable is absent. This is not ok. What is yout timezone setting in the web interface?

canuckray commented 2 years ago

pasted from web interface: EST5EDT,M3.2.0,M11.1.0 (this is the America / Toronto TZ string)

image

roleoroleo commented 2 years ago

I checked the script and I can't understand. Try another command: cat /proc/PID/environ | tr '\0' '\n'

canuckray commented 2 years ago

image

SeriousPat commented 2 years ago

di you fix it? i habe UTC-0 in Yi app. my timestamp up left in the video is incorret.

image

image

image

when i enable cloud feature. the time is correct.

roleoroleo commented 2 years ago

I don't know how to fix it, at the moment.

ghost commented 2 years ago

FWIW I found using the setting GMT in the Yi app and TZ in Yi-Hack breaks the seek time in the Yi android app when trying to playback video. For those using RTSP and personal recorders I guess it doesn't matter but I ended up changing both yi app and yi hack to the proper timezone and only applying the timezone inline where needed in system.sh. For example with httpd, although others might be added.

export TZ=$(get_config TIMEZONE)
if [[ $(get_config HTTPD) == "yes" ]] ; then
    mkdir -p /tmp/sd/record
    mkdir -p /tmp/sd/yi-hack/www/record
    mount --bind /tmp/sd/record /tmp/sd/yi-hack/www/record
    httpd -p $HTTPD_PORT -h $YI_HACK_PREFIX/www/ -c /tmp/httpd.conf
fi
# maybe some other apps here too
export -n TZ

But what works for me might not work for others and I don't know if Yi use daylight savings, maybe someone with daylight savings can shed some light? :)

Example with above and +7hrs set for both Yi Hack (where needed) and the Yi app. The r30gb needs a workaround but the other camera's b091qp/h60ga seem fine.

5

roleoroleo commented 2 years ago

I wanted to try to do the opposite: run rmm without TZ. But probably your solution is better.

ghost commented 2 years ago

To be clear rmm doesn't have the 'TZ' variable set and the yi-app time zone doesn't set the TZ variable but applies an offset as was commented here https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/203#issuecomment-920509721

roleoroleo commented 2 years ago

@SeriousPat Try this system.sh (overwrite the original one). Set your timezone in the app (instead of UTC) and in the web gui. Reboot and check:

system.tar.gz

roleoroleo commented 2 years ago

What about the date/time of the table in the "Events" page. Is it ok? Or is it shifted by an offset? I changed the system.sh and I reconfigured the correct time in the app. Now, the time of the events is not ok.

ghost commented 2 years ago

Not sure who you are asking, if it's me then my event page is fine. Don't use MQTT, CRON and SSH seems to do it's own thing with time, as I said before I'm a noob with Linux and not that much better with Windows so don't know.

TBH just telnet/ssh and ftp would be enough for me with these camera's but it's nice to learn so I try a few things. Even learning a little arm and wrote a test grabber with piped aac and video streams from fshare. Audio was a bit hit and miss with my modification to rtsp_server_yi, the newer one you submitted works better than my attempt. Not sure what to do with videofile.cpp to get the 265 working, all those brackets and semi colons do my head in. :/

roleoroleo commented 2 years ago

Not sure what to do with videofile.cpp to get the 265 working, all those brackets and semi colons do my head in. :/

Check the last commit: https://github.com/roleoroleo/RtspServer/tree/yi

ghost commented 2 years ago

Forgot to mention I'm not using ONVIF either and RTSP is being used for learning purposes, no dedicated box for it's use. Cloud is enabled but no cloud storage.

Check the last commit: https://github.com/roleoroleo/RtspServer/tree/yi

Cool, will try it out later today. Will start another thread under discussions.

kalyan02 commented 2 years ago

Thanks for the excellent software. Its magical to be able to ssh and play around into the camera.

Am facing similar date time problems.

I moved the export TZ to just before the rmm is executed, this seems to fix the folder label. However the overlay on top left is still 8 hours behind.

FYI: I am not using Yi App at all and all cloud features are disabled. Is there anyway to modify the firmware timezone offset? I am looking through #203 . Any tips?

roleoroleo commented 2 years ago

I don't know how to set the internal timezone (I mean the same that the app changes) without using the app. You should configre the app just for the time to set the cam.

rikrdo89 commented 1 year ago

I'm having the same issue. The timestamp on the rtsp feed is off by 5hrs, whenever I disable cloud. I have the yi app set to UTC. If I set the timezone to EST (which should subtract 5 hrs from UTC), it adds 5 hours more to the timestamp, so it shows a time that is 10hrs ahead. I tried multiple combinations of turning off ntdp, timezones, reboot cycles, but the timestamp seems to be always off unless I don't disable cloud.

roleoroleo commented 1 year ago

Is your TZ positive or negative?

rikrdo89 commented 1 year ago

It's supposed to be negative... my TZ is EST5 (Eastern time, which UTC - 5 hr)

roleoroleo commented 1 year ago

Try to overwrite 2 files contained inside this archive: patch.tar.gz

/tmp/sd/yi-hack/bin/set_tz_offset /tmp/sd/yi-hack/script/system.sh

rikrdo89 commented 1 year ago

Thanks a lot, I'll try that. Do I just ssh into the cam and overwrite those files, and reboot?, or Do I turn off the cam, take the micro sd and change the files in my computer, and then power on the cam?

roleoroleo commented 1 year ago

As you prefer. Normally I use ftp. No need to change permissions because the file system is a fat32. A reboot is required.

canuckray commented 1 year ago

I can confirm that these 2 files corrects the issue! Beautiful!

Thanks @roleoroleo .... greatly appreciated!

rikrdo89 commented 1 year ago

the patch works!!! Thanks a lot @roleoroleo, no more incorrect timestamp!

itkfilelor commented 1 year ago

Sadly, the system.sh file crashes both of my cameras on the current F/W (0.2.5) (model: y211ga) Back to normal on one my TZ is -5 but the camera stamp is showing +5. I can't reach the other camera atm to reset it and verify it is the same.

roleoroleo commented 1 year ago

Pay attention when you copy the file to the cam. The file must be in linux format (LF line termination).

itkfilelor commented 1 year ago

Pay attention when you copy the file to the cam. The file must be in linux format (LF line termination).

That should be easy since my daily is PopOs 😊 When it failed I also opened it up in VSCode to see what's up and I saw all \n no \r

roleoroleo commented 1 year ago

Please, check this commit: https://github.com/roleoroleo/yi-hack-Allwinner-v2/commit/4db939ee69d7b134313dd2610be2b71cc328bf32

itkfilelor commented 1 year ago

Please, check this commit: 4db939e

Just applied, if it fails, I only have 1 more shot til much later. At work right now. 😊 Technology is great.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

chrbar11 commented 1 year ago

FWIW I found using the setting GMT in the Yi app and TZ in Yi-Hack breaks the seek time in the Yi android app when trying to playback video. For those using RTSP and personal recorders I guess it doesn't matter but I ended up changing both yi app and yi hack to the proper timezone and only applying the timezone inline where needed in system.sh. For example with httpd, although others might be added.

Hello former user (@ghost) who wrote this post, did you obtain this result when Cloud was disable? I meet trouble to set the good timezone for the built-in YI timestamp (time OSD) in the upper left (#606). Do you have any idea how to set timezone about built-in Yi timestamp (time OSD) in the upper left?

chuckheron commented 1 year ago

Hi, I applied the patch, but as soon as I set TIMEZONE to anything, the camera wouldn't boot.

I was trying the TZP_SET calculation in /bin/sh, and I kept getting a 'bad substitution' with the ${TZP:0:1} syntax.

I got it to work using sed: TZP_SET=$(echo $TZP | sed 's/\(.\)/\1 /g' | awk '{ print ($1($2$3)*3600+($4$5)*60) }')

My camera boots now and the times seem to be correct.

Sadly, it's not doing motion detection anymore though, but that's probably a different issue.

Thanks -chuck

roleoroleo commented 1 year ago

I was trying the TZP_SET calculation in /bin/sh, and I kept getting a 'bad substitution' with the ${TZP:0:1} syntax.

This is strange. What happens if you run the following commands?

root@yi-hack:~# export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3
root@yi-hack:~# export TZP=$(TZ=$TIMEZONE date +%z)
root@yi-hack:~# export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$2*3600+$3*60) }')
root@yi-hack:~# echo $TZP_SET
chuckheron commented 1 year ago

Hi,

/bin/sh sh$ export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3 sh$ export TZP=$(TZ=$TIMEZONE date +%z) sh$ export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$23600+$360) }') sh: 3: Bad substitution sh$ echo $TZP_SET

sh$

That syntax seems to work in bash, not sh though.

/bin/bash bash$ export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3 bash$ export TZP=$(TZ=$TIMEZONE date +%z) bash$ export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ( $1$23600+$360) }') bash$ echo $TZP_SET +7200 bash$

Thanks -chuck

On Thursday, June 22, 2023 at 10:46:01 PM PDT, roleo @.***> wrote:

   I was trying the TZP_SET calculation in /bin/sh, and I kept getting a 'bad substitution' with the ${TZP:0:1} syntax.

This is strange. What happens if you run the followin commands? @.:~# export TIMEZONE=CET-1CEST,M3.5.0,M10.5.0/3 @.:~# export TZP=$(TZ=$TIMEZONE date +%z) @.:~# export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$23600+$360) }') @.:~# echo $TZP_SET

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

roleoroleo commented 1 year ago

Sorry bu I don't understand, inside the cam sh and bash are symbolic links to ash. Where are you running, these commands?

chuckheron commented 1 year ago

Hi Yes, sorry, I was running them on a linux machine, I tried it on the camera there is no error.
Now I'm not sure why the camera wasn't booting with that code in there. It's working now..

Thanks -chuck

sirduke989 commented 1 year ago

Try to overwrite 2 files contained inside this archive: patch.tar.gz

/tmp/sd/yi-hack/bin/set_tz_offset /tmp/sd/yi-hack/script/system.sh

I can confirm that the set_tz_offset in this patch fixes the OSD timestamp for a negative tz offset (CST/CDT) but does not appear to be included in the latest version (0.2.9). I tested this on RFUS both Indoor (y211ga) and Outdoor (h30ga) cameras running version 0.2.9. Note: I did not need to replace system.sh.

To get this to work:

  1. I re-enabled cloud integration and rebooted
  2. I set to timezone to Coordinated universal time in the Yi-Home app
  3. I disabled cloud integration, set the correct timezone and enabled time OSD in Yi-Hack
  4. Rebooted (Offset was still positive, IE +5 instead of -5)
  5. I replaced set_tz_offset from the patch on the camera
  6. Rebooted (now the OSD timestamp is displaying correctly)
roleoroleo commented 1 year ago

This is weird. I included the fixes in the master branch and tested again in this moment. It works with my h52ga (0.2.9) using "CST6CDT,M3.2.0,M11.1.0".

Please run the commands in this post, using your timezone and check the output.

sirduke989 commented 1 year ago

@roleoroleo I actually did try those commands prior to replacing set_tz_offset on 0.2.7 and 0.2.9 and it always gave the correct offset for me of -18000. This lead me to think that the issue was with set_tz_offset and not system.sh. I should have included this in my last post but I am also using "CST6CDT,M3.2.0,M11.1.0" as my Timezone in the UI.

Here are the commands ran on one of my cameras: root@yicamout:~# export TIMEZONE=CST6CDT,M3.2.0,M11.1.0 root@yicamout:~# export TZP=$(TZ=$TIMEZONE date +%z) root@yicamout:~# export TZP_SET=$(echo ${TZP:0:1} ${TZP:1:2} ${TZP:3:2} | awk '{ print ($1$23600+$360) }') root@yicamout:~# echo $TZP_SET -18000

I did some more testing and tried replacing set_tz_offset from different patches on one of my RFUS cameras running y211ga 0.2.9 and below are the resulting OSD: From patch.tar.gz: OSD is UTC-5 (correct) y211ga (0.2.9): OSD is UTC+5 h52ga (0.2.9): OSD is UTC+5 y211ga (0.2.7): OSD is UTC+5 y211ga (0.2.6): OSD is UTC-5 (correct) y211ga (0.2.5): OSD is UTC-5 (correct) y211ga (0.2.4): OSD is UTC-5 (correct)

roleoroleo commented 1 year ago

Ok, the last try: set_tz_offset writes 4 bytes to the file /tmp/mmap.info You can check if it writes properly reading the file: hexdump -C -s 0x04e0 -n 4 /tmp/mmap.info

The offset depends on the model and it's in the following table:

    { 0x4a0, 1 },    // Y20GA_9
    { 0x4a4, 1 },    // Y20GA_12
    { 0x4a0, 1 },    // Y25GA
    { 0x4a0, 1 },    // Y30QA

    { 0x4e0, 1 },    // H30GA_9
    { 0x56c, 0 },    // H30GA_11     Already present
    { 0x4e0, 1 },    // H51GA
    { 0x4e0, 1 },    // H52GA
    { 0x560, 0 },    // H60GA        Already present
    { 0x4e0, 1 },    // Q321BR_LSX
    { 0x4e0, 1 },    // QG311R
    { 0x4e0, 1 },    // R30GB
    { 0x56c, 0 },    // R35GB        Already present
    { 0x560, 0 },    // R40GA        Already present
    { 0x4e0, 1 },    // Y211GA_9
    { 0x570, 0 },    // Y211GA_12    Already present
    { 0x4e0, 1 },    // Y21GA_9
    { 0x564, 0 },    // Y21GA_12     Already present
    { 0x4e0, 1 },    // Y28GA
    { 0x56c, 0 },    // Y291GA_9     Already present
    { 0x570, 0 },    // Y291GA_12    Already present
    { 0x4e0, 1 },    // Y29GA
    { 0x000, 0 }     // B091QP       0x560 or 0x56c but already present

Try to run set_tz_offset and check if the number is ok. For example:

root@yi-hack-h52ga:~# set_tz_offset -c tz_offset_osd -m h52ga -f 9 -v -18000
root@yi-hack-h52ga:~# hexdump -C -s 0x04e0 -n 4 /tmp/mmap.info
000004e0  b0 b9 ff ff                                       |....|
000004e4