Duplicate season recordings

[djtaylor]

I think there's a problem with season recordings where the time slot changes?

I have noticed that I have a few instances where there are overlapped recordings on some shows for example, a time slot where it records 15:55 to 16:55 and then another of the same show 16:00 to 17:00.

Given that GBPVR sets up recording and allocates a tuner when it finds a new recording (at least that's how I understand it), it looks like although i'm doing a full EPG update, the show time changes slightly and hence it looks like GBPVR is seeing this as a new instance of the show and allocating a second tuner to the same show.

When I view the EPG via the web interface, I don't see these slightly overlapping instances of the same show.

This is a bit frustrating as yet again, i've got a couple of instances where two shows have overlapped like this on two seperate channels with the result that it thinks I need 4 tuners!

Am I correct in my understanding of how season recordings are set up and is there a neat solution to this at all?

Thanks
David.

[sub]

How are you doing your EPG update? The 'complete epg reload' logic that deletes the listings from the database, and deletes any pending season recordings, only runs as part of the automated EPG update.

The closest thing you can do to simulate it manually is go into each capture sources and click the 'Empty EPG' button, (you may now want to check in the 'pending' recordings screen to see they've been deleted), then update the EPG to get it to reload and reschedule.

[User]

I have seen this too. I think it's bad Zap2it data. On one show that is now on break for a month the guide comes in reularly as having two time slots, in tv guide there is a 1 minute sliver showing and if the info for the sliver is looked at it shows 9:00 - 10:00, then I look at the show to the right of the sliver and its time shows 9:01 - 10:00. It's the same show listed twice with those two sets of times. Have guide data set to do a complete reload. Caused conflicts every week so I removed the recurring recording and set a new one to record for the 9:00 - 10:00 slot for when the show returns to air, which I hope will fix the conflict when I had it on season recording.

[djtaylor]

How are you doing your EPG update? The 'complete epg reload' logic that deletes the listings from the database, and deletes any pending season recordings, only runs as part of the automated EPG update.

I have the check box marked "Complete EPG reload" checked.

EPG update is being done via XML file, automatic update at 7:00AM

I have 3 tuners, all updating from the same XML file, is that wrong? If I don't do that, I can't tune the channels.

Here's an example, Dancing on Ice, you'll see the selected item is the one that starts at 7:00 yet the show continues beyond and there's another instance at 7:10.

http://www.nodomainname.co.uk/gbpvr/epg.jpg

David.

[djtaylor]

I have seen this too. I think it's bad Zap2it data.

I don't use zap2it, I use XML tv data, however, clearly when the show time is updated, something is going wrong.

David.

[sub]

Was this the original show you used to create the season recording? If so, there is a known bug around this first episode that could cause the problem, but all future episodes should be unaffected.

This bug occurs because the original programme cant be removed from the database because it is still referenced by the season recording.

[djtaylor]

Not sure I understand exactly what you mean?

Do you mean, "was the earlier timed slot the first episode?"

or do you mean, "was the one in my example screen the first episode?"

I'll have a look through the database to see what times are set up for. Since you already know it to be a bug, I'll happily accept it as that, not much point telling you more about it I guess.

Thanks
David.

[sub]

Using your example, let me explain it this way. Imagine its Saturday the 18th, and I'm in the TV Guide. I decide want to record 'dancing on ice'. I bring up the show's details (dancing on ice, sat 18th, 19:00 - 21:00) and schedule a season recording. It creates pending recordings recordings for this "original" episode (sat 18th), and three more episodes (sun 19th 19:00 - 21:00, mon 20th 19:00 - 21:00, tue 19th 19:00 - 21:00).

With the bug I mentioned, this original episode (sat 18th) will not never be deleted from the database when it does a complete EPG reload, so can result in the an overlap or conflict if the time of the original show moves. This will not happen if any subsequent episode (Sun 19th, Mon 20th etc) has its time changed, so is only a problem for the "original" episode.

Hopefully that makes sense.

Even though its bug (or flawed logic), I'm unlikely to change it anytime soon. Its pretty rare, and a hassle to change. Its not caused many problems over the life of GB-PVR.

[djtaylor]

Ok, I get it, except that these aren't the first recordings but every subsequent time it seems that there's this overlap.

I'll keep an eye on it and see if I can pin it down better, just in case it's a variant of that bug.

Cheers
David.

[Ton]

Hey,

I've seen this too. The problem (for me) is, that the data in the XML-TV changes.

For example:

I have 7 days of EPG-data, so let's say the show shows up on monday, the start-time in the EPG is then 22:00.

Then, on wednesday the schedule changes, it's now scheduled for 22:10.

Because the show is already scheduled (by Season recordings), it won't delete the original entry. The show is now scheduled twice....

This is the reason I have switched to "PriorityRecordings", and I have added the "DeleteSchedule" utility. Now, each day "PriorityRecordings" delete's all scheduled shows, then (after the EPG update) it reschedules them...

I'm not sure this is what's happening on your end, but that's what I had...

I am working on an "EPGDiff" tool that should solve this problem once and for all...