[vdr] Re: three bugreports

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

emmtee@gmx.de wrote:
> 
> 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...

VDR only "knows" that this is an instant recording while it is running in the
same session as the recordign was started in. After a restart (for whatever reason)
it is handled just like any other timer recording.

> 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)

I suppose the 10 second wait happens on channels that have no EPG data?!
VDR tries to use the current EPG data in order to name the recording etc.
If there is no EPG data at the time the recording starts, VDR waits up
to 10 seconds to allow EPG data to arrive.

> ------------------------------------
> 
> 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;
> }

VDR is apparently waiting for some input. I don't see how that should
interfere with anythign else.

What you could to is to take the tools.c file from verion 1.0.0pre4
to see whether the problem was introduced by the changes in that file.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________