AVS Forum banner

621 - 640 of 683 Posts

·
Registered
Joined
·
1,717 Posts
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.
 

·
Registered
Joined
·
264 Posts
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).
 

·
Registered
Joined
·
1,717 Posts
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.
 

Attachments

·
Premium Member
Joined
·
255 Posts
Discussion Starter #624
@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
 

·
Registered
Joined
·
1,717 Posts
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.
 

·
Premium Member
Joined
·
255 Posts
Discussion Starter #626
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
 

·
Registered
Joined
·
2,190 Posts
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?
 

·
Registered
Joined
·
2,190 Posts
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.

3047995
 

·
Registered
Joined
·
2,190 Posts
Never mind they both are requesting a guide and updating. Wouldn't you know they would after I posted this.
 

·
Registered
Joined
·
7,591 Posts
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?
 

·
Registered
Joined
·
97 Posts
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
 

·
Premium Member
Joined
·
255 Posts
Discussion Starter #633 (Edited)
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.

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

·
Premium Member
Joined
·
255 Posts
Discussion Starter #634
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
 

·
Registered
Joined
·
1,717 Posts
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
 

·
Registered
Joined
·
97 Posts
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. (y) 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
 

Attachments

·
Registered
Joined
·
1,717 Posts
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.
 

·
Premium Member
Joined
·
255 Posts
Discussion Starter #640
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...
 
621 - 640 of 683 Posts
Top