NLite not getting timezone

[dsreyn]

Just trying NLite for the first time tonight (my NextPVR server is running on Docker on my Synology NA).  The NextPVR server is set to US Eastern (TZ environment variable set to America/New_York).  I see the correct times everywhere except in Nlite.  "Everywhere" here includes:  the NextPVR web interface, the NextPVR client for Kodi, and the iOS app.

However, NLite does not seem to be getting or applying time zone information.  This applies across the board - the current system time display in the upper right, listings in the TV guide, and times for "ready" recordings and pending recordings.  All of these times are displayed in UTC.  In the Windows 10 settings, the time zone is set to "Eastern Time (US & Canada).  Any idea why NLite isn't converting time to US Eastern?

Doug

[mvallevand]

Did you set the proper timezone value in the docket srtup? There are a few posts here showing how to do that.

Martin

[dsreyn]

Did you set the proper timezone value in the docket srtup?  There are a few posts here showing how to do that.

Martin

Yes, I have the TZ environment variable set there to America/New_York.

Doug

[dsreyn]

Upon further investigation...it turns out that my iOS devices are not getting the right time info after all. Things looked OK at a quick glance, but I now see that I'm back to the problem (in the iOS app) where I only have guide listings for part of the day - the listing are truncated by either 4 or 24 hours (I'm in US/Eastern, currently UTC-4), depending on the current time of day.

And it looks like the problem is not NLite at all, but something more fundamental in my Docker container setup. If I ssh into my NAS, the date command says "Fri Oct 30 07:00:52 EDT 2020". Then if I log into the running NextPVR container, date says "Fri Oct 30 11:00:52 America 2020". Obviously, not what I expect. If I type "set", near the end of the list I see TZ=America/New_York, so that appears to be set correctly. But it doesn't seem to be getting applied properly. I just tried experimenting with setting it to some different time zones, and the only thing that changes is "America" might get replaced by "Europe", for example. Whatever I put in TZ gets displayed there (truncated at the slash), but the actual time value never changes. Strange also that it is not showing something like "EST" or "EDT" - if I run my older NextPVR container, I see "EDT" instead of "America".

I just recently upgraded NextPVR to version 5.0.9.201026 (I had not upgraded for a while...had been using 5.0.1.xxx). I'm using the same environment variable setup as before. Has something changed regarding the timezone setup? It looks like the new version isn't actually setting the time zone for some reason.

Doug

[mvallevand]

What exactly are you using for the TZ variable? Is it possible you used a back slash?

Martin.

[dsreyn]

What exactly are you using for the TZ variable?  Is it possible you used a back slash?

Martin.

America/New_York

Which is exactly what I was using for the previous version of NextPVR.

Doug

[mvallevand]

I checked and I use

--volume /etc/localtime:/etc/localtime:ro \

So my setup gets it from the host.

I did look in sub's Docker with bash and there is no /usr/share/zoneinfo maybe you need to map that in to user America/New_York

Martin

[dsreyn]

I checked and I use

--volume /etc/localtime:/etc/localtime:ro \

So my setup gets it from the host.

I did look in sub's Docker with bash and there is no /usr/share/zoneinfo  maybe you need to map that in to user America/New_York

Martin

Yes, your last sentence was the problem - no /usr/share/zoneinfo.  I manage my Docker container setup using the GUI, because it seems like Synology has made it difficult to do things manually (settings made outside the GUI sometimes get overwritten after a reboot, etc.).  Anyway, whether it's due to the GUI, or if it's a more general Docker restriction, I can not access or mount /usr/share/zoneinfo directly.  But I did come up with the following solution:

1. ssh into the NAS

2. cp -rp /usr/share/zoneinfo /volume1/docker/zoneinfo

3. Then in the Docker configuration GUI:
- Select "Container" in the left panel, then select the relevant NextPVR container
- Select "Edit", then select the "Volume" tab
- Click "Add Folder".  This will allow you to pick something from the *available* part of the file system to map.  You can't access the root directory or /usr/..., but /volume1/docker shows up here as "docker"
- Pick docker/zoneinfo, and set /usr/share/zoneinfo as the mount path

And now, everything works fine - my iOS devices now show the full guide listings, and NLite is showing everything in the correct time zone.  I also see the correct time from the "date" command if I log into the running NextPVR container.

Also of note - besides being unable to access /usr/share/zoneinfo directly, creating a link to it in /volume1/docker (ln -s /usr/share/zoneinfo /volume1/docker/zoneinfo) didn't work either.  Everything looked fine in the shell, but the GUI would not show me the link (and you can't manually edit the source folder in the "Add Folder" step above - you have to pick from what the GUI offers).

Once again, thank you very much for the support.

Doug

[mvallevand]

Instead of copying the folder which you wouldn't want to do every build you could just use the host

--volume /usr/share/zoneinfo:/usr/share/zoneinfo:ro \

However I think you could use a TZ that doesn't need the table

Anyway maybe sub will include this in his docker.

Martin

[dsreyn]

Instead of copying the folder which you wouldn't want to do every build you could just use the host

--volume /usr/share/zoneinfo:/usr/share/zoneinfo:ro \

However I think you could use a TZ that doesn't need the table

Anyway maybe sub will include this in his docker.

Martin

The --volume option isn't available to me, due to running the NextPVR container through the Docker GUI.  The GUI doesn't appear to provide any way to add command line options.  In any case, I won't have to copy the folder for every new NextPVR build, because the place where I put it exists in the Docker file system.  So I'll just need to point new container images to the same location.

Anyway, I admit that this isn't necessarily an ideal solution, but since it works, I'm happy. :-)

Doug