VDR timer + mplayer = VDR crash. Please fix!

Message ID 46686ED7.8070708@gmail.com
State New
Headers

Commit Message

Anssi Hannula June 7, 2007, 8:47 p.m. UTC
  VDR User wrote:
> On 6/6/07, Anssi Hannula <anssi.hannula@gmail.com> wrote:
>> VDR User wrote:
>>> If a timer is triggered while the mplayer plugin is in use, VDR
>>> crashes.  This has happened to me about a zillion times now and I'm
>>> hoping somebody will fix this!  You can use the mplayer plugin after a
>>> timer is started no problem.  Correct me if I'm wrong but mplayer
>>> should never have to take control of the tuner in the first place
>>> since it's not required to play a media file.
>>>
>>> Free booze to anyone who can fix this incredibly annoying problem once
>>> and for all!!
>> This could be related to the fact that when mplayer-plugin forks mplayer
>> from vdr, the /dev/dvb/adapter* file descriptors are copied as well and
>> are not closed.
> 
> Thanks for such a quick reply Anssi!  Is that an easy thing to fix?

Attached is a patch for mplayer plugin which closes file descriptors 
(except 0, 1, 2) when forking mplayer script.
  

Comments

VDRU VDRU June 8, 2007, 3:41 a.m. UTC | #1
On 6/7/07, Anssi Hannula <anssi.hannula@gmail.com> wrote:
> Attached is a patch for mplayer plugin which closes file descriptors
> (except 0, 1, 2) when forking mplayer script.

I have tried the patch with several attempts now and everything worked
fine.  The timer was triggered & started recording while the mplayer
playback was uninterrupted.  No crashes, no problems as far as I can
tell.

I'd like to express great thanks that you've taken the time to fix
this bug as it's been a huge problem for a long time!

Cheers!
  
Anssi Hannula June 8, 2007, 4:27 a.m. UTC | #2
VDR User wrote:
> On 6/7/07, Anssi Hannula <anssi.hannula@gmail.com> wrote:
>> Attached is a patch for mplayer plugin which closes file descriptors
>> (except 0, 1, 2) when forking mplayer script.
> 
> I have tried the patch with several attempts now and everything worked
> fine.  The timer was triggered & started recording while the mplayer
> playback was uninterrupted.  No crashes, no problems as far as I can
> tell.
> 
> I'd like to express great thanks that you've taken the time to fix
> this bug as it's been a huge problem for a long time!

Nice to hear that :)

I hadn't previously investigated this further, as I have a multiple-card
system, so I had only experienced minor problems because of this.
  

Patch

diff -Nurp -x '*~' mp3-0.9.15/player-mplayer.c mp3-0.9.15-c/player-mplayer.c
--- mp3-0.9.15/player-mplayer.c	2006-09-19 21:17:50.000000000 +0300
+++ mp3-0.9.15-c/player-mplayer.c	2007-06-07 23:34:17.000000000 +0300
@@ -29,6 +29,7 @@ 
 #include <sys/ioctl.h>
 #include <sys/types.h>
 #include <sys/poll.h>
+#include <sys/resource.h>
 #include <unistd.h>
 #include <signal.h>
 #include <wait.h>
@@ -395,6 +396,11 @@  bool cMPlayerPlayer::Fork(void)
       close(outpipe[1]);
       }
 
+  rlimit lim;
+  if(getrlimit(RLIMIT_NOFILE, &lim) == 0)
+    for(int i = lim.rlim_max - 1; i > 2; i--)
+       close(i);
+
     char cmd[64+PATH_MAX*2], aid[20];
     char *fname=Quote(file->FullPath());
     if(MPlayerAid>=0) snprintf(aid,sizeof(aid)," AID %d",MPlayerAid);