[frank70]

Well, at least I know what to look for if I notice fewer than 90 requests again - see if the prior build was complete or not.

 

[Arenal04]

FYI, member SirCrow recently has DVR+ Lister running Ubuntu 20.04 under Wine/PlayOnLinux (see DVR+ Lister for Channel Master DVR+). Everyone interested in running DVR+ Lister on a Linux computer should investigate his post. I've already had a "conversation" with SirCrow to the extent of my knowledge of running in Linux (which is VERY little), so someone else may be able to answer a problem he is having with the DVR+ Lister Converter.

I posted a reply in the DVR+ Lister thread, containing links to the Linux version of Handbrake and HandbrakeCLI (the command-line version of Handbrake).

 

[frank70]

Well, at least I know what to look for if I notice fewer than 90 requests again - see if the prior build was complete or not.

@timothee, I didn't have to wait very long apparently. Today's log for 194 shows 89 requests with an 8 hour gap between requests 49 (10/26 12:00:00Z) and 50 (10/26 20:00:00Z). This time, the forced build from yesterday was still in effect and had no exceptions.

This time, the guide for 10/26 12:00:00EDT through 16:00:00EDT (the missing block) for channels >12.3 were still UNKNOWN from yesterday's failed build, while for channels 12.3 and below, apparently still contain yesterday's data. So the DVR+ truly skipped a 4-hour block and left behind old data in that block. What is it thinking??? Is it on to us???

