[schedchk] auto fix schedule changes - a proposal

MymsMan

Ad detector
I think the following idea would reduce the problem of missed recordings when the schedule is changed at short notice due to special events, news events or overrunning sporting events.
This ideas does depend on the broadcasters updating the broadcast EPG data promptly which unfortunately doesn't always happen so this wont be infallible.

Even when there is plenty of notice of the schedule change the Humax sometimes does not pick up the change automatically as noted here and here among others.

The idea is a new package, schedchk, which would run at every auto processing interval which would:

For every recording scheduled in the next three hours(1) check whether the times in the EPG match the recording times (skip if EPG data is not available)
If the programme has been delayed, adjust the recording schedule times(2)
If the programme is not in the EPG at original time (& not delayed) cancel the recording.

For each cancelled recording search entire EPG for program crid to check for moved channel or alternative showing and if found schedule the alternative showing as a one off recording(3)

For each series in the recording schedule check for episodes added to the EPG that are not already in the series recording schedule and add them to the series recording.

I don't think this would be too hard to implement but I don't have the time at the moment.
Maybe this will inspire someone to take it on or suggest improvements to my ideas,
testing would be tricky since schedule changes cant be predicted but Wimbledon often creates a few.

Notes:
(1) Time range could be adjustable, and once a day check entire schedule. Could always check entire schedule if not too slow.
(2) I wonder if we can change the end time of an active recording to cope with an overrunning recording without AR
(3) I suggest cancelling recordings before attempting to reschedule to reduce the risk of apparent conflicts
 
Last edited:
Note there is a risk that the available EPG data does not cover the full week at any one time. The package would probably need some kind of safeguard to prevent this causing problems.

If the programme is not delayed or in the EPG at original time cancel the recording.
What? I've not been through it with a fine toothed comb, but this doesn't feel right.
 
Note there is a risk that the available EPG data does not cover the full week at any one time. The package would probably need some kind of safeguard to prevent this causing problems.


What? I've not been through it with a fine toothed comb, but this doesn't feel right.
Good points,

There would need to be checks for missing EPG data and only apply the checks when there is EPG data for the channel and time to check against.

I messed up the wording for that check and will update the wording, it was intended to cover the case where the programme has been moved to another channel or cancelled rather than delayed on the same channel.
 
This package would address issues which as far as I was concerned the t2 was doing from box opening. I was not aware this was happening. Are there other freeview recorders which do this automatically?
 
Sounds good! Would this proposal cover the problem where a broadcaster drops a particular showing from time to time during a series run, which normally causes the series link to silently die prematurely for anyone who chose to series link that particular timeslot... ?

Another annoyance of mine with Freeview+ boxes are series links which wonder off their timeslot. I normally pick an off peak early hours timeslot to try to avoid clashes at the peak 9-11 recording times. When rescheduling the next episode Freeview+ boxes have a habit of reverting back to the first (usually peak) showing. It would be nice if the above proposal could detect this and switch the series link back to the original timeslot assuming its still available..
 
Sounds good! Would this proposal cover the problem where a broadcaster drops a particular showing from time to time during a series run, which normally causes the series link to silently die prematurely for anyone who chose to series link that particular timeslot... ?
I would hope so since there should be no 'unable to track recording' failed recording errors.
Another annoyance of mine with Freeview+ boxes are series links which wonder off their timeslot. I normally pick an off peak early hours timeslot to try to avoid clashes at the peak 9-11 recording times. When rescheduling the next episode Freeview+ boxes have a habit of reverting back to the first (usually peak) showing. It would be nice if the above proposal could detect this and switch the series link back to the original timeslot assuming its still available..
AFAIK there is no linkage between a series and a particular timeslot - everything is based of the series CRID so the News at 10 had a series CRID but episodes of the News a 10 could be broadcast at any time of the day and still be recorded, ITV+1 ( www.itv.com/18585504) and ITV HD ( www.itv.com/22070598) have different series CRID from ITV (www.itv.com/182223 ) but all three use the same episode CRID for tonights broadcast ( www.itv.com/252731672). Similarly where a programme is repeated later on the same channel it should have a different series crid
I am not certain what happens when a programme is moved from BBC1 to BBC2 - I think it should keep the same series CRID and the Humax should be smart enough to track the change but that it often doesn't.

