AVS Forum banner

641 - 660 of 784 Posts

·
Registered
Joined
·
97 Posts
Home Assistant(HA) has it own O/S SD image. I tried but was having difficulty getting Python 3.8 to work properly. May try later.

Using a Pi3 was the minimum.. Pi4 was the recommended hardware.

My Pi3 had been running Motion, PIGs and a Plex server all together. Resources wasn't the issue.

Trying to load HA on top of Raspian Buster and getting Python 3.8 was the stumbling block.
 

·
Registered
Joined
·
295 Posts
Discussion Starter #642
Well, I think DVR+ is getting its Daylight Savings Date/Time info from PSIP. I've messed with the timezone info in pigs.json trying get get dvr+ off Nov 1 @ 2am... but no luck.

This article seems to imply that psip does contain the necessary info as long as the TZ is specified on DVR+. So it appears PiGS has very little to do with DST.

from atsc.org:
The ATSC PSIP Standard (A/65A) requires broadcasters to transmit a reference for time of day with the System Time Table (STT). The STT bases its reference for time of day on Global Positioning Satellite (GPS) time, which is measured in terms of seconds and provides a reliable and predictable timebase for specification of future events. The STT even provides daylight savings time information.
Before a receiver can use the STT data to track local time of day, it needs to know the time zone specified as an offset in hours from UTC (Coordinated Universal Time) and whether or not daylight savings time is observed locally. For an over-the air digital television, this information may be entered directlyby the consumer via a unit setup function. For a cable set-top box, this information may be delivered by the cable system operator. System time data is required to be no less accurate than plus or minus one second. By locking to the broadcast station master clock, the DTV receiver will be the most accurate timepiece in the house.
 

·
Registered
Joined
·
295 Posts
Discussion Starter #644 (Edited)
It appears the time-change went off without a hitch. CM's data changed like this (not what I expected).

"TimeZones":[
{ "StartDateTime":"2020-11-01T07:00:00Z",
"EndDateTime":"2021-03-14T08:00:00Z",
"Offset":"-360"
}]

Their TimeZones[] list is more like the current period start and end times... The StartDateTime is when this period started and EndDateTime is when it ends. my offset changed from -300(-5hr) to -360(-6hr) as it should.
I guess I was expecting it to be the DST Start/End times for 2021, like start march 14, 2021 end Nov xx, 2021

But it doesn't matter since dvr+ is not using it.
 

·
Registered
Joined
·
518 Posts
It appears the time-change went off without a hitch.
Since an Internet connected DVR+ gets its time from pool.ntp.org, all time information is in UTC. It's the responsibility of the operating system on the device to know when to change the time from Standard time to Daylight Saving time. A problem arises if the DST dates change and the OS is not updated to reflect those date changes.

Any DVR+ that receives schedule data via PSIP would get the time information from the System Time Table (STT) data that is transmitted with the schedule information. The DVR+ would get the time from the currently tuned station—or possibly the local PBS station if the device has two or more tuners. ( A brief review of the ATSC standard does not indicate that a device would get the time data from a local PBS station exclusively. ) Some will remember that later model VCRs used to be able to set their clocks by manually tuning to a local PBS station to set the time to avoid the dreaded blinking 12:00 problem.

A couple of resources from ATSC.org relating to broadcast standards for PSIP information:

ATSC Standard: Program and System Information Protocol for Terrestrial Broadcast and Cable (PDF)

A Broadcasters’ Guide to PSIP (PDF)
 

·
Registered
Joined
·
7,680 Posts
This article seems to imply that psip does contain the necessary info as long as the TZ is specified on DVR+.
That is correct. PSIP does contain DST info.
The DVR+ would get the time from the currently tuned station—or possibly the local PBS station if the device has two or more tuners.
I bet it's a bit more complicated than that. (For one thing, the DVR+ would have no way of knowing for sure which station is PBS, but since every station broadcasts time and DST info, that's probably irrelevant anyway.) We know the DVR+ builds a PSIP guide even if an Internet/PiGS guide is available, probably to use as a default in case the Internet guide is missing some channels. You can see this if you start a manual guide refresh - PSIP data briefly appears in the guide, then gets overlaid by the data coming from PiGS. I would expect the DST info to be captured at the same time the PSIP guide database is built. (The same goes for time-of-day if Internet time is not available.)