The log (starting from yesterday's forced guide build through the end of both DVR+ units today) is attached. Notice that again unit 189 made all 90 requests. Today's missing 4-hour block on 194 is unrelated to the two missing 4-hour blocks from yesterday.

 

[timothee]

@timothee, I didn't have to wait very long apparently. Today's log for 194 shows 89 requests with an 8 hour gap between requests 49 (10/26 12:00:00Z) and 50 (10/26 20:00:00Z). This time, the forced build from yesterday was still in effect and had no exceptions. This time, the guide for 10/26 12:00:00EDT through 16:00:00EDT (the missing block) for channels >12.3 were still UNKNOWN from yesterday's failed build, while for channels 12.3 and below, apparently still contain yesterday's data. So the DVR+ truly skipped a 4-hour block and left behind old data in that block. What is it thinking??? Is it on to us???

if you do the math on the indexes it does look like pigs has sched data for the missing area since the index moves farther fwd than the items sent (but dvr has no way to know what pigs has). Best guess is that dvr is getting something in the prior 4-hr block that tells it to skip fwd??? i cant imagine dvr is that smart. unless there is some wired boundary condition dvr does not like.

There is a dvr 'bug' I found... Channel Master / Rovi Guide Server V9 API Linear Schedule Bug which I think I 'fixed.' Its just weird we have never seen skipped blocks since the 90 counter has been implemented. or the missing block could have been there all-along but the 90 counter made it visible?

if we think pigs is sending bad data in the 49 blk, we could try to dump all 10/26 pigs data with dur=60*24
http://192.168.1.200/linearschedule/99999/info?duration=1440&inprogress=false&startdate=2020-10-26T00:00:00Z
duration is normally 240, and startdate is exactly what is printed in the log, inprogress is true only for the first call the dvr makes

if you can save that block of json in 10-26.json you could email it to me
this is the tool i used to view/search the json Best JSON Viewer Online

You could make calls directly to pigs from your browser and view the json in your browser maybe for the block directly before to see if there is some strange data, but that would be difficult
http://192.168.1.200/linearschedule/99999/info?duration=30&inprogress=false&startdate=2020-06-14T16:00:00Z
duration is normally 240, and startdate is exactly what is printed in the log, inprogress is true only for the first call the dvr makes
but that seems very tedious

 

[frank70]

Best guess is that dvr is getting something in the prior 4-hr block that tells it to skip fwd???

But puzzle me this: an hour after this missing block occurs, DVR+ 189 comes along and (with PiGS still using the exact same guide build data) requests all 90 blocks. If DVR+ 194 were reacting to something in the data, then DVR+ 189 should do exactly the same thing, right? But it doesn't.

 

[timothee]

But puzzle me this: an hour after this missing block occurs, DVR+ 189 comes along and (with PiGS still using the exact same guide build data) requests all 90 blocks. If DVR+ 194 were reacting to something in the data, then DVR+ 189 should do exactly the same thing, right? But it doesn't.

They are not the same... dvr 189 rolled past a 4hr boundary... but I dont know what that means
you could do 2 MGRs so the dvr's a few minutes apart and see if they act the same tomorrow....

MAIN:LINSCHED **** Program Sched Req from ('192.168.1.194', 42417) at 2020-10-18 11:24:57(EDT)
MAIN:LINSCHED: Next Build time is scheduled for 2020-10-19 10:24:57(EDT) <<<< first dvr of the day schedules tomorrows build time
LS:GLS DVR 192.168.1.194 State[10395,2020-10-17 15:14:49.240504]
LS:GLS First Request at: 2020-10-18 11:24:57(EDT)
LS:GLS:Searching for 2020-10-18T12:00:00Z. InProgessFlag=1...
LS:GLS:Request complete! 280 Listings. LI=2431 RequestCount=1, Elapsed= 00:11s

MAIN:LINSCHED **** Program Sched Req from ('192.168.1.189', 51302) at 2020-10-18 12:16:06(EDT)
LS:GLS DVR 192.168.1.189 State[10511,2020-10-17 16:09:34.929307]
LS:GLS First Request at: 2020-10-18 12:16:06(EDT)
LS:GLS:Searching for 2020-10-18T16:00:00Z. InProgessFlag=1...
LS:GLS:Request complete! 240 Listings. LI=2669 RequestCount=1, Elapsed= 00:12s

Note that InProgessFlag=1 resets the State[] ListIndex and RequestCnt to 0

 

[LenL]

But puzzle me this: an hour after this missing block occurs, DVR+ 189 comes along and (with PiGS still using the exact same guide build data) requests all 90 blocks. If DVR+ 194 were reacting to something in the data, then DVR+ 189 should do exactly the same thing, right? But it doesn't.

Just a thought ...is a recording going on at the time?

 

[frank70]

Just a thought ...is a recording going on at the time?

Nope.

 

[LenL]

This happened this AM. I shut PiGS down and restarted but neither DVR looked for the guide after I did this. Should I try to force a guide update or wait till Tuesday AM to see if the DVR's try to get an update? Or I could force a guide update on one and see if the other tries to get one Tuesday.

 

[LenL]

Never mind they both are requesting a guide and updating. Wouldn't you know they would after I posted this.

 

[JHBrandt]

I wonder about the CM-7400 (Channel Master's "other" DVR, after they stopped selling the Pal but before the DVR+ came along). It had a paid guide, but that didn't save it from the DVR+ guide's fate; eventually the revenue from subscriptions didn't cover the costs, and the guide provider pulled the plug. Existing subscriptions were honored until they ran out, but no renewals were accepted.

I wonder if Rovi was the CM-7400's guide provider? If so, PiGS might be easily adapted to restore its guide too. Anyone have an old 7400 for @timothee to play with?

 

[flowersrj]

Just did a new install on a pi 3 with raspian buster lite. Python3.7.3 is installed by default but no pip3, dateutil, request or pillow.

Tried starting pigs but get error regarding "dateutil import parser"

Anyone have the same issue?

-rich

 

[timothee]

PiGS and Daylight Savings...

Daylight savings occurs on Saturday night. Since we fall back at 2am this coming Sunday, 2am becomes 1am again (the 1am time-slot gets repeated). The schedule is 100% zulu time which does not change, just the mapping of the programs to local time on your DVR. My dvr is currently showing 1am twice on Sunday morning as it should.

The SD/Rovi API's returns a field called TimeZones which you can see here. SD does not include any timezone information. So I created a timezone structure which you can see in your pigs.json file. I initialized it your your local time zone when pigs was started. I don't know what, if anything, this TZ info does to the dvr/ dvr schedule.
{ 'StartDateTime': '2020-03-08T08:00:00Z', <<< 8 - 6 is 2am winter to spring
'EndDateTime': '2020-11-01T07:00:00Z', <<< 7 - 5 is 2am fall to winter
'Offset': -300}] <<< current offset is -300/60 = GMT -5 hrs for CST
On the Menu>Settings>Time&Date there are 2 settings Auto Time & Date and Auto Apply Daylight Savings. But where does dvr get its T&D and DST info? what does manual mean? what does Auto/manual DST mean? does this info come from NTP? The problem becomes if this config info does anything somehow it needs to get updated after Sunday.

I tried editing the Tzinfo to modify the time change from 2am to 3 or 4 am, restarting pigs and doing a MGR but nothing changed on the dvr schedule (like 2am or 3am being repeated) so it almost appears dvr is using something else for its Time change algorithm (my T&D is set to auto).

If you feel like looking into this, Here is a direct link to BETA version 1.13c . It has some better error handling, I messed with the dns a little and it includes a browser url search function which can dump some schedule info right from the PiGS internal schedule. I didnt know if I could trust what dvr was displaying so I wanted to see what the raw Zulu based schedule looked like before dvr got a chance to manipulate it. see ReleaseNotes.txt for full details. There are search examples in the notes.

To display 11/1 00:00 GMT for channel 15.1, the search looks like this:
http://192.168.1.200/search?expand=&duration=1*24*60&startdate=2020-11-01T00:00:00Z&zulu=true&channel=15.1&title=&copy=
There are some weird things in the SD schedule like a 60min Castle episode that says its 120 minutes long. my offset is -5:00 so 05:00 is 00:00 midnight.
After that I think my offset changes to -6:00? so the 07:02 castle is at 1am local time I guess.

Chan	Date-Time(offset=0)	Dura	Title	Description
15.1	2020-11-01T00:00:00Z	60	Weakest Link	"Whose Brain Is Still on Hold With Tech Support?." S1, E4. Aired: 2020-10-13. Eight strangers test
15.1	2020-11-01T01:00:00Z	60	Ellen's Game of Games	"Party in the Goo. S. A.." S3, E9. Aired: 2020-03-10. Volunteers from Ellen's studio audience play
15.1	2020-11-01T02:00:00Z	60	Saturday Night Live	(New) An ensemble performs sketch comedy. Cast: Kenan Thompson, Kate McKinnon, Cecily Strong, Aidy B
15.1	2020-11-01T03:00:00Z	29	NBC 15 News at 10	(New) Aired: 2006-04-03. Local and regional news coverage.
15.1	2020-11-01T03:29:00Z	93	Saturday Night Live	(New) "John Mulaney; The Strokes." S46, E5. Aired: 2020-10-31. Host John Mulaney; The Strokes perfo
15.1	2020-11-01T05:02:00Z	120	Castle	"An Embarrassment of Bitches." S4, E13. Aired: 2012-01-23. The investigation into the death of a fa
15.1	2020-11-01T07:02:00Z	60	Castle	"The Blue Butterfly." S4, E14. Aired: 2012-02-06. Castle and Beckett must investigate a mysterious
15.1	2020-11-01T08:02:00Z	30	1st Look	"In Search of the Truth." S2018, E17. Aired: 2018-10-27. Johnny Bananas seeks out the truth about t
15.1	2020-11-01T08:32:00Z	30	Open House NYC	"Presents: George to the Rescue -- Racquel." Aired: 2020-10-24. Brokers and buyers participate in s
15.1	2020-11-01T09:02:00Z	28	Open House NYC	(New) "Presents: George to the Rescue -- Northwell." Aired: 2020-10-31. Brokers and buyers particip

 

[timothee]

Just did a new install on a pi 3 with raspian buster lite. Python3.7.3 is installed by default but no pip3, dateutil, request or pillow.
Tried starting pigs but get error regarding "dateutil import parser"
Anyone have the same issue?
-rich

did you just try pip? pip and pip3 have different names so python 2.7 can exist with 3.x
is 2.7 installed ? try python --V

 

[frank70]

Just did a new install on a pi 3 with raspian buster lite. Python3.7.3 is installed by default but no pip3, dateutil, request or pillow.

Tried starting pigs but get error regarding "dateutil import parser"

Anyone have the same issue?

-rich

Try this (the first one isn't terribly obvious, but a quick online search found it):

sudo apt install python3-pip
sudo pip3 install requests
sudo pip3 install python-dateutil
sudo pip3 install pillow

 

[flowersrj]

Thanks Frank70

 

[flowersrj]

Timothee,

On a whim I installed PIGS 1.1 on a WiFi based Raspberry Pi-0 W with Buster release and SystemD service to control it.

I assume no one has tried this before.

The first download from Schedules Direct seemed successful. See attached screen attachments.

Not running the DNS server. My Linksys router runs OpenWRT and I have modified its HOSTS file for the EPG/ECHOSTAR entries.

Will check it in a few days.

My production PIGS is running on a ethernet based PI-3 which I'd like to instead dedicate to Home Assistant provided this Pi-0 installation works out.

If you want me to check something or provide more printscreens just let me know.

-flowersrj

 

[frank70]

On a whim I installed PIGS 1.1 on a WiFi based Raspberry Pi-0 W with Buster release and SystemD service to control it.
I assume no one has tried this before.

Both @timothee and I have tried it on a Pi Zero W and yes, it works very well. Mine uses the full Buster release of Raspbian and I can control it via RDP and/or VNC and/or SSH (but I don't technically have to do any of that because PiGS is set up to autostart). It's been keeping 2 DVR+s up-to-date for many weeks. See photo here: Post 315. No reason to use v1.1 when v1.12 is the latest release.

 

[flowersrj]

Go ahead, burst my bubble.

 

[timothee]

My production PIGS is running on a ethernet based PI-3 which I'd like to instead dedicate to Home Assistant provided this Pi-0 installation works out.

Why can't your Pi 3 run both apps? Pigs requires very little cpu power - it just moves text around...