[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?