Strange Pause/Resume behaviour

[escat]

For some time I've been experiencing strange behaviour with the pause and resume functions on playback:
1) after stopping and then resuming playback, the programme skips back to some time before the programme was stopped;
2) After pressing pause and then using trick-play - for example to skip over adverts - the playback again skips back to some time before the pause point.

Experimentation reveals the following:
a) it happens on more than one machine, with different remote controls;
b) the 'skip back point' is the same for the same programme recorded on different machines;
c) the behaviour is the same if a recording is played back on a machine different to the one on which it was recorded;
d) it doesn't happen on every recording;
e) some recordings have more than one 'skip back point';
f) I've only experienced it on programmes which have been cropped via the web-interface;
g) So far, I've found the behaviour on programmes recorded on BBC1 and on the Drama Channel (20).

Has anybody experienced anything like this, or got any insights as to what might be going on?

 

[prpr]

I've only experienced it on programmes which have been cropped via the web-interface;

Don't do that. It f***s up the .nts file and the timestamps in the .ts file. You may wish to experiment with regenerating the .nts file with sidecar. It may or may not improve things. You really need to re-do the timestamps, but it's a faff. Somebody posted some instructions - I forget who now - and I never got round to trying it.

 

[escat]

Don't do that. It f***s up the .nts file and the timestamps in the .ts file. You may wish to experiment with regenerating the .nts file with sidecar. It may or may not improve things. You really need to re-do the timestamps, but it's a faff. Somebody posted some instructions - I forget who now - and I never got round to trying it.

Thanks for your prompt reply. I had wondered something along these lines, but I've been using crop for years, and only experienced these problems recently. I'll try the sidecar suggestion, thanks.

Your comment about timestamps helped me with a more effective forum search - leading to the following post from November 2021:

Numerous time I'm finding that the position tracking of my playback position (trick-play?) is wrong by many minutes (perhaps 10-20?).
This is especially the case for HiDef recordings.
These are processed files; decoded, ad-detected (a striped out copy).
Resume MAY also fail, putting me back many minutes.
Playback position can seem stuck (it shows on my front display or playback bar) then when I next notice/look it's jumped forward many minutes (but may be reading wrong again).
Although I'm not sure, I think un-shrunk recordings work OK (so probably BBC, although I will also shrink most of these, manually or dir flag)

Which sounds like my problem - except all my recordings are in SD. You and Black Hole responded along similar lines at the time. But I must have used crop hundreds of times since then without encountering this problem - strange. Anyway, thanks again.

 

[MymsMan]

Which sounds like my problem - except all my recordings are in SD. You and Black Hole responded along similar lines at the time. But I must have used crop hundreds of times since then without encountering this problem - strange. Anyway, thanks again.

SD or HD makes no difference for the problem which can also occur when cropping with detectads, why it only some times causes a problem is, AFAIK, not really clear - if it it was a more frequent problem there would be more pressure to to actually fix it!

 

[RobH1]

I had this problem for a year or two, plus recordings randomly skipping a couple of minutes. ITV4 and Quest being the main culprits for the former and BBC1 for the latter.
I upgraded the CF from 3.10 to 3.13 and ran fixdisk and all seems to be ok now.

 

[MymsMan]

I had this problem for a year or two, plus recordings randomly skipping a couple of minutes. ITV4 and Quest being the main culprits for the former and BBC1 for the latter.
I upgraded the CF from 3.10 to 3.13 and ran fixdisk and all seems to be ok now.

CF level and fixdisk will have no effect on this problem but might have fixed a disk problem causing glitches during recording/play back

 

[RobH1]

Sure, I guessed as much, but I had used fixdisk prior to upgrading to no avail. I tend not to worry over these things as I am recording less these days.

 

[escat]

Thanks for all the input, which has helped me narrow down the problem - for those who are interested )

The fact that the problem happens in exactly the same place on two different machines suggests that it is not caused by a machine fault. It also suggests that, while the problem is unpredictable, it is not completely random. Indeed, it probably suggests that it might be something in the specific TS stream that triggers it - but is not necessarily the root cause of it.

if it it was a more frequent problem there would be more pressure to to actually fix it

But I must have used crop hundreds of times since then without encountering this problem

One possibly is that there had been a regression in the code, but the fact that no one else seems to have been troubled by it makes that unlikely. I uncovered the problem while watching a six-part series that necessitated a lot of pausing and trick-playing. Every episode had 'skip-back' problems, sometimes several. I wouldn't have noticed these if I had just watched the programmes straight through. So, maybe these problems have been there all the time in programmes that had been cropped.

Don't do that. It f***s up the .nts file and the timestamps in the .ts file. You may wish to experiment with regenerating the .nts file with sidecar. It may or may not improve things. You really need to re-do the timestamps, but it's a faff. Somebody posted some instructions - I forget who now - and I never got round to trying it.

I first deleted all three sidecar files from a recording that had the problem. Playback was fine: the limited skip-forward and skip-back functions worked - even across the 'suspect' 'skip back point'. The stop and resume functions worked ok. (BTW, I discovered that the .hmi file - which is only produced after the recording is stopped - seems merely to be a vehicle for recording the resume point, at offset X'0100').

This seemed to support the suggestion that the problem is caused by the .nts file that was produced by the crop function. But it also suggests that the crop function does not tamper with the timestamps in the .ts file itself.

As suggested, I did then re-create the .nts files using sidecar. At first blush, this seems to have fixed the problem. But I'll continue checking.

I also did a quick visual comparison of the pairs of nts files: that in the original recording vs that produced by sidecar. I can comment on this later if anyone is interested?

 

[prpr]

I discovered that the .hmi file - which is only produced after the recording is stopped - seems merely to be a vehicle for recording the resume point

Yes, it's tricky to think what else might be stored there.

I also did a quick visual comparison of the pairs of nts files: that in the original recording vs that produced by sidecar. I can comment on this later if anyone is interested?

I'm always interested to hear anything sensible.

 

[Black Hole]

An hmi file is created even when playing non-ts video files. I don't think it does anything other than save the resume point.

 

[escat]

It also sets a flag 0x80 at offset 0044 to display a special 'AVI failed recording' icon in the programme list if it cannot recognise the file format - even if the file is a locally produced, but still encrypted, ts-video file.

Do you know of any other functions which generate nts files other than crop, detectads, sidecar and AV2HDR-T2, or of any documentation on the nts files other than Raydon's format map in the Wiki? Thanks