Showing correct time in OSD (snx_isp_ctl)

[Tommy032017]

I have the problem, that the time shown in the OSD is -2 h as compared to the time shown in the main web page of the hack.


I did following changes in 20-rtsp-server:

#!/bin/sh
PIDFILE="/var/run/rtsp-server.pid"

status()
{
  pid="$(cat "$PIDFILE" 2>/dev/null)"
  if [ "$pid" ]; then
    kill -0 "$pid" >/dev/null && echo "PID: $pid" || return 1
  fi
}

start()
{
  LOG=/dev/null
  echo "Starting RTSP server..."
  snx_rtsp_server -W 1920 -H 1080 -Q 10 -F 15 -b 4096 -a >$LOG 2>&1 &
  #OSD Date & Time
  snx_isp_ctl --osdset-en 1 --osdset-ts 1 --osdset-template 1234567890./-:Date --osdset-gain 2 --osdset-bgtransp 0x1 --osdset-bgcolor 0x000000
  #--mfset-mode  Set Mirror Flip Mode(mode:off:0, flip:1, mirror:2, flip&mirror:3)
  snx_isp_ctl --mfset-mode 0  
  echo "$!" > "$PIDFILE"
}

stop()
{
  pid="$(cat "$PIDFILE" 2>/dev/null)"
  if [ "$pid" ]; then
     kill $pid ||  rm "$PIDFILE"
  fi
}

if [ $# -eq 0 ]; then
  start
else
  case $1 in start|stop|status)
    $1
    ;;
  esac
fi

And stop and start again the 20-rtsp-script shows:

Running script '20-rtsp-server'...
Starting RTSP server...
optind:3  optopt:0
optind:5  optopt:0
optind:7  optopt:0
0, strlen= 19
1, strlen= 19
2, strlen= 19
3, strlen= 19
4, strlen= 19
5, strlen= 19
6, strlen= 19
7, strlen= 19
8, strlen= 19
9, strlen= 19
10, strlen= 19
11, strlen= 19
12, strlen= 19
13, strlen= 19
14, strlen= 19
15, strlen= 19
16, strlen= 19
17, strlen= 19
18, strlen= 19
optind:9  optopt:0
optind:11  optopt:0
optind:13  optopt:0
snx_isp_osd_enable_set(1) ==>
snx_isp_osd_timestamp_set(1) ==>
snx_isp_osd_gain_set(2) ==>
snx_isp_osd_txt_color_set(0) ==>
snx_isp_osd_txt_transp_set(1) ==>
snx_isp_osd_template_set(1234567890./-:Date ) ==>
snx_isp_osd_font_set() ==>
optind:3  optopt:0
snx_isp_mirror_flip_mode_set(0) ==>

Could somebody give me pls some help.

[samtap]

I'm aware of this issue, but I don't think there's much we can do about it... The snx_isp_ctl tool only toggles osd settings, the actual updating is handled by closed-source sonix libraries/drivers.

I did receive some reports from others who had a correct osd timestamp (could be related to mi home settings?) but I'm not sure if both the system time (as shown on the status web page) and osd were correct in those cases. Maybe they just set the system time 2 hrs early to compensate.

There's also the possibility to update the osd yourself, i.e. create a script that writes a date/time string to the osd every second. It's just a shame we have to resort to this instead of using the internal hardware-supported method.

[conradhagemans]

Because of this post I checked my OSD. I noticed that I am 1 hour off, earlier.
Other option could be to use Zoneminder to pickup the stream and use Zoneminder to put an OSD on the picture/stream.
I am using Zoneminder and runs nicely. Of course you will need a server to run Zoneminder. Other advantage of Zoneminder is that you can access the stream from outside your local network with security enabled (username/password). The current RTSP-Server lacks any security.

[Tommy032017]

I did a check with wireshark and the camera only connects to google NTP server with enabled "Disable cloud applications". So no more cloud traffic and camera seems to do no more talking back home.
This is the result of wireshark concerning the correspondence to the NTP server. Maybe it will be interesting for somebody.