That does leave the problem of what to do if some stations broadcast incorrect DST and/or time of day, which unfortunately happens for a variety of reasons. This was often a problem on E*'s predecessor DVR, the DTVPal (aka CM-7000Pal). Apparently E* figured it out somehow, because I've never seen the DVR+ mess up a DST change as I've seen on the Pal. It probably tries to find some sort of consensus among the stations, but only E* knows the details.
 

·
Registered
Joined
·
1,728 Posts
I just noticed that PiGS is reporting timetags (those which aren't in UTC) on various events in EDT, while we are on EST now, so they're all shown as an hour after when the event actually took place. The Pi and PC themselves have the correct time. The Windows version also reports EDT, though it spells it out "Eastern Daylight Time" whereas the Raspbian version uses "EDT". Don't know what it's doing in other time zones, but I'm wondering how it knows when it should change (does it come from SD, the DVR+, or the OS?)
 

·
Registered
Joined
·
295 Posts
Discussion Starter #649 (Edited)
Yeah I just noticed that last night also. It's my own local time conversion function. Time was a challenging part of PiGS. And this proves that everything you find on the internet is not necessarily true :) It comes from the OS by way of the the 'time' and 'datetime' modules, and it appears I was using the wrong functions. My mistake was that the flag time.daylight does not change - that flag just says this zone 'observers' daylight time, but that was not a flag that changed when CDT changed to CST... It will be interesting to see what windows does with the new code. The Localtime display is just a display thing - trying to make it easier for humans to understand when PiGS did things.

I already fixed it and it'll be out in the next release but if you want to fix it before then, replace this stuff in the file ut.py.

Stop PiGS. Open ut.py. Delete the RED lines, add the GREEN lines (keep everything else).
Make sure the indent stays the same (4 spaces). Save ut.py. Restart pigs

def LocalTimeStr(at, showSeconds=False, showDate=True, showTimeZone=True) : #

if time.daylight : # determine which offset to use based on daylight flag (0 or 1)
tzmins = -int(time.altzone/60)
else :
tzmins = -int(time.timezone/60)
tzhrs = int(tzmins / 60)
# Get the timezone name
tzstr = "(" + time.tzname[time.daylight] + ")"
localTime = at + timedelta(hours=tzhrs)
# fixed in 2.13 to display correct local-time
t = time.localtime()
tzstr = "(" + t.tm_zone + ")"
tzmins = int(t.tm_gmtoff/60)
localTime = at + timedelta(minutes=tzmins)
dispFmt='' <<< this line (and below) doesnt change
 

·
Registered
Joined
·
2 Posts
I'm sorry, if this is the wrong place to post this question but here it is:

I am using PiGS-v1.12-For-Windows-Portable. I am using 12919 as the zipcode. Daylight Savings ending worked fine except for one channel and now that schedule is off by one hour. The channel is NHK World 57.2 (which is the channel we watch the most):

LS:BLS: Added 1506 programs for channel 57.2, RfChan=36 (StationID=54298)

I have removed this channel from my Favourites to allow the PSIP for this one channel, and the schedule is fine for time. Also, the NHK World TV Schedule on their wesbite shows the correct time.

I notice in the status of my PiGS or the logs it still shows the daylight savings time, with the time in the status being off by an hour (PiGS restarted at 10:07 Eastern Standard Time):

MAIN: PiGS started at 2020-11-04 11:07(Eastern Daylight Time)


I have an TV Listing App on my iPhone, TV Listings by TV24, and it too is showing the schedule as off by one hour. So there are two applications that are off which make me think the source must be wrong. I took a look at SchedulesDirect's FAQ which says:

"This is usually a Time Zone or Daylight Saving Time (DST) issue on the application side. We provide data in UTC, so time conversion is done by the local app."

I was going to try to make the changes above but as I am using PiGS-v1.12-For-Windows-Portable I don't have the ut.py file and when I searched the file contents for the settings in that file, I don't find them.

Any ideas would be appreciated. Thanks.
 

·
Registered
Joined
·
295 Posts
Discussion Starter #651 (Edited)
the ut.py fix is for log display only. it doesnt affect the data that comes from SD or how dvr+ displays it.
your icon is Canadian... is there a reason you are not using a candian zip?
I see that zip is right on the border... and solidly in the Eastern Time zone. with only 1 channel shifted, it almost has to be the SD source data.
Can you give me your Canadian zip, and 1 or 2 more channels in 12919 that are correct...
also can you email your pigs.json file and pigslog.txt file to [email protected] and I will look at your configuration...

we did just learn that the timezone shift comes from the psip data but it seems wierd that it would only affect 1 channel...

but to add, the dvr knows very little about localtime. the listings are specified in GMT/Zulu and the 'Time' never really changed... the world kept spinning at the same rate, all that happens is the time LABELs change. so for 1 station to change, either the raw SD data changed, or that station changed its broadcasting, but I assume that things you watch are still on at the same time each day.
 

·
Registered
Joined
·
2 Posts
Hi,
I am not using a Canadian ZIP (Postal Code) because all the channels that I get OTA aren't listed for my code of H9X 4A5.

Examples of channels that are correct are:
57.1, RfChan=36 (StationID=44368)
12.1, RfChan=12 (StationID=65995)

I have tried to following the information on SchedulesDirect site to view raw data with xmltv but my configuration setup errors out.

I will send the log and .json file right away.

Thanks
 

·
Registered
Joined
·
295 Posts
Discussion Starter #653 (Edited)
Pigs did a little better this month... So more are downloading PiGS but not joining this forum.

Application Name : PiGS
Active SD users : 43 (+16) (as reported by users' profile)
Fetch-14 users : 40 (+14) (data downloaded within 14 days)
 

·
Registered
Joined
·
295 Posts
Discussion Starter #654 (Edited)
I am not using a Canadian ZIP (Postal Code) because all the channels that I get OTA aren't listed for my code of H9X 4A5.
Examples of channels that are correct are:
57.1, RfChan=36 (StationID=44368)
12.1, RfChan=12 (StationID=65995)
We determined that indeed the SD source data for "NHK World" was shifted by 1 hour for Zip 12919 57.2, RfChan=36 (StaID=54298)
Submitted to SD for fix, but in the meantime, Buck found a nearby zip in NJ 07631 that carried the same network on 50.2. (StaID=29140 )
Since PiGS allows for up to 4 lineups, we 'borrowed' the schedule from 50.2 to display on his 57.2. These were the steps:

With PiGS running,
1 select 12919 in Lineups and deselect just 57.2 (ctrl-click)
2 preview zip 07631
3 select just channel 50.2
4 'Add this channel lineup' (will now have 2 lineups)
5 save settings, pigs will build a schedule with 50.2 in it
6 quit pigs with ctrl-c so pigs.json can be edited
7 edit config file pigs.json with a text editor like notepad (not word or anything)
8 search for 50.2, and find this block
{
"channel": "50.2",
"name": "WNJNDT2 (WNJN-DT2)",
"callsign": "WNJNDT2",
"affiliate": "NHKWRLD",
"favorite": true
},
9 change the 50.2 to 57.2 (what the dvr wants)
10 save the file
11 restart pigs which will build the schedule (station id for 57.2 should be 29140 when it builds)
(the preview window will now show 57.2 in the 07631 Lineup)
12 manual guide refresh DVR from DVR menus
13 schedule should be correct
 

·
Registered
Joined
·
459 Posts
Stop PiGS. Open ut.py. Delete the RED lines, add the GREEN lines (keep everything else).
Make sure the indent stays the same (4 spaces). Save ut.py. Restart pigs

def LocalTimeStr(at, showSeconds=False, showDate=True, showTimeZone=True) : #

if time.daylight : # determine which offset to use based on daylight flag (0 or 1)
tzmins = -int(time.altzone/60)
else :
tzmins = -int(time.timezone/60)
tzhrs = int(tzmins / 60)
# Get the timezone name
tzstr = "(" + time.tzname[time.daylight] + ")"
localTime = at + timedelta(hours=tzhrs)
# fixed in 2.13 to display correct local-time
t = time.localtime()
tzstr = "(" + t.tm_zone + ")"
tzmins = int(t.tm_gmtoff/60)
localTime = at + timedelta(minutes=tzmins)
dispFmt='' <<< this line (and below) doesnt change
Does this get included into V1.13 or is it a one-off change for special circumstances?

Thanks,

Scott
 

·
Registered
Joined
·
68 Posts
A strange thing started in that this address error (see Capture) now loops continuously. A reset has no effect. Only shutting off DVR+ #1 while DVR+ #2 works normally.
 

Attachments

·
Registered
Joined
·
295 Posts
Discussion Starter #658 (Edited)
A strange thing started in that this address error (see Capture) now loops continuously. A reset has no effect. Only shutting off DVR+ #1 while DVR+ #2 works normally.
Strange..... it means the PiGS dns server is not getting a response from the upstream dns server...

From @sam_adams Post stb.channelmastertv.com appears to be associated with the channel master tv app
Anything different about that dvr? firmware version? did you change/do something recently? Play with CM TV?
that is not one I added to the list of urls Pigs dns blocks. The good news is that you should be able to stop the message by adding that host to pigs.json.

Stop pigs. from a command prompt
sudo nano pigs.json (if on a Pi, or use a text editor like Notepad on windows)
find the DnsHosts section
add the line in green, dont forget the trailing comma
save the file, restart Pigs

DnsHosts": {
"epg.channelmastertv.com": "*",
"roproxy-guide.echostarcdn.com": "*",
"stb.channelmastertv.com": "0.0.0.0",
"xpool.ntp.org": "*",
"xechostar.com": "69.164.198.192",
"xmicrosoft.com": "173.255.215.209",
"xamazon.com": "104.236.116.147",
"xgoogle.com": "138.236.128.112",
"tr50.dishaccess.tv": "0.0.0.0",
"stbfw.echodata.tv": "0.0.0.0"
},


That will cause PiGS to answer the request from DVR+ instead of going out to the internet for an answer (that appears to not exist)

That PIGSDNS:GHBN Error() message is mostly informational. I have changed that message to the debug level instead of warning
with pigs stopped, you could edit pigsdns.py changing warning to debug as below
or just put a # in front of the line to comment it out all together.

except Exception as inst:
Flags[1] += 2 # signal a dns server error for all errors
#Flags[1] += 3 # signal a dns name error for all errors
logging.warning("PIGSDNS:GHBN Error(%s) %s: %s", qhost, addr, inst )
logging.debug("PIGSDNS:GHBN Error(%s) %s: %s", qhost, addr, inst )


Testing stb.cmtv.com with dig, 'the internet' does not provide any answer, so PiGS prints a warning
maybe CM has removed that host from their server and the dns entry for it...

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> stb.channelmastertv.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44574
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;stb.channelmastertv.com. IN A

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Nov 12 14:54:39 CST 2020
;; MSG SIZE rcvd: 41



# These are the URLs that we know about
Standard query response 0x016d A microsoft.com A 40.113.200.201 A 40.112.72.205 A 40.76.4.15 A 13.77.161.179 A 104.215.148.63
Standard query response 0x016e A echostar.com A 139.85.4.115
Standard query response 0x016f A echostar.com A 139.85.4.115
Standard query response 0x0170 A amazon.com A 176.32.103.205 A 176.32.98.166 A 205.251.242.103
Standard query response 0x0172 A amazon.com A 176.32.103.205 A 205.251.242.103 A 176.32.98.166
Standard query response 0x0173 A google.com A 216.58.192.174
Standard query response 0x0171 A tr50.dishaccess.tv CNAME stbfw.echodata.tv A 67.148.153.225
Standard query response 0xf6b8 A epg.channelmastertv.com CNAME proxy-elb-1800886808.us-west-2.elb.amazonaws.com A 35.160.224.97 A 52.37.131.128
Standard query response 0xf6b9 A cps-static.rovicorp.com CNAME d3871tx5qq6rdv.cloudfront.net A 13.227.45.14 A 13.227.45.5 A 13.227.45.114 A 13.227.45.78
and pool.ntp.org
 

·
Registered
Joined
·
10 Posts
Timothee,

I'm seeing the same thing running PIGS on windows it started yesterday. I was running v1.11 today I finally started running v1.12 and I'm getting the same error message. Everything was fine until yesterday. I can do a manual request for update and it works fine but I still see the error message after the update. PIGS was working fine with no issues since the beginning of October. Just wanted to let you know windows version is doing the same thing.
 

·
Registered
Joined
·
68 Posts
Strange..... it means the PiGS dns server is not getting a response from the upstream dns server...

From @sam_adams Post stb.channelmastertv.com appears to be associated with the channel master tv app
Anything different about that dvr? firmware version? did you change/do something recently? Play with CM TV?
that is not one I added to the list of urls Pigs dns blocks. The good news is that you should be able to stop the message by adding that host to pigs.json.
The only difference is DVR+ #1 Channel Master TV status is Activated and has been for years but not used. I need to find out how to deactivate before trying anything else to know if that matters.
 
641 - 660 of 784 Posts
Top