New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Showing correct time in OSD (snx_isp_ctl) #78

Open
Tommy032017 opened this Issue Mar 30, 2017 · 23 comments

Comments

Projects
None yet
@Tommy032017

Tommy032017 commented Mar 30, 2017

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.
image
image
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

This comment has been minimized.

Show comment
Hide comment
@samtap

samtap Mar 30, 2017

Owner

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.

Owner

samtap commented Mar 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@conradhagemans

conradhagemans Mar 30, 2017

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.

conradhagemans commented Mar 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Tommy032017

Tommy032017 Mar 30, 2017

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

Tommy032017 commented Mar 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ZeroPoints

ZeroPoints Mar 31, 2017

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

ZeroPoints commented Mar 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Tommy032017

Tommy032017 Mar 31, 2017

@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.

Tommy032017 commented Mar 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@samtap

samtap Mar 31, 2017

Owner

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.

Owner

samtap commented Mar 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@samtap

samtap Mar 31, 2017

Owner

@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.

Owner

samtap commented Mar 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Tommy032017

Tommy032017 Mar 31, 2017

@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".

Tommy032017 commented Mar 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@samtap

samtap Mar 31, 2017

Owner

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.

Owner

samtap commented Mar 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Sander456654

Sander456654 Apr 17, 2017

30muar

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

Sander456654 commented Apr 17, 2017

30muar

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

This comment has been minimized.

Show comment
Hide comment
@metroeye

metroeye Apr 18, 2017

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.

metroeye commented Apr 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Sander456654

Sander456654 Apr 18, 2017

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.

Sander456654 commented Apr 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@metroeye

metroeye Apr 18, 2017

@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.

metroeye commented Apr 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Sander456654

Sander456654 Apr 18, 2017

Let's wait, maybe @samtap will recommend Something

Sander456654 commented Apr 18, 2017

Let's wait, maybe @samtap will recommend Something

@metroeye

This comment has been minimized.

Show comment
Hide comment
@metroeye

metroeye Apr 18, 2017

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 ^^

metroeye commented Apr 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Sander456654

Sander456654 Apr 18, 2017

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

Sander456654 commented Apr 18, 2017

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

@kamel83

This comment has been minimized.

Show comment
Hide comment
@kamel83

kamel83 Jun 12, 2017

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 :)

kamel83 commented Jun 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Pauperx

Pauperx Jun 28, 2017

kamel83=king! 👍 Great work, pal!

Pauperx commented Jun 28, 2017

kamel83=king! 👍 Great work, pal!

@davidjb

This comment has been minimized.

Show comment
Hide comment
@davidjb

davidjb Sep 18, 2017

Contributor

@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.

Contributor

davidjb commented Sep 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@BlaY0

BlaY0 Sep 18, 2017

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...

BlaY0 commented Sep 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@davidjb

davidjb Sep 19, 2017

Contributor

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!

Contributor

davidjb commented Sep 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tam481

tam481 Nov 18, 2017

@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?

tam481 commented Nov 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@davidjb

davidjb Nov 19, 2017

Contributor

@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.

Contributor

davidjb commented Nov 19, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment