Schedule Restore Failure

[EEPhil]

Parp! Sorry CJ.

 

[Black Hole]

Parp! Sorry CJ.

[sniggers off]

Yes, I am interested; I have just been away and disconnected for a bit!

Let's have the backup file then.

Offending file attached

 

[mr-b]

Hi

I've seen the ref to service numbers in the log after a schedule restore and wondered what they meant. Was there any conclusion?

  Backup version 2
Restoring scheduled events from /mod/var/backup/auto-2020-May-13-15:42.rbk...
  Restoring Location, Location, Location (4seven HD)
    Service number has changed 458897 -> 458900, fixing.
      AUL 4seven HD (458897 -> 458900)
      AUL 4seven HD (458897 -> 458900)
      AUL 4seven HD (458897 -> 458900)
      AUL 4seven HD (458897 -> 458900)
      AUL 4seven HD (458897 -> 458900)
      AUL 4seven HD (458897 -> 458900)

 

[MymsMan]

Hi

I've seen the ref to service numbers in the log after a schedule restore and wondered what they meant. Was there any conclusion?

The service number is an internal number associated with each channel allocated during tuning and which can change after a retune, these numbers are stored with each scheduled event so the restore has to update the schedule database with the new numbers.
Humax took the easy way out and just deleted the old schedule!

Confusingly the epg has a different set of internal numbers for channels so a lot of mapping has to go on.

 

[prpr]

It's a combination of transport stream and service index numbers from your tuning database.
They are meaningless in absolute terms.

 

[mr-b]

OK tx, so nothing to be concerned about then. I was sure there hadn't been a recent retune ... but it did say "fixing" i.e. implying that something had gone wrong.