While developing "mcut" (see the post Perform movie cuts on DM7025) I discovered a few strange behaviors which may be due to a bug in how the .ap files are used. The .ap files apparently contain a mapping between file positions in bytes and time stamps in the movie. The time stamps are typically about one or one half second apart depending on the recorded service. This mapping is used among other things when stepping backwards through a movie. That is, pausing and then pressing fast-backwards, always jumps to such a point listed in the .ap file. For lack of a better name I will in the following call the sequence of a movie between two consecutive time stamps in the .ap file a "chunk".

I noted the following, maybe seemingly unrelated details:

• Stepping backwards through the movie jumps over two chunks at a time, i.e. if the chunks are half a second long the jumps are one second long, and if the chunks are one second the jumps are two seconds long. The intention is probably to be able to jump over one chunk at a time.
  

  
  

• When using the cutlist editor, the actual cuts are offset somewhat from where they are set. For example, carefully stepping as above to the best position for a cut, causes the actual cut to be positioned some second later (presumably one chunk length) than what was intended.
  

  
  

• When looking at the movie list, the indicated times of the movies seem always to be about one second too short. I.e a one hour recording is indicated as 59:59 long. When actually cutting out exactly two minutes with "mcut", which I know will add some extra margin on both sides and thus be some part of a second longer than two minutes, it is indicated as 1.59 long. Perhaps the last "chunk" is not counted?
  

  
  

• When diving into the representations in the various files (when writing "mcut") I noted that the time stamps in the .ap file were slightly offset from the time stamps in the mpeg stream at the corresponding position in the file.

The last observation made me wonder if the time stamps in the .ap file was unintentionally shifted one step, and if this would cause one or more of the first three oservations.. So since I was already able to parse and process the .ap file I made an experiment: I shifted all timestamps in the .ap file one step to see what happened. The results were mixed:

• Stepping backwards indeed now jumped only one chunk at a time, so for this the fix was successful.
  

  
  

• Unfortunately for the cutlist editor the offset between intended cut and actual cut increased by one chunk length rather than decrease as I had hoped.
  

  
  

• The lengths in the movie list was probably not affected, or rather the movie now seemed two seconds shorter than it actually was, but this was expected since I loose one chunk when I shift everything in the .ap file.

So what can one say from this? Probably the .ap file is correct after all, but the values in it are used in the wrong way (or in two different wrong ways) both when stepping backwards and by the cutlist editor. The short movie lenths are probably unrelated and maybe due to unfortunate roundoff (or missing the last chunk and then truncating the length rather than rounding).

Maybe these observations will help someone to rectify these bugs?

(These effects were observed with Enigma2 version=20070109. "Hopefully" I have not made a fool of myself by posting a bug report for bugs that are already fixed...)

Best Regards
Anders Holst