Covid-19 recording conflicts

/df

Well-Known Member
In the current circumstances a swathe of regular programmes that people might have on series record are not being produced, let alone broadcast: as an example, Match of the Day 2.

If a replacement programme is set to record, there is every chance that a conflict will be flagged. In this forum, I'm considering setting up recordings using the Webif, not with the remote control; in the latter case I seem to recall that the UI doesn't let you commit conflicting schedules.

What might then happen is discussed in this thread.

Based on this, recordings scheduled using AR should be fine, because the temporarily absent scheduled show will never be signalled and the replacement will be; when the temporarily absent scheduled show returns, the replacement won't be shown at the same time, if at all. As always, it depends on the broadcasters doing the right thing. Update: this did appear to occur as described.

Recordings scheduled using padding will get confused, if the original programme would have started before the replacement and the replacement programme is of a different length, and otherwise fragmentary recordings of what the old EPG data said was the end of the original programme might also be created.

Recordings scheduled using fixed times will fail unless the replacement programme starts before, or is within the period of, the original show, and in the latter case unwanted leader or trailer may be present.

Have I got this right?
 
Last edited:
I was under the impression that refreshing the recording scheduled would pickup the changes?

is there an automated way to do this?
 
The EPG data is being updated all lthe time from the broadcast stream, but the schedule is written into the rsv.db using the EPG data at the time of scheduling, indexed by the programme or series CRID.

Even if the schedule were updated from the current EPG data when a scheduled recording moved, it might not be correct to delete or skip a scheduled recording that went missing from the EPG: it might come back within AR search period. I assume that this is why I saw a conflict when adding a replacement show.
 
Even if the schedule were updated from the current EPG data when a scheduled recording moved, it might not be correct to delete or skip a scheduled recording that went missing from the EPG: it might come back within AR search period. I assume that this is why I saw a conflict when adding a replacement show.
I'm not sure how all this actually works, af123 might as he has had to dissect the relevant databases. I suspect future recordings are not in the database at all, only the next one. It seems unlikely there is a process constantly monitoring the EPG data stream for changes to schedule entries, but it can't only look at the next scheduled item because of the possibility that another item will be brought forward.

Somehow it also has to patch up after a failed or missed recording by looking for another entry with the same P-CRID.
 
There are some hints here and in the schema of rsv.db, which I've annotated below.
Code:
CREATE TABLE TBL_RESERVATION(
  ulslot INT,            /* slot! */
  ersvtype INT,          /* "Mode" 3 => recording, 2=> reminder */
  hsvc INT,              /* service ID */
  nsttime INT,           /* start time (epoch) */
  szsttime TEXT,         /* ISO date if reminder */
  nduration INT,         /* length of programme/s */
  erepeat INT,           /* repeat: 0..6 => no, daily, weekly, weekdays, weekends */
  usevtid INT,           /* (?) */
  szevtname TEXT,        /* programme name preceded by\x15 or \x10i7 (?) */
  ulPreOffset INT,       /* padding */
  ulPostOffset INT,      /* padding */
  ulProgramId INT,       /* 0? */
  ulSeriesId INT,        /* 0? */
  ucVolume INT,          /* 0? */
  ucInputMode INT,       /* 0? */
  usChNum INT,           /* 0? */
  ucRecKind INT,         /* 0 => programme, 4 => series */
  ucCRIDType INT,        /* 50 => series, or 0 */
  szCRID TEXT,           /* series CRID, or empty */
  szFPBRecPath TEXT,     /* destination folder for series recordings - ISTR setting this for non-series makes no difference */
  szRecordedProgCrid TEXT, /* actual programme CRIDs separated and terminated by '|' */
  szEventToRecord TEXT,  /* for a series, next P-CRID to record, or 0 */
  aulEventToRecordInfo,  /* some binary stuff (?) */
  bRecomRsv INT,         /* maybe set if scheduled via green button ? */
  usLastRecordedEvtId INT, /* same namespace as usevtid ? */
  eReady INT             /* =30 (?) */
);
 
Last edited:
AFAIK, 'Refresh Events' clears the future and past events lists (szRecordedProgCrid, szEventToRecord and aulEventToRecordInfo) of the database record but it does not populate them with future events.

This clears any skips you have set up and can lead to duplicate recordings of previously recorded episodes .

It also leaves a period when the schedule appears to be incomplete, The Humax periodically updates the schedule entry with future episode from the epg but I am not clear as to how frequently this occurs.
 
So it seems it does what I thought it did. Clear incorrect furure recordings.

Can I automate the action which pushing the button does?
 
Can I automate the action which pushing the button does?

Possibly if you are prepared to write some code.

I proposed an automatic schedule updater to handle the last minute switch of programmes to BBC2 that frequently occur around Wimbledon time and when major new events occur https://hummy.tv/forum/threads/schedchk-auto-fix-schedule-changes-a-proposal.7988/

So far this idea hasn't got off the drawing board. One problem is whether the epg data is updated frequently enough to detect last minute changes.
 
One problem is whether the epg data is updated frequently enough to detect last minute changes.
I have seen it work when events last longer. That means changes at the last minute, right?

If you mean write code having knowledge of coding, I do not
 
Possibly if you are prepared to write some code.

I proposed an automatic schedule updater to handle the last minute switch of programmes to BBC2 that frequently occur around Wimbledon time and when major new events occur https://hummy.tv/forum/threads/schedchk-auto-fix-schedule-changes-a-proposal.7988/

So far this idea hasn't got off the drawing board. One problem is whether the epg data is updated frequently enough to detect last minute changes.
Turns out I DO have the rsvsync prog.
How can I tell if it is working?
 
Turns out I DO have the rsvsync prog.
How can I tell if it is working?
The rsvsync changes allowed you to refresh the events without needing to reboot, they don't detect when it is necessary to refresh the events.
You can tell that is working by observing that future events disappear from the schedule entry and are later replaced by the currently scheduled events
 
but still something is going wrong because my schedule is showing entries which are non existent in the on the box epg , press guide on remote control.
 
Back
Top