Re: [vdr] ERROR: LIRC remote control thread xx won't end
Markus Hahn wrote:
Hi there,
due to debuging purposes I set in
void cThread::Cancel(int WaitSeconds)
WaitSeconds = 6000;
between the waits of 3 seconds I syslog the message: "thread won`t end" .
At vdr shutdown I get the (endless) error message :
[vdr] ERROR: LIRC remote control thread xxx won't end
_until_ I pressed any key.
If Cancel() kills a thread, it ends up with a Segfault mostly.
Does anybody noticed this behavior to?
Maybe there must be another interrogation of Running() in lirc.c
There are two 'while' loops in cLircRemote::Action(), but both
check Running(), so I would expect them to end properly.
You could try adding something like
dsyslog("%d", __LINE__);
at a few places in cLircRemote::Action() to find out where
exactly it is hanging, as in
while (Running() && f >= 0) {
dsyslog("%d", __LINE__);
bool ready = cFile::FileReady(f, timeout);
dsyslog("%d", __LINE__);
int ret = ready ? safe_read(f, buf, sizeof(buf)) : -1;
dsyslog("%d", __LINE__);
if (ready && ret <= 0 ) {
etc.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
I joined the mplayer mailing list and have tried to seek help/information from those nice folks.. The following is part of one of my exchanges. Maybe the part about the timestamp may be of some help? > I asked a couple specific questions and included some quotes from other> posts to provide an idea of what we're looking at as the cause. I can't> tell you what the exact problem is because we're still trying to figure that > out... And a good place to start is by comparing the differences between> the software that has the problem and software that doesn't. We're> trying to figure out what mplayer does, if anything, with regards to > repacking, the pes layer, pcr data, etc. during the "playback" of a VDR "recording".nothing particular: the pes packetization is as standard as you can get, except that IIRC there's a timestamp on every single frame,rather than once every 0.5-0.7 seconds; this fact alone can make alot of difference during playback.Does the desync that you are experiencing get worse with time or does it regularly decrease and next increase? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
I'm not sure if it's been answered yet, but I thought I'd throw this out:mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime. Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice.I know it's probably what most of you didn't want to hear, but I figured you guys would want to know. whoman421On 11/3/06, VDR User <[EMAIL PROTECTED]> wrote: I joined the mplayer mailing list and have tried to seek help/information from those nice folks.. The following is part of one of my exchanges. Maybe the part about the timestamp may be of some help? > I asked a couple specific questions and included some quotes from other> posts to provide an idea of what we're looking at as the cause. I can't> tell you what the exact problem is because we're still trying to figure that > out... And a good place to start is by comparing the differences between> the software that has the problem and software that doesn't. We're> trying to figure out what mplayer does, if anything, with regards to > repacking, the pes layer, pcr data, etc. during the "playback" of a VDR "recording".nothing particular: the pes packetization is as standard as you can get, except that IIRC there's a timestamp on every single frame,rather than once every 0.5-0.7 seconds; this fact alone can make alot of difference during playback.Does the desync that you are experiencing get worse with time or does it regularly decrease and next increase? ___vdr mailing listvdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice and epia tv-out problem with Xorg
On Donnerstag 02 November 2006 23:38, Stefan Lucke wrote:
> Quoting Leo Márquez:
>
> > Hi again,
> >
> > Stefan Lucke escribió:
> >
> > >>/ But after started it without problems now I get:
> > >/>/
> > >/>/ [softdevice] A/V devices initialized, now initializing MPEG2 Decoder
> > >/>/ X Error of failed request: BadValue (integer parameter out of range
> > >for
> > >/>/ operation)
> > >/>/ Major opcode of failed request: 145 (MIT-SHM)
> > >/>/ Minor opcode of failed request: 3 (X_ShmPutImage)
> > >/>/ Value in failed request: 0x3ff
> > >/
> > >Which are the startup options now ?
> > >0x3ff = 1023 = 1024 - 11
> > >
> > >
> > My startup options are only "-vo xv:full"
> >
> > >Did you changed your X resolution via "ALT"+"CTRL"+"Keypad +" ?
> > >
> > >
> > No but I press the 'f' key to toggle between fullscreen and windowed vdr
> > mode.
> > The second time I run vdr with -vo xv:full don't work
>
> Ah, I should have mentioned that you _must_ not toggle full screen ->
> windowed mode, as windowed mode works with some default values
> which even did not work previously (thats why I ask for full screen mode).
>
> I'll send you a patch tomorrow that will restrict these values.
>
Ok, here comes the patch. I tested it with 640x480 resolution and now I do not
get these failed request any more. In contrast to your setup, mine worked fine
when setting "softdevice.OSDalphablend = 1" in vdr's setup.conf even
without the patch.
--
Stefan Lucke
Index: video-xv.c
===
RCS file: /cvsroot/softdevice/softdevice/video-xv.c,v
retrieving revision 1.63
diff -U3 -r1.63 video-xv.c
--- video-xv.c 29 Sep 2006 19:17:18 - 1.63
+++ video-xv.c 3 Nov 2006 18:29:54 -
@@ -862,6 +862,23 @@
}
}
#endif
+
+ /* -
+ * limit widht and height to screen dimensions
+ */
+ {
+ int screen_width, screen_height;
+
+screen_width = DisplayWidth(dpy, scn_id);
+screen_height = DisplayHeight(dpy, scn_id);
+
+if (height > screen_height)
+ old_dheight = lheight = dheight = height = screen_height;
+
+if (width > screen_width)
+ old_dwidth = lwidth = dwidth = width = screen_width;
+ }
+
/* -
* default settings which allow arbitraray resizing of the window
*/
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
whoMAN wrote: mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime. It doesn't transcode MPEG2. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] dv-plugin
Hi there! Is the dv-plugin maintained anymore? I've been looking at http://home.vrweb.de/~erich.bachl/ but I didn't find anything at all there ... Is there anyone out there that maybe can mail me the plugin or point me to another download location? And, i it working well? Best regards and thanks for any help, Lars Fredriksson ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
whoMAN wrote: mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime. Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice. Once again, this is impossible. Really. My CPU is a VIA C3-600 CPU, and its really too slow to transcode *anything*. If I force transcodung with -vf lavc=1000, the CPU load is 99% and the video plays at 40% original speed only. Just decoding the mpeg2 stream eats up 75% CPU alone, without audio and without displaying. Without forcing transcoding, the CPU load is 10% and no frames get dropped. This is roughly 25 times faster than with lavc=1000. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dv-plugin
Lars Fredriksson wrote: > Hi there! > > Is the dv-plugin maintained anymore? I've been looking at > http://home.vrweb.de/~erich.bachl/ but I didn't find anything at all > there ... I think that the Softieee1394-plugin has replaced the DV-plugin... I have it installed, but i have not had time to test it yet... http://softdevice.berlios.de/softieee1394/index.html Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
