Problems skipping last episode in series.

[MymsMan]

Good idea, thanks, I've done the same here.

Well I now have two copies of 'Death in Paradise' - the skip didn't work

 

[af123]

Well I now have two copies of 'Death in Paradise' - the skip didn't work

Likewise! Plan B then...

 

[af123]

(as a slight aside, mine are called Death in Paradise_20170223_2059 (HD version) and Death in Paradise_20170223_2100 (SD). I wonder whether that's luck or whether it did something about a name collision)

 

[prpr]

I wonder whether that's luck or whether it did something about a name collision

I think the latter. ISTR noticing this when accidentally setting the same programme on both SD and HD.

 

[MymsMan]

Likewise! Plan B then...

Well you know you have another test window on Sunday with the end of Dragons otherwise you will be hunting for other end of series!

Out of curiosity do you know the purpose and format of the aulEventToRecordInfo field - it looks odd

(as a slight aside, mine are called Death in Paradise_20170223_2059 (HD version) and Death in Paradise_20170223_2100 (SD). I wonder whether that's luck or whether it did something about a name collision)

I have the same names as you - I have always but it down to slight variations in the broadcast timings.

 

[MontysEvilTwin]

Re. the filenames, the high def. version seems to start a few seconds after the standard def. broadcast. If they have the same time in the filename, a suffix of '(1)' is added to the second recording.

 

[af123]

Out of curiosity do you know the purpose and format of the aulEventToRecordInfo field - it looks odd

Yes, it's sets of 32-bit numbers which are <Service ID> <Start Timestamp> <End Timestamp> <Event ID> representing the upcoming episodes to be recorded. They usually correspond to the CRIDs in the szEventToRecord field. Skip removes the entry from that list too - see rsv::set_skip(). (aul = array of unsigned long?)

The presence of the upcoming episode in the szRecordedProgCrid field is stopping re-population of aulEventToRecordInfo and szEventToRecord but it looks like the Humax is using the hsvc & usevtid fields to find the event in this case.

I already update the hsvc, usevtid and nsttime fields to those of the next event when skipping an episode but if the next episode is not yet known then I will need to do something else with those. Where there has been a previous recording in the series I can use usLastRecordedEvtId, otherwise I may have to try setting the last event ID to 0 and the nsttime field to something in the past.

 

[prpr]

aul = array of unsigned long?

Yes. Blame the Hungarians.

 

[af123]

1.4.0-11 is now in the beta repository and contains a test fix for this. I've installed it and set the Dragon's Den episode to skip again.

It's potentially confusing but since I don't know the timestamp of the last recorded episode in the series, I'm setting it to 24 hours before the time at which it was skipped. That may need more refinement!

 

[MymsMan]

Success, Dragons den is not recording

 

[af123]

Same here : )
Not even a DD folder.

 

[af123]

Next test then. I've just scheduled and skipped Planet Earth II on BBC Four, Tue 28 Feb 2017 20:00.
When next week's episode appears in the EPG, hopefully that will appear as normal.

 

[af123]

Today, now that the EPG data covers next Tuesday, Planet Earth II is showing as scheduled for next week.

 

[af123]

Just to close this one off, the fix for this is now in the generally available web interface release. Thanks to those who reported it and helped with the testing (and sorry to MymsMan again for missing his original report some time back!)