scheduling changes not handled well?

[johnsonx42]

I've had a couple of cases recently where there was an apparent scheduling change of a show already scheduled to record in gb-pvr (via a recurring recording), and it didn't handle it well.

In one case, The Biggest Loser was originally scheduled from 8:00pm-10:00pm, and gb-pvr had scheduled the recording accordingly. at some point the show was bumped back to 9:00pm, to make way for an nbc special about death-defying escapes or some such (you know, car crashes, stunts gone wrong, etc.). the TV Guide was a bit strange - it showed a 1 hour block of the biggest loser at 8:00pm, but said it was from 8:00pm to 10:00pm (ie, visually the block was 1 hour, but the text said 2 hours). Then at 9:00pm it showed a 2 hour block of the biggest loser, but again the text said 8:00pm to 10:00pm. Finally if I moved to the 11:00 hour (news or something), and then back to the 9:00-11:00 block, the text time would be correct. the death-defying special never appeared in the TV Guide. gb-pvr recorded from 8:00pm to 10:00pm, the original schedule.

A day or two later, Lie to Me was pre-empted by American Idol for two hours from 8:00pm to 10:00pm. Lie to Me was scheduled at 8:00pm for 1 hour. The TV Guide still showed Lie to Me at 8:00pm, and at 9:00pm it showed "No Show Details". gb-pvr recorded 1 hour of American Idol, but of course called it 'Lie to Me'.