By scheduling one-off recordings when it is necessary to switch to an alternate showing schedchk would not be changing the series CRID so there shouldn't be a problem with time slots.
Some programmes have neither CRID or series CRID (on shopping channels) so schedchk would not do anything with those but I doubt many people record those, nor would it touch manual timer recordings.
 
I am not certain what happens when a programme is moved from BBC1 to BBC2 - I think it should keep the same series CRID and the Humax should be smart enough to track the change but that it often doesn't..

I thought it never did that.
 
oh man, I just found another instance where I needed this "maybe to come to life" package.

I'll just use the refresh for now, but I'm surprised to see the phenomenon so often.
 
I've just uploaded a beta version of the rsvsync package which supports refreshing schedule entries without a reboot. It seems to take up to a minute before the Humax software re-populates the event list. If you subscribe to the beta repository it should appear as an update for you.
 
Last edited:
I'ts just uploaded a beta version of the rsvsync package which supports refreshing schedule entries without a reboot. It seems to take up to a minute before the Humax software re-populates the event list. If you subscribe to the beta repository it should appear as an update for you.
I have installed the updates and refreshed BBC News at 10, 10+ minutes later the schedule only shows todays edition.
Code:
919    Fri Jun 30 20:44:24 2017: Loading schedule information to HumaxTV binary.
918    Fri Jun 30 20:44:24 2017: Final schedule entries: 42
917    Fri Jun 30 20:44:24 2017: Slots: +61
916    Fri Jun 30 20:44:24 2017: Refreshing slot 61
915    Fri Jun 30 20:44:24 2017: Found slot 61 for 3/131100/1498856400/46356
914    Fri Jun 30 20:44:24 2017: Opening /var/lib/humaxtv/rsvp.db
913    Fri Jun 30 20:44:24 2017: Schedule saved.
912    Fri Jun 30 20:44:24 2017: Nugget is available.
911    Fri Jun 30 20:44:24 2017: Real-time mode.
910    Fri Jun 30 20:44:24 2017: rsvsync starting, version 1.1.12.
Should I have done a reboot to ensure it was all fully installed?

NB Schedule did repopulate after recording tonight's News
 
Last edited:
That log doesn't show any problems - anything in nugget.log?
I've tried it several times on series from Pop with lots of upcoming episodes and it has always repopulated fairly quickly. I'll do some more testing.
 
