[vdr] three bugreports

[emmtee@gmx.de]

First bug/"feature?" affects unpatched VDR 1.0.0 final (and before):

the menu-entry to /stop recording/ is missing after VDR restarted (into recording).
(i'm not sure if this applies to all recordings which got started by timer)

reproduce the bug:
- start recording (instant record)
-> there's an option to stop recording at the main menu
   (also acts as indication that VDR ist recording something)
- kill vdr
- restart vdr (it will resume recording)
-> the menu option is gone...
   the only option to stop recoring, which visible to me, is to edit the timer...

------------------------------------

the second bug i noticed is a bit hard to catch or reproduce
so i can't totally disqualify my system as reason - but here the
description:

- sometimes instant recording instantly starts recording.
- sometimes it simply waits (even ten or more) seconds before
  it starts recording.

note: the system is idle during those delays so i can exclude any
      performance problem.
      I get a filespace warning at the beginning of recording, not
      before - so i suppose that mechanism not guilty for the delay.
      (my OS is constantly low on HD - about 200 meg free for recording)

------------------------------------

the third bug affects divx-recording:

the patch was developed with VDR pre4 and has proven
itself as stable with pre4. when patching into VDR-1.0.0final
it developed a problem with "random" aborts of the record pipeline.
Those aborts seem to be preceded by a no-data-deadtime
there is a noticeable delay of several seconds between last encoded
frame and destructor call.

I investigated this bug a bit and traced it to one of the latest
changes...

I'm not sure what call is guilty for the pipe to stop working or
getting terminated - but it must be something that was added since pre4.

here the stacktrace for the fclose() wich is called once the stream dies
(hopefully the guilty function is visible somewhere below, annotations
 to source (linenumbers) are preced by an arrow like this: "<--"):

#5  0x4011a7ee in __libc_start_main () from /lib/libc.so.6
#4  0x0807985d in main (argc=1, argv=0xbffff284) at vdr.c:485
#3  0x0805dbd4 in GetKey__10cInterfaceb (this=0x83a6368, Wait=true) at interface.c:97
#2  0x0805db21 in GetCh__10cInterfacebPbT2 (this=0x83a6368, Wait=true, Repeat=0xbfffc97a, Release=0xbfffc97b) at interface.c:76
#1  0xffffffff in ?? ()
#0  0x401cf47e in select () from /lib/libc.so.6      <-- those last 2 are a call to dvbapi.c: cFileName::~cFileName()


Here the corresponding code-segments:

------------------
  vdr.c
------------------
  // Main program loop:
  ... <-- code left out
  while (!Interrupted) {
        ... <-- code left out
        // User Input:
        cOsdBase **Interact = Menu ? &Menu : (cOsdBase **)&ReplayControl;
        eKeys key = Interface->GetKey(!*Interact || !(*Interact)->NeedsFastResponse());  // <-- LINE 485
        if (NORMALKEY(key) != kNone) {
           EITScanner.Activity();
           LastActivity = time(NULL);
           }

           
------------------
  interface.c:
------------------
unsigned int cInterface::GetCh(bool Wait, bool *Repeat, bool *Release)
{
  Flush();
  if (!rcIo->InputAvailable())
     cFile::AnyFileReady(-1, Wait ? 1000 : 0);            // <-- LINE 76 (bad boy?)
  unsigned int Command;
  return rcIo->GetCommand(&Command, Repeat, Release) ? Command : 0;
}

eKeys cInterface::GetKey(bool Wait)
{
  Flush();
  if (SVDRP) {
     SVDRP->Process();
     if (!open) {
        char *message = SVDRP->GetMessage();
        if (message) {
           Info(message);
           delete message;
           }
        }
     }
  eKeys Key = keyFromWait;
  if (Key == kNone) {
     bool Repeat = false, Release = false;
     Key = Keys.Get(GetCh(Wait, &Repeat, &Release));         // <-- LINE 97
     if (Repeat)
        Key = eKeys(Key | k_Repeat);
     if (Release)
        Key = eKeys(Key | k_Release);
     }
  keyFromWait = kNone;
  return Key;
}