scheduling changes not handled well?

[martint123]

I do see a line in your logs with
2009-10-19 02:01:03.130 VERBOSE [10] Emptying EPG...

I used to get an EPG error that prevented this happening (as sub referred to the 'none' in EPG source) and got similar problems to yourself. When I got rid of it and started getting the "emptying...." message then all my odd overlapping problems went away.

Ah - but I also see

2009-10-19 02:01:17.480 VERBOSE [10] Already has recording: EP006883590120
2009-10-19 02:01:17.480 VERBOSE [10] Already has recording: EP011063720018

Could it be that these EPG entries are ignored as having already been seen (I don't know much about this as this option isn't available over here).

[johnsonx42]

I think you're right. Obviously at 2:00am on 10-19, I didn't have those recordings on the disk (both were truly new episodes that didn't air until 8:00pm and 9:00pm). However, they were already scheduled.

I'll bet it's a flaw in the "don't record duplicates" logic that is causing this behaviour; that's why there aren't more reports of this, and why sub can't duplicate the problem.

Nice catch, thanks.

Sub, you home yet? I'm sure fixing all my problems is #1 on your to-do list after being away for weeks, right?

[martint123]

I think you're right. Obviously at 2:00am on 10-19, I didn't have those recordings on the disk (both were truly new episodes that didn't air until 8:00pm and 9:00pm). However, they were already scheduled.

I'll bet it's a flaw in the "don't record duplicates" logic that is causing this behaviour; that's why there aren't more reports of this, and why sub can't duplicate the problem.

Nice catch, thanks.

Sub, you home yet? I'm sure fixing all my problems is #1 on your to-do list after being away for weeks, right?

The recordings don't have to be on disk to be flagged as dupes.
As we don't use it, I've not looked into it, but I think it's something like they have been recorded in the past xxx days.
You are also reliant on your listing provider sending out the correct unique codes for this to work.

[johnsonx42]

Yes, i think it is 45 days or so. But no, that's not the issue... here's where I think the logic is breaking down, when the "Don't Record Duplicates" option is set:

1. GB-PVR gets an EPG update.
2. It goes through the schedule, and finds shows that need to be recorded.
3. It schedules the needed shows, and adds the episode number of each show to the duplicate list so that any other occurances of the show won't be scheduled.
--- all is well to this point ---
4. On a later date, GB-PVR gets a new EPG update.
5. It goes through the schedule, and finds shows that need to be recorded.
6. Any show whose Episode number is already in the duplicate list is not rescheduled.

Number 6 is fine as long as there has been no change to the scheduling. But if there has been any change, then the logic fails.

Whether the show has been moved just a tiny bit in the timeslot, to a new timeslot, to a new day, or cancelled altogether, the scheduler ends up ignoring changes to any existing scheduled recording that has an Episode number in the 'don't record duplicates' list.

This means that the Don't Record Duplicates option is pretty well broken.

For now the only choice is to just turn off the feature, but that's going to be unpleasant since I record some shows on channels that re-run the same episodes several times before going to a new episode, and they tend to run them at seemingly random time slots. I'll just have to keep an eye on things until sub can fix this.

[martint123]

I would have thought there would have been loads more reports of this problem if in (3) the database was updated at scheduling rather than recording.

Anyways - we (or you at least!) will have to await the boss's return to have a look.

[johnsonx42]

I'm right, I just know it, and I'll stomp my feet and hold my breath until you admit it too! :p

[beav_35]

I am also noticing that my recordings are not getting updated properly when the guide data changes. When some shows first make it into the xmltv.xml file there is no summary in the description but the summary is added in during later guide updates. These updates never make it into the gbpvr guide if the show is set to record. If they aren't set to record the descriptions are updated properly. Let me know if you would like to see my logs.

[johnsonx42]

Yes, actually I would like to see your logs. They might prove me wrong as to the root cause of this issue.

[beav_35]

Ok I have attached the logs.

This is an xmltv entry for a show that doesn't display the summary in the guide:

Code:

<programme start="20091023210000 -0500" stop="20091023220000 -0500" channel="I801.39492095.microsoft.com">
    <title>NUMB3RS</title>
    <sub-title>Hydra</sub-title>
    <desc>(2009-10-23) (605) The team searches for the daughter of a geneticist; Amita and Charlie talk about having kids; a dark secret is revealed.
(VCHIP:TV-14) (2009-10-23) (HDTV 16:9)
Actors: Rob Morrow, David Krumholtz, Judd Hirsch.
Guests: Keith David, Christian Camargo, Mia Barron.
Director: Ralph Hemecker.
</desc>
    <category>Drama</category>
    <category>Episodic</category>
    <category>Series</category>
    <length units="minutes">60</length>
    <episode-num system="dd_progid">EP00712872.0109</episode-num>
    <audio>
      <stereo>stereo</stereo>
    </audio>
    <new />
    <subtitles type="teletext" />
  </programme>

[johnsonx42]

Yep, same problem, same reason. Your log shows numerous occurrances of:

Code:

2009-10-18 05:04:22.218    VERBOSE    [11]    Already has recording: EP00713516.0102

I would say you've got precisely the same trouble - the recording service scheduled the recording based on the first incomplete entry in the EPG, and then when the EPG data changed later it won't accept the update due to the flaw in the "don't record duplicates" logic.

All we need now is for sub to come to our rescue.