Code:
974    [nugget]: Fri Jun 30 23:39:30 2017:     - Sat Jul  1 21:34:30 2017
973    [nugget]: Fri Jun 30 23:39:30 2017: Adding timer(1498941270)
972    [nugget]: Fri Jun 30 23:39:30 2017: Ready 1498941270 - Sat Jul  1 21:34:30 2017
971    [nugget]: Fri Jun 30 23:39:30 2017:  Wake 1498941300 - Sat Jul  1 21:35:00 2017
970    [nugget]: Fri Jun 30 23:39:30 2017:       Fri Jul  7 22:00:00 2017 +25m
969    [nugget]: Fri Jun 30 23:39:30 2017:  [5] 131100,1499461200,1499462700,46599
968    [nugget]: Fri Jun 30 23:39:30 2017:       Thu Jul  6 22:00:00 2017 +30m
967    [nugget]: Fri Jun 30 23:39:30 2017:  [4] 131100,1499374800,1499376600,46571
966    [nugget]: Fri Jun 30 23:39:30 2017:       Wed Jul  5 22:00:00 2017 +30m
965    [nugget]: Fri Jun 30 23:39:30 2017:  [3] 131100,1499288400,1499290200,46543
964    [nugget]: Fri Jun 30 23:39:30 2017:       Tue Jul  4 22:00:00 2017 +30m
963    [nugget]: Fri Jun 30 23:39:30 2017:  [2] 131100,1499202000,1499203800,46470
962    [nugget]: Fri Jun 30 23:39:30 2017:       Sun Jul  2 22:00:00 2017 +20m
961    [nugget]: Fri Jun 30 23:39:30 2017:  [1] 131100,1499029200,1499030400,46418
960    [nugget]: Fri Jun 30 23:39:30 2017:       Sat Jul  1 21:50:00 2017 +20m
959    [nugget]: Fri Jun 30 23:39:30 2017:  [0] 131100,1498942200,1498943400,46322
958    [nugget]: Fri Jun 30 23:39:30 2017:   Events: 1FP.BBC.CO.UK/5A7JTE|1FP.BBC.CO.UK/5A7JWQ|1FP.BBC.CO.UK/5A7KEB|1FP.BBC.CO.UK/5A7KEC|1FP.BBC.CO.UK/5A7KED|1FP.BBC.CO.UK/5A7KEE|
957    [nugget]: Fri Jun 30 23:39:30 2017:   Last Event: 46356
956    [nugget]: Fri Jun 30 23:39:30 2017:   Recorded: 1FP.BBC.CO.UK/5A7KEA|1FP.BBC.CO.UK/5A7KE9|
955    [nugget]: Fri Jun 30 23:39:30 2017:   CRID: 2/[FP.BBC.CO.UK/KCI4LO]
954    [nugget]: Fri Jun 30 23:39:30 2017:    @ 1498942200 (Sat Jul  1 21:50:00 2017)
953    [nugget]: Fri Jun 30 23:39:30 2017:   BBC News
952    [nugget]: Fri Jun 30 23:39:30 2017: Processing slot +61 (61)
951    [nugget]: Fri Jun 30 23:39:30 2017: slots(42, +61)
950    [nugget]: Fri Jun 30 23:39:30 2017: schedule reload complete (42).
949    [nugget]: Fri Jun 30 23:39:30 2017: Closing database.
948    [nugget]: Fri Jun 30 23:39:30 2017: Re-loading schedule database (42).
947    [nugget]: Fri Jun 30 23:39:30 2017: schedule save complete.
946    [nugget]: Fri Jun 30 23:39:30 2017: schedule save starting.
945    [nugget]: Fri Jun 30 20:44:24 2017:     - Fri Jun 30 21:44:30 2017
944    [nugget]: Fri Jun 30 20:44:24 2017: Adding timer(1498855470)
943    [nugget]: Fri Jun 30 20:44:24 2017: Ready 1498855470 - Fri Jun 30 21:44:30 2017
942    [nugget]: Fri Jun 30 20:44:24 2017:  Wake 1498855500 - Fri Jun 30 21:45:00 2017
941    [nugget]: Fri Jun 30 20:44:24 2017:   Events:
940    [nugget]: Fri Jun 30 20:44:24 2017:   Last Event: 46412
939    [nugget]: Fri Jun 30 20:44:24 2017:   Recorded:
938    [nugget]: Fri Jun 30 20:44:24 2017:   CRID: 2/[FP.BBC.CO.UK/KCI4LO]
937    [nugget]: Fri Jun 30 20:44:24 2017:    @ 1498856400 (Fri Jun 30 22:00:00 2017)
936    [nugget]: Fri Jun 30 20:44:24 2017:   BBC News at Ten
935    [nugget]: Fri Jun 30 20:44:24 2017: Processing slot +61 (61)
934    [nugget]: Fri Jun 30 20:44:24 2017: slots(42, +61)
933    [nugget]: Fri Jun 30 20:44:24 2017: schedule reload complete (42).
932    [nugget]: Fri Jun 30 20:44:24 2017: Closing database.
931    [nugget]: Fri Jun 30 20:44:24 2017: Re-loading schedule database (42).
930    [nugget]: Fri Jun 30 20:44:24 2017: schedule save complete.
929    [nugget]: Fri Jun 30 20:44:24 2017: schedule save starting.
928    [nugget]: Fri Jun 30 20:44:24 2017: Persistent log starting, v0.97
927    +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
thanks BH

2833 Wed Jul 26 15:36:44 2017: Failed: no such table: skip (no such table: skip)
2832 Wed Jul 26 15:36:44 2017: - next event skip (721120:6134:1501614000)
2831 Wed Jul 26 15:36:44 2017: Setting skip on slot 52 (721120:6134:1501614000)
2830 Wed Jul 26 15:36:44 2017: Found slot 52 for 3/721120/0/6069
2829 Wed Jul 26 15:36:44 2017: Opening /var/lib/humaxtv/rsvp.db
2828 Wed Jul 26 15:36:44 2017: rsvsync starting, version 1.1.12.


the event I want to skip is the next one available. does the stuff above mean that it will skip it or that it will fail to skip it?
 
Back
Top