(this in itself was no big deal to me, since I couldn't care less about American Idol, and Lie to Me wasn't actually on anyway... but let's say I had a recurring recording for both Lie to Me AND American Idol - even with two tuners it probably would not have picked up the second half of American Idol)

It appears to me from the behaviour that once a show is scheduled to record, it gets 'locked' in the database. if the epg data changes, the recording won't be adjusted; further since the TV guide draws from the same database, it won't display the new information either.

this doesn't come up very often I'd guess, only when there's a scheduling change after the epg data is first delivered and the recording is scheduled.

comments, thoughts?

p.s. sorry, I don't have any logs from those days.

[LewE]

I've had a couple of cases recently where there was an apparent scheduling change of a show already scheduled to record in gb-pvr (via a recurring recording), and it didn't handle it well.

It appears to me from the behaviour that once a show is scheduled to record, it gets 'locked' in the database. if the epg data changes, the recording won't be adjusted; further since the TV guide draws from the same database, it won't display the new information either.

this doesn't come up very often I'd guess, only when there's a scheduling change after the epg data is first delivered and the recording is scheduled.

comments, thoughts?

This is a similar problem with the xml processing by UltraXMLTVEnhancer ( and maybe xmltv too) in that once a program's listing has been selected from recording inside GBPVR if you revise how you want to enhance listings, Ultra won't reprocess those for shows marked to be recorded.

It does come up often enough that I, for one, would like to see the program(s) handle it better.

[johnsonx42]

I'm going to make the assumption the UltraXMLTVEnhancer is doing it's job just fine, but the GB-PVR database simply isn't going to accept any new data for a timeslot with a program already scheduled to record.

It just occurred to me also that downloading a long period of guide data is not a good idea given this behaviour. I currently download 10 days of data.

I had been thinking of going to 15 days of guide data, or even 22 days, so that for any given weekly show I watch I could look forward and see detail on the next two or three episodes.

Instead, perhaps it might be a good idea to go down to only a week or less; this will reduce the chance of this sort of scheduling issue occurring.

If my theory about what is happening is correct, I guess it becomes a wishlist item. If an EPG update results in a change to a show already set to record, the recording has to be flushed - if it's a recurring recording, just let it reschedule as normal. If it was a 'Record Once' recording, it would be nice to inform the user, perhaps via the conflict list (perhaps the conflict list might be expanded to be sort of a 'Recording Exceptions' list). But even if it just dumps the recording without a word, that's better than what it does now.

edit: wow, 400 posts in just 7 months. I've made quite a nuisance of myself, haven't I? I've learned quite a bit, and hopefully helped a few people along the way. No doubt I've butted into a few threads I shouldn't have, and probably annoyed sub once or twice. Here's to the next 400 posts... Cheers!

[sub]

The general story is that season recordings will get the times updated if they change (with the exception of the first episode which was used to create the season recording). When it does an EPG update, GB-PVR deletes all pending episodes of a season recording, then goes through the matching process again (looks for name matches etc), and reschedules them, which leads to them being the correct time.

One-off recordings, or the first episode in a season recording are not deleted and re-created (due to several complications with doing this).

[johnsonx42]

The general story is that season recordings will get the times updated if they change (with the exception of the first episode which was used to create the season recording). When it does an EPG update, GB-PVR deletes all pending episodes of a season recording, then goes through the matching process again (looks for name matches etc), and reschedules them, which leads to them being the correct time.

One-off recordings, or the first episode in a season recording are not deleted and re-created (due to several complications with doing this).

This definitely did not happen for me. Both of my problem recordings were season recordings, and were not the first recording of the season.

I guess I'll have to figure that either the problem was actually caused by the data from Schedules Direct (doesn't really fit all the symptoms, but who is to say since I don't have any logs or the original schedules direct data), or that I've encountered a bug in GB-PVR that is causing it not to behave as expected. Either way, I guess if it happens again I'll have to be quicker to get the logs and any possible screen shots of the described TV Guide weirdness.

Is there a file somewhere that contains the EPG download from Schedules Direct? If this were to occur again it would be helpful to see what exactly was in the last update.

Thanks for explaining what the expected behaviour is.

[sub]

This definitely did not happen for me. Both of my problem recordings were season recordings, and were not the first recording of the season.

I'm not aware of any issues with this, and unfortunately its pretty hard to guess without all the info available. To determine why it didnt, you'd really need the recording service logs from the night the schedule changed in the EPG.

Is there a file somewhere that contains the EPG download from Schedules Direct? If this were to occur again it would be helpful to see what exactly was in the last update.

There is some setting in the config.xml for saving the zap2it data, which results in a c:\zap2it.xml file. Schedules Direct is a renamed version of the old zap2it service.

[Reddwarf]

Now THAT is a problem that has bothered me for a long time! In particular one of the tv-stations that I frequently record from has a habit of moving programs some 10 - 15 minutes back and forth, if such a show is scheduled in gbpvr, it will stay scheduled, but there will be scheduled a new recording at the adjusted time in the updated xmltv. So the only way I'v har so far is to delete the original recording and stick with the one scheduled at the new time.

This must be a bug, right?

[roy]

I also see this all the time. Any scheduled season recording keeps the originally scheduled program if the listing changes. Would logs be helpful next time it occurs?

I use I-xmltv with Schedules Direct. The I-xmltv.bat is set to empty the epg. Would it be better to empty epg with updatepg.bat?

[sub]

Now THAT is a problem that has bothered me for a long time! In particular one of the tv-stations that I frequently record from has a habit of moving programs some 10 - 15 minutes back and forth, if such a show is scheduled in gbpvr, it will stay scheduled, but there will be scheduled a new recording at the adjusted time in the updated xmltv. So the only way I'v har so far is to delete the original recording and stick with the one scheduled at the new time.

This must be a bug, right?

I've just checked this here by editing some times in my xmltv file, then doing an Update EPG and seeing the new times in the updated recordings. It seemed to work fine.

If you post your GBPVRRecordingService.exe.log, should be able to check that its correctly emptying your EPG during the update process (or if there is some reason it isnt emptying it).

Do you have any capture sources setup which use the 'none' epg source option? This can cause the epg to not be emptied during the EPG update.

[johnsonx42]

Here's my log, just in case anything is useful there. I have two souces, both set to use Schedules Direct with the same lineup. I will also find and set the option in config to save the zap2it data.