Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £129! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £179! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[Zgemma H7] Summer time correction for timer crossing time change applied twice?

  • Thread starter Thread starter BrokenUnusableAccount
  • Start date Start date
I've probably lost track of it all Brian. The program in red in the epg includes padding so that's probably why there's an overlap. It looks to be just over 2 hours long there which you believe to be correct?
 
I'd say that the solid red recording icon is a clear indication of when the programme ends.

Guides I've looked at say 23:10 to 02:15.
 
I'd say that the solid red recording icon is a clear indication of when the programme ends.

Guides I've looked at say 23:10 to 02:15.
IMDb has the film as 116mins.
125mins allows for 9mins of adds. Which is possible.
185mins would allow for 69mins of adds, which isn't possible for C4.

The real question shouldn't be about how long the recording is/was, but rather why the two screen shots in the OP show different time ranges for the same programme.
The timer states 23:08 -> 03:17 (189mins)
The EPG shows ~23:10 -> ~02:15.

The timer duration shows that the DLST switch is known about (otherwise it would be 249mins).
So the question is why the end of the timer is wrong (and hence Climax is being shown as part-recorded).

I'm wondering whether, at the time the timer was set, the data was wrong (so the timer was wrong) but has since been corrected (so the EPG is correct).
 
IMDb has the film as 116mins.
125mins allows for 9mins of adds. Which is possible.
185mins would allow for 69mins of adds, which isn't possible for C4.

The real question shouldn't be about how long the recording is/was, but rather why the two screen shots in the OP show different time ranges for the same programme.
The timer states 23:08 -> 03:17 (189mins)
The EPG shows ~23:10 -> ~02:15.

The timer duration shows that the DLST switch is known about (otherwise it would be 249mins).
So the question is why the end of the timer is wrong (and hence Climax is being shown as part-recorded).

I'm wondering whether, at the time the timer was set, the data was wrong (so the timer was wrong) but has since been corrected (so the EPG is correct).

I now think it could be that the duration of WWZ in the EPG was always wrong. The grid EPG I took a screen shot of might hide the wrong duration because the next program at 02:15 overwrote the end of the oversized block that would have been drawn for WWZ. I think I used to see that happen when there were incorrectly placed events that overlapped because of the 0x20000 extra seconds bug (now fixed in the build I'm running).
On Saturday night I may never have looked at the EPG in a form that would better give away if programs in the EPG were overlapping in time.

However as pointed out by ccs the solid red icon showing seems on the face of it to rule it out.
But without reading and understanding all the relevant code I can't say that for sure.

The half red icons are just because I always ask for 2 minutes pre and post margin in my timers. Unnecessary in most cases I know, but that's how I do it.
 
Last edited:
Fwiw, a few observations, mostly uninfoirmed speculation and no answers ;) ...

Purely for French-language educational purposes, I set a manual timer for 'Climax' (obvs. absolutely nothing to do with sex or drugs):

/etc/enigma2/timers.xml
Code:
<timer begin="1616893920" end="1616900400" serviceref="1:0:19:4500:4084:233A:EEEE0222:0:0:0:" repeated="0" rename_repeat="1" name="Climax" description="(2018) Hallucinogenic thriller. A group of dancers gather in a deserted building. But the sangria is spiked. In French/subs. Adults only: strong language/violence/self-harm/drugs/sex.  [S]" afterevent="auto" justplay="0" always_zap="0" pipzap="0" conflict_detection="1" descramble="1" record_ecm="0" isAutoTimer="0" eit="11296">
<log code="5" time="1616893900">activating state 1</log>
<log code="0" time="1616893900">Found enough free space to record</log>
<log code="0" time="1616893900">Filename calculated as: &apos;/media/hdd/TV/20210328 0212 - Channel 4 HD - Climax&apos;</log>
<log code="6" time="1616893900">prepare ok, waiting for begin</log>
<log code="5" time="1616893920">activating state 2</log>
<log code="11" time="1616893920">start recording on tuner: A</log>
<log code="5" time="1616900400">activating state 3</log>
<log code="12" time="1616900400">stop recording on tuner: A</log>
</timer>
That all worked beautifully: deep standby to full recording, some padding, .meta file shows duration of just under 108 minutes. (Before this thread I thought the box had to be on to 'clock' any daylight-saving shift).

The EPG recording icon isn't necessarily where the recording ends -- it sits right-justified in the visible part of the programme field and we might be looking at a rendering glitch when an hour's been taken out of the timeline, as shown. Or, like you say, on-overlap. I wonder if any of the programme data files, .eit, etc, have anything to say about whether the broadcaster sent a duff end time. (If I had to guess, I'd say not-guilty).
 
I wonder if any of the programme data files, .eit, etc, have anything to say about whether the broadcaster sent a duff end time. (If I had to guess, I'd say not-guilty).
I think each program has a start time and a duration, so it would be the duration that might have been sent with an extra hours added.
I saved the meta files, though right now, I don't know how to interpret most of them.
View attachment WWZmetadata.zip
 
I think each program has a start time and a duration
I read somewhere that the .meta duration field in "PTS units" or similar and divide by 90,000 to convert to seconds. That's be 188.96 minutes in this case -- but is the pts value sent or calculated from 'something'. I've no idea but I'll try and find that link...

EDIT: here...
Code:
https://github.com/libo/Enigma2/blob/master/doc/FILEFORMAT
 
Last edited:

OpenViX Feeds Status

Back
Top