Version 1.7.32

VDR developer version 1.7.32 is now available at

       ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.32.tar.bz2

A 'diff' against the previous version is available at

       ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.31-1.7.32.diff

MD5 checksums:

068ba78fd427694dcc480fe3b2d07148  vdr-1.7.32.tar.bz2
222f1e9b4d4edaa6fe57286409614cc7  vdr-1.7.31-1.7.32.diff

WARNING:
========

This is a developer version. Even though I use it in my productive
environment. I strongly recommend that you only use it under controlled
conditions and for testing and debugging.

The main focus of this version is on an improved frame detection code,
and improvements to the cutting process. When cutting a recording, VDR
now removes any "dangling" TS packets from the beginning of an editing
sequence and pulls in any "pending" TS packets at the end of a sequence.
It also fixes all timestamps and continuity counters.
However, while the results look much better now in, for instance, Kaffeine,
the TT S2-6400 still shows some video artifacts at the editing points, and
the Mac video player sometimes totally chokes on edited material.
I did spend a lot of time trying to find out what could still be wrong here,
but couldn't come up with any new ideas. So I think it's now time to invite
others to test this new cutting code, read the source code and try to find
out what's still going wrong here. Maybe (hopefully ;-) it's just some stupid
little error... ;-)

From the HISTORY file:
- Pressing the Play key during normal live viewing mode now opens the Recordings menu
  if there is no "last viewed" recording (thanks to Alexander Wenzel).
  The same behavior has been implemented for the Blue key in the main menu.
- cIoThrottle::Engaged() is now also checked in cRemoveDeletedRecordingsThread::Action(),
  to suspend removing deleted recordings in case this is necessary to make room for
  new, ongoing recordings (suggested by Udo Richter).
- The cThread constructor now has an additional boolean parameter that can be set to
  true to have this thread run at a lower priority. Plugin authors that use low
  priority threads may want to use this instead of the calls to SetPriority(19) and
  SetIOPriority(7). The priority of a thread ("low" or "high") is now logged when the
  thread starts.
- Changed DTV_DVBT2_PLP_ID to DTV_STREAM_ID in dvbdevice.c to adapt to an incompatible
  change in DVB API 5.8 (reported by Derek Kelly).
  Removed the meanwhile obsolete definition of FE_CAN_TURBO_FEC.
- Fixed some compiler warnings under gcc version 4.7.1.
- Fixed setting the video format in the dvbhdffdevice (thanks to Torsten Lang).
- Fixed 'make install' to not overwrite existing configuration files (thanks to Peter
  Münster).
- Added including the Make.global and Make.config files to the dvbdhffdevice's
  libhdffcmd/Makefile.
- Added options to build a 32-bit version of VDR on a 64-bit machine to
  Make.config.template.
- Fixed handling VPS timers in case the running status of an event goes to '1' (not
  running) and later goes to '4' (running).
- If a frame position in the 'marks' file of a recording doesn't point to an I-frame,
  it will now be shifted towards the next I-frame, either up or down, whichever is
  closer (suggested by Udo Richter).
- Fixed a possible memory leak in SI::StructureLoop::getNextAsPointer() (reported by
  Sundararaj Reel).
- Fixed handling timers in case an event is modified and "phased out" while the timer
  is recording.
- Improved frame detection by parsing just far enough into the MPEG-4 NAL units to get
  the necessary information about frames and slices.
- The initial syncing of the frame detector is now done immediately after the first
  complete GOP has been seen. This makes recordings and especially pausing live video
  start up to twice as fast as before.
- Updated the Romanian OSD texts (thanks to Lucian Muresan).
- Fixed handling the very last entry in a recording index.
- The return type of cMarks::Add() has been changed to void, since due to the sorting
  of the list of marks the returned pointer might have pointed to a totally different
  mark. Besides, the return value was never actually used.
- Improved editing TS recordings by
  + stripping dangling TS packets from the beginning of a sequence
  + including pending TS packets at the end of a sequence
  + fixing all timestamps and continuity counters
  + generating editing marks for the edited version in such a way that each cutting
    point is marked by an "end" and "begin" mark with the same offset
  + no longer generating an editing mark at the "end" of the edited recording (this
    was actually generated at the beginning of the last GOP, so that a subsequent
    edit would have cut off the last GOP)
  + no longer generating any editing marks if the edited recording results on just
    one single sequence
  + ignoring pairs of editing marks that are placed at exactly the same position of
    a recording when actually cutting the recording
  + not doing anything if the editing marks in place would result in the edited
    version being the same as the original recording
- Editing marks can now be placed directly on top of each other, in which case they
  simply mark a position, but have no effect on the actual cutting process.
- When positioned at an offset where two (or more) editing marks are placed on top
  of each other, the '4' key moves the first one of them to the left, while the '6'
  key moves the last one of them to the right. The '7' and '9' key handle multiple
  marks at the same place as if it were one single mark.
- Modified editing marks are now written to disk whenever the replay progress display
  gets hidden (thanks to Christoph Haubrich).

MANUAL

@@ -367,13 +367,13 @@ Version 1.6
   - 7, 9    Jump back and forward between editing marks. Replay goes into still
             mode after jumping to a mark.
   - 8       Positions replay at a point 3 seconds before the current or next
-            "start" mark and starts replay.
+            "begin" mark and starts replay.
   - 2       Start the actual cutting process.
 
   Editing marks are represented by black, vertical lines in the progress display.
-  A small black triangle at the top of the mark means that this is a "start"
+  A small black triangle at the top of the mark means that this is a "begin"
   mark, and a triangle at the bottom means that this is an "end" mark.
-  The cutting process will save all video data between "start" and "end" marks
+  The cutting process will save all video data between "begin" and "end" marks
   into a new file (the original recording remains untouched). The new file will
   have the same name as the original recording, preceded with a '%' character
   (imagine the '%' somehow looking like a pair of scissors ;-). Red bars in the
@@ -382,7 +382,7 @@ Version 1.6
 
   The video sequences to be saved by the cutting process are determined by an
   "even/odd" algorithm. This means that every odd numbered editing mark (i.e.
-  1, 3, 5,...) represents a "start" mark, while every even numbered mark (2, 4,
+  1, 3, 5,...) represents a "begin" mark, while every even numbered mark (2, 4,
   6,...) is an "end" mark. Inserting or toggling a mark on or off automatically
   adjusts the sequence to the right side of that mark.
 
@@ -395,11 +395,13 @@ Version 1.6
   version of the recording you can use the '8' key to jump to a point just
   before the next cut and have a look at the resulting sequence.
 
-  Currently editing marks can only be set at I-frames, which typically is
-  every 12th frame. So editing can be done with a resolution of roughly half
-  a second. A "start" mark marks the first frame of a resulting video
-  sequence, and an "end" mark marks the last frame of that sequence.
-
+  Currently editing marks can only be set at I-frames, which typically appear
+  every half of a second to a second.  A "begin" mark marks the first frame of
+  a resulting video sequence, and an "end" mark marks the last frame of that
+  sequence.  Note that the actual frame indicated by the an "end" mark will
+  not be included in the edited version of the recording. That's because every
+  recording (and every sequence of an edited recording) begins with an I-frame
+  and ends right before the next I-frame.
   An edited recording (indicated by the '%' character) will never be deleted
   automatically in case the disk runs full (no matter what "lifetime" it has).