8 hours delay on the time display

[ghost]

Thanks, it's really a great project that I just discovered and installed on Ubuntu 20.04 with python3. I have a small bug. There is an 8 hours delay on the time display, on the events / hovering and the axis. A blood glucose of 8:20 AM is displayed as 4:20 PM. The device is the G6 receiver: Rev. 004, Firmware 5.1.3.026. But the program is still a real improvement!

[DexcTrack]

The program gets the local timezone information by using a Python library called tzlocal. In dexctrack.py, we have :

  33 import tzlocal
...
  74 mytz = tzlocal.get_localzone()
...
 522 # We want to display dates in the local timezone
 523 plt.rcParams['timezone'] = mytz

I run on a Linux Mint 19.1 system, based off of Ubuntu 18.04. It's a little older than yours, but still pretty close. It's possible the timezone is not correctly set on your system. If you run date in a terminal, does the response look correct? Next, try running python3 to see if tzlocal provides the right response. For example:

> python3
Python 3.6.9 (default, Jan 26 2021, 15:33:00) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tzlocal
>>> tzlocal.get_localzone()
<DstTzInfo 'America/Chicago' LMT-1 day, 18:09:00 STD>
>>> 

In more recent releases of python3, there is an effort to discourage use of tzlocal. First, they said you should use dateutil instead. Then they decided to deprecate dateutil, and suggested using datetime, where some timezone capabilities had recently been added. Because I'm trying to support both python2 and python3 users, I still use tzlocal. If tzlocal has been broken in some way for versions of python3 newer than 3.6.9, then I could implement some code to fetch the timezone differently for python3. Let me know what version of python3 you are running, and what result you get from tzlocal.get_localzone(). Does the string at the beginning match your timezone?

To see how the timezone is configured on your system, use timedatectl. For example:

> timedatectl
                      Local time: Tue 2021-04-13 17:59:41 CDT
                  Universal time: Tue 2021-04-13 22:59:41 UTC
                        RTC time: Tue 2021-04-13 22:59:41
                       Time zone: America/Chicago (CDT, -0500)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

If your configuration does not look correct, get a list of available timezones.

> timedatectl list-timezones
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmara
...

Pick one which matches your location, and then sudo timedatectl set-timezone <your_time_zone>

[DexcTrack]

I just tested running python3 dexctrack.py on a Linux Mint 20.1 system, which is based off of Ubuntu 20.04, and it worked fine. The python3 version was 3.8.5. I suspect your problem is that the OS timezone is not set properly.

[ghost]

Hi, Thanks for your answer. The 3 return correct for my system (Europe/Zurich)

date
jeu 15 avr 2021 16:13:38 CEST

python3
>>> import tzlocal
>>> tzlocal.get_localzone()
<DstTzInfo 'Europe/Zurich' LMT+0:34:00 STD>

timedatectl
               Local time: jeu 2021-04-15 16:16:55 CEST
           Universal time: jeu 2021-04-15 14:16:55 UTC 
                 RTC time: jeu 2021-04-15 14:16:55     
                Time zone: Europe/Zurich (CEST, +0200) 
System clock synchronized: yes                         
              NTP service: active                      
          RTC in local TZ: no       

Today i cannot lauch dexctrack. I have errors like:

Locator attempting to generate 4018 ticks ([10774.916666666666, ..., 14791.916666666666]), which exceeds Locator.MAXTICKS (1000).
Locator attempting to generate 4018 ticks ([10774.916666666666, ..., 14791.916666666666]), which exceeds Locator.MAXTICKS (1000).
Locator attempting to generate 96439 ticks ([10774.375, ..., 14792.625]), which exceeds Locator.MAXTICKS (1000).

Last time I use dexctrack, I forget to quitt before to shut down my computer - perhaps it's the reason? Is there a way to "reset" ? Should i delete the sqlite file in my home ? (I don't speak python!)

[DexcTrack]

The sqlite3 database is generally fault resistant, but it's possible that something got mangled. You can try deleting the sqlite database file in your home directory.

To get some more useful information for debugging, please add a -d option when you restart the program. This causes debug messages and exception messages to be printed out to the terminal. For example:

> python3 dexctrack.py -d
DexcTrack  Copyright (C) 2018  Steve Erlenborn
This program comes with ABSOLUTELY NO WARRANTY.

get_screen_size width = 1920 , get_screen_size height = 1080 , dispRatio = 1.8
sys.platform = linux
backend = TkAgg
sqlite_file = /home/steve/dexc_PL75130020.sqlite
rcParams[timezone] = America/Chicago
Latest glucose at 2021-04-15 14:15:13-05:00 = 114
plotGraph() : Before plotting              count = 235424
1 degree polynomial =

-0.5486 x + 113
1 hour prediction : at 2021-04-15 15:15:13-05:00 glucose = 103

2 degree polynomial =
         2
0.1646 x - 1.558 x + 114
1 hour prediction : at 2021-04-15 15:15:13-05:00 glucose = 140