Frame 2347: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
    Encapsulation type: Raw IP (7)
    Arrival Time: Mar 30, 2017 14:34:35.276600000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1490877275.276600000 seconds
    [Time delta from previous captured frame: 0.054861000 seconds]
    [Time delta from previous displayed frame: 33.040783000 seconds]
    [Time since reference or first frame: 116.029534000 seconds]
    Frame Number: 2347
    Frame Length: 76 bytes (608 bits)
    Capture Length: 76 bytes (608 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: raw:ip:udp:ntp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Raw packet data
Internet Protocol Version 4, Src: 192.168.150.39, Dst: 216.239.35.0
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
        0001 00.. = Differentiated Services Codepoint: Unknown (4)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 76
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 63
    Protocol: UDP (17)
    Header checksum: 0xe8d1 [validation disabled]
        [Good: False]
        [Bad: False]
    Source: 192.168.150.39
    Destination: 216.239.35.0
    [Source GeoIP: Unknown]
    [Destination GeoIP: United States]
        [Destination GeoIP Country: United States]
User Datagram Protocol, Src Port: 33614 (33614), Dst Port: 123 (123)
    Source Port: 33614
    Destination Port: 123
    Length: 56
    Checksum: 0x0740 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    [Stream index: 16]
Network Time Protocol (NTP Version 4, client)
    Flags: 0x23, Leap Indicator: no warning, Version number: NTP Version 4, Mode: client
        00.. .... = Leap Indicator: no warning (0)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or invalid (0)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 1,000000 sec
    Root Delay:    0,0000 sec
    Root Dispersion:    0,0000 sec
    Reference ID: NULL
    Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Origin Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Receive Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Transmit Timestamp: Jan 10, 2033 02:46:12.210380000 UTC

[ZeroPoints]

I've been digging around in the sonix sdk and found what it uses for timestamp.
In both snx_isp_osd_unicode.c and snx_isp_osd_ascii.c
They both use code that appears like this.

	time_t timep;
	struct tm *p;
	time(&timep);
	p = localtime(&timep);
	sprintf(str, "%04d-%02d-%02d %02d:%02d:%02d", (1900 + p->tm_year), (p->tm_mon + 1), p->tm_mday, p->tm_hour, p->tm_min, p->tm_sec);

	snx_isp_osd_line_txt_set(ISP_CH_0, ISP_OSD_LINE_1, str);
	snx_isp_osd_line_txt_set(ISP_CH_1, ISP_OSD_LINE_1, str);

When i get time I'm going to create a standalone binary to see if it outputs correct or utc and maybe see where i can go from there

[Tommy032017]

@ZeroPoints
Perfect!
I did some more tests and getting UTC from NTP works, but the problem is the transformed timezone.
For Europe we would need this: CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
I think there must be any additional transforming, concerning the settings to TZ.
I also got a correct time once by one camera, but it was more accidental, because I was trying some tests and also did a reset an a reinstalling of the hack. My guess is, that the entry in TZ will be synchronized by connecting the cloud and transformed to the correct timezone by the cloud.
Would be perfect, if there will be a solution for international timezone.
It's not very important to have the time stamp, but I like it, because it shows me, that the camera is working correct and streaming pictures are actual.

[samtap]

The code referred to by @ZeroPoints is part of snx_isp_ctl. So it might be used to set the time once, it is certainly not used to keep it updated every second since that would require snx_isp_ctl to run continously.
From what I can tell, the code in snx_isp_ctl is correct as it uses the system time but I suspect there's code somewhere else (snx_isp.ko or libsnx_isp.so? or one of the other closed-source drivers/libs) that doesn't consider the local timezone, or does some weird transformation based on region setup by cloud app. The cloud config data is in /etc so perhaps we can find some way to trick it into doing the correct transformation by changing some setting there.

[samtap]

@Tommy032017 Not sure if you've noticed, but ntpd is started by my scripts (data/etc/scripts/02-ntpd), and is also updated once by running ntpd -q when you change TZ on status page. This should run regardless of cloud apps being enabled.

[Tommy032017]

@samtap Yes, I know this. Every time you change TZ, an update will be done. I also did a capture by wireshark and the camera does continuously and periodically synchronize with the NTP server. This should't be the problem!
But NTP only gives back UTC time. And local time will be transformed independent.
So somewhere the transformation to the local specific time must be done. Maybe internal or by cloud? The parameter to know how to transfer will be given by "CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00".

[samtap]

Well it's handled by any compliant C library for the last ~ 30 years (reads /etc/TZ or something similar to create a time that corresponds with the local timezone i.e. localtime(). I just think the Chinese tried to reinvent the wheel and produced a square one instead of round.

[Sander456654]

I stupidly deleted the time zone and the server - now I can not fix the time, through the web interface, help me fix the file locally

[metroeye]

I have a same problem with "Sander456654".
TZ may reset to UTC+0 and I can not chage the time. Please help me how to fix it.
Thanks in advance.

[Sander456654]

I change time - command "date", but after a while, it itself returned back - correction is must UTC +5, but now the script does not accept it from forms.

[metroeye]

@Sander456654 I have tested the command "date" after telnet connecting. it works. but the date and time is back after rebooting. How can I set the timezone for date/time on screen.

[Sander456654]

Let's wait, maybe @samtap will recommend Something

[metroeye]

I solved it! but I am not sure this is correct...
my "/etc/TZ" file was empty ( I don't know why)
so I saved a line "GMT-9:00" for Seoul Korea in that file.
It works well ^^

[Sander456654]

Does the insertion in the video also show the right time?
It did not help me, only in the script shell.

[kamel83]

Hi folks :) After a little bit of messing around I found that the following seems to work for me just fine:

/etc/init.d/rcS > un-comment this line > modprobe snx_rtc

/etc/fang_hacks.sh > add the following to the end of the file:

/bin/busybox hwclock -l >> /tmp/hacks.log 2>&1
logmsg "hwclock -l"
sleep 2

/media/mmcblk0p2/data/etc/scripts/02-ntpd start >> /tmp/hacks.log 2>&1
logmsg "ntpd start"
sleep 6

/bin/busybox hwclock -t >> /tmp/hacks.log 2>&1
logmsg "hwclock -t"
sleep 2

/media/mmcblk0p2/data/etc/scripts/02-ntpd stop >> /tmp/hacks.log 2>&1
logmsg "ntpd stop"
sleep 2

/media/mmcblk0p2/data/etc/scripts/02-ntpd start >> /tmp/hacks.log 2>&1
logmsg "ntpd start"
sleep 2

logmsg "All done!" 

That's it. Now just reboot and wait patiently for the camera to start. Please note that the camera must be able reach the NTP server within the 6s sleep, so please extend this if required.

Let me know if it works for you :)