Out of range Legend (-1.0, -1.0)  moved to (0.093, 0.878)
plotGraph() : Before displayCurrentRange() count = 260870
plotGraph() :  After displayCurrentRange() count = 260870    + 260870
++++++++++++++++++++++++++++++++++++++++++++++++

                              types |   # objects |   total size
=================================== | =========== | ============
                       <class 'list |       39716 |      3.61 MB
              <class 'numpy.ndarray |        1047 |      2.99 MB
                       <class 'dict |        4261 |      2.59 MB
          <class 'datetime.datetime |       28943 |      1.32 MB
                      <class 'float |       30079 |    704.98 KB
                        <class 'str |       10418 |    704.43 KB
  <class 'numpy.ma.core.MaskedArray |           1 |    441.07 KB
                    <class 'weakref |        2562 |    200.16 KB
                        <class 'int |        4718 |    136.73 KB
                function (<lambda>) |         991 |    131.62 KB
                      <class 'tuple |        1709 |    105.77 KB
                     function (_cb) |         772 |    102.53 KB
         <class 'weakref.WeakMethod |         772 |     84.44 KB
                     <class 'method |        1204 |     75.25 KB
                       <class 'cell |        1468 |     68.81 KB
deviceReadThread launched at 2021-04-15 14:33:59
Reading device at 2021-04-15 14:33:59
Erasing plot data from previous device

Every 5 minutes some more information gets printed out, showing current glucose reading, generated polynomials, and memory usage. If there is a fatal exception, it should print out, as well.

A user located in the Berlin timezone reported a matplotlib crash, the second time they ran the program (#10). I tracked it down to a missing conversion for regions where glucose is reported in mmol/L units. I submitted a conversion fix, but never heard back from them to confirm that fix. It's possible that it's still broken and you are running into the same issue. My Receiver device is using mg/dL units so it's difficult to fully test that scenario. I believe mmol/L units are standard in Europe.

Make sure you're running the latest code, git pull origin master and then launch with the debug option. python3 dexctrack.py -d If you see a Segmentation Fault, it might be the same issue. Please capture any suspicious output (stuff which doesn't look like my example above) and report it in your next message. It will also be useful to see if the timestamp values printed out in the debug output is in your local timezone, or off by 8 hours.

Is your Dexcom Receiver showing the correct local Time at the top of the screen? The device stores all the glucose values using UTC. but User Events get stored using the Local Time. So, if the Date/Time settings are not accurate, it could throw off some of the data which gets pulled in from the Receiver.

[ghost]

I updated with git. Deleting the sqlite file worked, the program started. I did not observe any error in the log.

I quit and tried to restart to check. I thought I could not restart the program (same output as yesterday) but with a little patience and some lines of Locator attempting to generate n ticks (n]), which exceeds Locator.MAXTICKS (1000). the program starts.

The player displays the correct time. But the program shows with the -d option that the last data is 18:20 (instead of 10:20)

python3 dexctrack.py -d
DexcTrack Copyright (C) 2018 Steve Erlenborn
This program comes with ABSOLUTELY NO WARRANTY.

get_screen_size width = 1920 , get_screen_size height = 1200 , dispRatio = 1.6
sys.platform = linux
backend = GTK3Agg
sqlite_file = /home/nat/dexc_PL91016462.sqlite
rcParams[timezone] = Europe/Zurich
Latest glucose at 2021-04-16 18:20:42+02:00 = 0
Locator attempting to generate 4018 ticks ([10774.916666666666, ..., 14791.916666666666]), which exceeds Locator.MAXTICKS (1000).

It is possible that the stored time is different in the devices supplied in Europe?

[DexcTrack]

Could you send a copy of your database? First, zip compress it, as follows: zip ~/dexcDb.zip ~/dexc_PL91016462.sqlite Then drag & drop the ~/dexcDb.zip file to attach it to your message. This way I can use it to try to figure out why it's failing to load. Thanks.

[ghost]

Do you have an email address to send you the database privately? I am happy to continue to exchange publicly but do not wish to publish my medical data on the web.

[DexcTrack]

I've added an option to time shift the display of the data. python3 dexctrack.py -t+8 will shift eight hours forward. python3 dexctrack.py -t-8 will shift eight hours backward. python3 dexctrack.py -t 0 will eliminate any shift. You only need to specify the -t option once. I save the time offset into the database, so the next time you run without a -t option, it will use the last specified offset. Run git pull origin master to get this update. Use the python3 dexctrack.py -d syntax, in case there are any issues.

I have seen a crash when I edit the database to specify 'mmol/L' glucose units, and then plug in my Receiver, which uses 'mg/dL' units. The program reads the configuration from the Receiver. This used to work fine under python2, but the newer release of the matplotlib library under python3 crashes upon the unit transition. However, the update write to the database is successful, and then next time I launch the program, it works fine.

I'm thinking that the crash you saw might be related. The program defaults to 'mg/dL', and then transitions to 'mmol/L' after reading your Receiver. The matplotlib library throws an exception due to the units change, but the next time you launch, it should start out using the correct units and be stable.

Try out the new version, and let me know if it works for you.

[ghost]

The -t option works very well and the offset is well recorded. Thank you very much for the program and your responsiveness.