[Pauperx]

kamel83=king! 👍 Great work, pal!

[davidjb]

@kamel83 Thanks for the suggestion; turns out the RTC module isn't needed.

I ended up adding a ntpd -q -n -p time.google.com && hwclock -t call into 02-ntpd script immediately above before the original ntpd is being started (davidjb@70d5ff5). That has ntpd set the user space date/timezone first, then sets the kernel's timezone via hwclock (which has the side effect of making the date incorrect as it adjusts the time as per your TZ offset), then as ntpd starts normally, finally correcting the date to what it should be.

It's a curious solution, but hwclock seems to be the only built-in way of setting the kernel's timezone from user space. Someone could compile a C application to just do that job though if they were keen.

[BlaY0]

Another way would be uncommenting modprobe snx_rtc and hwclock -s in rcS. That way you don't need to call ntpd twice. If you worry too much about rtc module being loaded, you can as well unload it afterwards...

[davidjb]

Thanks @BlaY0, I've switched to using modprobe snx_rtc && hwclock -s && modprobe -r snx_rtc instead within the ntpd script. Much faster on boot!

[tam481]

@davidjb do you execute "modprobe snx_rtc && hwclock -s && modprobe -r snx_rtc" instead of ntpd under "start"?
I tried doing that but the time ends up being 01/01/2000!

Could someone please explain howto fix this please?

[davidjb]

@tam481 That date/time in the year 2000 is the default set in the hardware RTC. ntpd will correct it when ntpd is started and time has synced. Try doing a ps and if you're finding ntpd isn't running after boot, then you're probably seeing the same issue as #145 (comment). For my cameras, the network isn't yet upon running the 02-ntpd script so I made some changes in be1af31 to wait til the network is up. Now, the time's back to working correctly & the OSD is showing the correct time.

[sshaikh]

For anyone else struggling with this, the final solution isn't quite enough. You have to run hwclock -t at least once (it survives a reboot). So something like this on the command line:

modprobe snx_rtc
hwclock -t
modprobe -r snx_rtc

Just to be clear, this does NOT have to go in a script or anything, just run once manually. David's hwclock -s line might still be needed in a script though.

[madmax2]

@sshaikh Can you please give a full step by step instructions how to fix the +1hr time zone in OSD?

I read this thread and tried some of the info here, but still showing incorrect +1hr time in my OSD.

Also is there two different methods to fix this problem?

[sshaikh]

Alas I cannot. I have three of these running and checking just now I see 2 of them with the correct TZ. I don't think I've treated them any differently, and following all the commands (including my own) doesn't fix it.... so it all seems a bit of a lucky dip really :)

[madmax2]

@sshaikh Did you follow #78 (comment) script?
or Pauperx method?

I tried @kamel83 method and my camera stop displaying the rstp stream and I couldn't ssh or access the web page.

[madmax2]

@kamel83 Hi I tried your script change #78 (comment) but why now the RSTP stop streaming and why I can't access ssh or viewing the status page shows 404?

Basically the script change didn't work (as far as I can tell) and made the camera non functional and not working.

[toshichi]

Hi there I just made everything worked well as @davidjb said here.
Modify /media/mmcblk0p2/data/etc/scripts/02-ntpd, add ntpd -q -n $NTPD_OPTS && hwclock -t to the start function and it will be like:

start() 
{
  echo "Starting ntpd..."
  ntpd -q -n $NTPD_OPTS && hwclock -t
  ntpd $NTPD_OPTS
}

Reboot the camera and both OSD and date is set to your timezone.

[madmax2]

@toshichi your script change works and showing correct time
but why i check managed scripts show

20-rtsp-server | NOK

[sshaikh]

Hi there I just made everything worked well as @davidjb said here.

Worked for me. Interestingly he's evolved solution in #78 (comment) is what wasn't working for me.

[toshichi]

@toshichi your script change works and showing correct time
but why i check managed scripts show

20-rtsp-server | NOK

Glad to hear that it works. I also suffer this NOK status now and then. It looks like the process is not very stable.
Click stop and the red cell will become yellow. Click start to restart it. That's what I do when I see this status.

[madmax2]

@toshichi all working now..

[toshichi]

@madmax2 If it often crashes, check #217 and here to create a watcher service.

[madmax2]

@toshichi experiencing a new problem...
do you know how to get the time /script to update with daylight saving changes?
the xiaofang is now running 1 hour behind my real life clock

[toshichi]

@madmax2 Sorry I have no idea about DST, perhaps you can change your timezone to a 1-hour-ahead one?