| Message ID | 4277E7BE.1030003@gmx.de |
|---|---|
| State | New |
| Headers |
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by www.linuxtv.org with smtp (Exim 4.34) id 1DT4bK-0007yX-U9 for vdr@linuxtv.org; Tue, 03 May 2005 23:06:42 +0200 Received: (qmail invoked by alias); 03 May 2005 21:06:11 -0000 Received: from dialin-145-254-231-170.arcor-ip.net (EHLO [192.168.101.15]) [145.254.231.170] by mail.gmx.net (mp025) with SMTP; 03 May 2005 23:06:11 +0200 X-Authenticated: #527675 Message-ID: <4277E7BE.1030003@gmx.de> Date: Tue, 03 May 2005 23:06:06 +0200 From: Reinhard Nissl <rnissl@gmx.de> User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Schmidinger's VDR <vdr@linuxtv.org> Subject: Re: [vdr] xine-vdr NovaT "FIXME: xineDevice.c:1160" References: <1115115214.3406.7.camel@hush> <020701c54fde$f3e19b30$7b95b984@nsctechnology.com> In-Reply-To: <020701c54fde$f3e19b30$7b95b984@nsctechnology.com> Content-Type: multipart/mixed; boundary="------------050700060604070406070203" X-Y-GMX-Trusted: 0 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Klaus Schmidinger's VDR <vdr@linuxtv.org> List-Id: Klaus Schmidinger's VDR <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2005 21:06:43 -0000 Status: O X-Status: X-Keywords: X-UID: 1905 |
Commit Message
Reinhard Nissl
May 3, 2005, 9:06 p.m. UTC
Hi, Simon Baxter wrote: > I've just setup my WinTV NovaT on a new (2.2Ghz) shuttle PC and built > the xine-plugin components. > > I created a new channels.conf file with scan and ran up VDR > > On some channels I get screens and screens of information like : > FIXME: xineDevice.c:1160 > FIXME: xineDevice.c:970 > FIXME: xineDevice.c:1126 > > I gather each specific XXXX number refers to capability needed on those > specific channels?? > > any ideas? Hhm, each of these locations checks, whether a PES packet starts with the byte sequence 00 00 01, and fails as the packets don't. If you are using a recent VDR (1.3.20 and higher), please have a look at the attached patch. It fixes the so called class cPesAssembler. Does the problem disappear if you record such a channel and then play the 001.vdr file directly with xine? Can you provide me a sample recording (~ 5 MB)? Bye.
Comments
I was using vdr-1.3.1, and getting those errors. I've just compiled 1.3.23 and don't ALTHOUGH...... I'm doing the testing via a DEBUG_OSD=1 compile and a 'shell' because I have a slow running X problem at the moment. 1) The problem _may_ not be happenning now in version 1.3.23, although until I resolve my slow x problem I can't be sure 2) The Makefile in 1.3.23 no longer has the tags for DEBUG_OSD. Has this now been removed? I added : ifdef DEBUG_OSD DEFINES += -DDEBUG_OSD NCURSESLIB = -lncurses endif to the Makefile, but the OSD shell-text OSD doesn't startup when I start vdr now??? Has this been removed?? Thanks Simon ----- Original Message ----- From: "Reinhard Nissl" <rnissl@gmx.de> To: "Klaus Schmidinger's VDR" <vdr@linuxtv.org> Sent: Tuesday, May 03, 2005 10:06 PM Subject: Re: [vdr] xine-vdr NovaT "FIXME: xineDevice.c:1160" > Hi, > > Simon Baxter wrote: > >> I've just setup my WinTV NovaT on a new (2.2Ghz) shuttle PC and built >> the xine-plugin components. >> >> I created a new channels.conf file with scan and ran up VDR >> >> On some channels I get screens and screens of information like : >> FIXME: xineDevice.c:1160 >> FIXME: xineDevice.c:970 >> FIXME: xineDevice.c:1126 >> >> I gather each specific XXXX number refers to capability needed on those >> specific channels?? >> >> any ideas? > > Hhm, each of these locations checks, whether a PES packet starts with > the byte sequence 00 00 01, and fails as the packets don't. > > If you are using a recent VDR (1.3.20 and higher), please have a look at > the attached patch. It fixes the so called class cPesAssembler. > > Does the problem disappear if you record such a channel and then play > the 001.vdr file directly with xine? > > Can you provide me a sample recording (~ 5 MB)? > > Bye. > -- > Dipl.-Inform. (FH) Reinhard Nissl > mailto:rnissl@gmx.de > -------------------------------------------------------------------------------- > --- ../vdr-1.3.23-orig/device.c 2005-02-27 14:55:15.000000000 +0100 > +++ device.c 2005-05-01 22:59:18.869069399 +0200 > @@ -27,6 +27,7 @@ private: > uint32_t tag; > int length; > int size; > + bool hasFragment; > bool Realloc(int Size); > public: > cPesAssembler(void); > @@ -39,6 +40,7 @@ public: > void Put(uchar c); > void Put(const uchar *Data, int Length); > bool IsPes(void); > + bool HasFragment(void); > }; > > cPesAssembler::cPesAssembler(void) > @@ -57,6 +59,12 @@ void cPesAssembler::Reset(void) > { > tag = 0xFFFFFFFF; > length = 0; > + hasFragment = false; > +} > + > +bool cPesAssembler::HasFragment(void) > +{ > + return hasFragment || length > 0; > } > > bool cPesAssembler::Realloc(int Size) > @@ -67,6 +75,7 @@ bool cPesAssembler::Realloc(int Size) > if (!data) { > esyslog("ERROR: can't allocate memory for PES assembler"); > length = 0; > + hasFragment = false; > size = 0; > return false; > } > @@ -77,6 +86,7 @@ bool cPesAssembler::Realloc(int Size) > void cPesAssembler::Put(uchar c) > { > if (!length) { > + hasFragment = true; > tag = (tag << 8) | c; > if ((tag & 0xFFFFFF00) == 0x00000100) { > if (Realloc(4)) { > @@ -985,7 +997,7 @@ int cDevice::PlayPes(const uchar *Data, > return 0; > } > int Result = 0; > - if (pesAssembler->Length()) { > + if (pesAssembler->HasFragment()) { > // Make sure we have a complete PES header: > while (pesAssembler->Length() < 6 && Length > 0) { > pesAssembler->Put(*Data++); > -------------------------------------------------------------------------------- > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.3 - Release Date: 03/05/2005
Simon Baxter wrote: > I was using vdr-1.3.1, and getting those errors. I've just compiled > 1.3.23 and don't ALTHOUGH...... > > I'm doing the testing via a DEBUG_OSD=1 compile and a 'shell' because I > have a slow running X problem at the moment. > > 1) The problem _may_ not be happenning now in version 1.3.23, although > until I resolve my slow x problem I can't be sure > > 2) The Makefile in 1.3.23 no longer has the tags for DEBUG_OSD. Has > this now been removed? I added : > ifdef DEBUG_OSD > DEFINES += -DDEBUG_OSD > NCURSESLIB = -lncurses > endif > > to the Makefile, but the OSD shell-text OSD doesn't startup when I start > vdr now??? Has this been removed?? The OSD DEBUG has been removed for quite some time (after vdr-1.3.6 if I recall correctly). It has been replaced by a plugin called skincurses which is located in <vdr-dir>/PLUGINS/src. André.
Thanks! How do I use it? I've tried : [root@media vdr-1.3.23]# ./vdr -P'xine -r' -t TTY vdr: can't access terminal: TTY ----- Original Message ----- From: "André Weidemann" <Andre.Weidemann@web.de> To: "Klaus Schmidinger's VDR" <vdr@linuxtv.org> Sent: Wednesday, May 04, 2005 10:11 AM Subject: Re: [vdr] xine-vdr NovaT "FIXME: xineDevice.c:1160" > Simon Baxter wrote: >> I was using vdr-1.3.1, and getting those errors. I've just compiled >> 1.3.23 and don't ALTHOUGH...... >> >> I'm doing the testing via a DEBUG_OSD=1 compile and a 'shell' because I >> have a slow running X problem at the moment. >> >> 1) The problem _may_ not be happenning now in version 1.3.23, although >> until I resolve my slow x problem I can't be sure >> >> 2) The Makefile in 1.3.23 no longer has the tags for DEBUG_OSD. Has this >> now been removed? I added : >> ifdef DEBUG_OSD >> DEFINES += -DDEBUG_OSD >> NCURSESLIB = -lncurses >> endif >> >> to the Makefile, but the OSD shell-text OSD doesn't startup when I start >> vdr now??? Has this been removed?? > > The OSD DEBUG has been removed for quite some time (after vdr-1.3.6 if I > recall correctly). > It has been replaced by a plugin called skincurses which is located in > <vdr-dir>/PLUGINS/src. > > André. > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.3 - Release Date: 03/05/2005 > >
got it - vdr -P'skincurses' Seems to be stable and no of the FIXME errors..... now to fix my slow X problem... Thanks again ----- Original Message ----- From: "Simon Baxter" <linuxtv@nzbaxters.com> To: "Klaus Schmidinger's VDR" <vdr@linuxtv.org> Sent: Wednesday, May 04, 2005 10:39 AM Subject: Re: [vdr] xine-vdr NovaT "FIXME: xineDevice.c:1160" Thanks! How do I use it? I've tried : [root@media vdr-1.3.23]# ./vdr -P'xine -r' -t TTY vdr: can't access terminal: TTY ----- Original Message ----- From: "André Weidemann" <Andre.Weidemann@web.de> To: "Klaus Schmidinger's VDR" <vdr@linuxtv.org> Sent: Wednesday, May 04, 2005 10:11 AM Subject: Re: [vdr] xine-vdr NovaT "FIXME: xineDevice.c:1160" > Simon Baxter wrote: >> I was using vdr-1.3.1, and getting those errors. I've just compiled >> 1.3.23 and don't ALTHOUGH...... >> >> I'm doing the testing via a DEBUG_OSD=1 compile and a 'shell' because I >> have a slow running X problem at the moment. >> >> 1) The problem _may_ not be happenning now in version 1.3.23, although >> until I resolve my slow x problem I can't be sure >> >> 2) The Makefile in 1.3.23 no longer has the tags for DEBUG_OSD. Has this >> now been removed? I added : >> ifdef DEBUG_OSD >> DEFINES += -DDEBUG_OSD >> NCURSESLIB = -lncurses >> endif >> >> to the Makefile, but the OSD shell-text OSD doesn't startup when I start >> vdr now??? Has this been removed?? > > The OSD DEBUG has been removed for quite some time (after vdr-1.3.6 if I > recall correctly). > It has been replaced by a plugin called skincurses which is located in > <vdr-dir>/PLUGINS/src. > > André. > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.3 - Release Date: 03/05/2005 > >
Simon Baxter wrote: > Thanks! > > How do I use it? > > I've tried : > > [root@media vdr-1.3.23]# ./vdr -P'xine -r' -t TTY > vdr: can't access terminal: TTY The error probably occurs because you need to sepcify /dev/tty12 or something similar instead of TTY. Just for testing you don't need this I'd say. The TTY is only needed if you start vdr from a script and you need a terminal afterwards to be able to control it via keyboard. For the skincurses plugin... I'd use -P skincurses on the command line... André. PS: this site is not yet complete... but it is always a good starting point: http://www.linuxtv.org/vdrwiki/index.php/Main_Page PPS: please do not top-quote... makes it difficult to follow up
Can anyone send me their remote.conf for the Hauppauge Nova-T card, which uses the mini-din connected IR sensor? Can this card be used under LIRC? Or do all the buttons work under the in-built sensor and DVB drivers? Thanks Simon
"Simon Baxter" <linuxtv@nzbaxters.com> writes: > Can anyone send me their remote.conf for the Hauppauge Nova-T card, > which uses the mini-din connected IR sensor? Mini-din? I have Nova-T and IR sensor is connected with 2.5 or 3.5 mm plug. It appears in /dev/input/event0 (uses modules input and evdev), but those are loaded at least for me automatically. > Can this card be used under LIRC? Or do all the buttons work under > the in-built sensor and DVB drivers? For mine all except power-butto work with vdr+remote plugin ok. Loading order of modules matter, if I load dvb-ttpci before dvb-ttpci-budget-ci remote does not work. (Not answering what you asked, but answering still in hope this might help...)
--- ../vdr-1.3.23-orig/device.c 2005-02-27 14:55:15.000000000 +0100 +++ device.c 2005-05-01 22:59:18.869069399 +0200 @@ -27,6 +27,7 @@ private: uint32_t tag; int length; int size; + bool hasFragment; bool Realloc(int Size); public: cPesAssembler(void); @@ -39,6 +40,7 @@ public: void Put(uchar c); void Put(const uchar *Data, int Length); bool IsPes(void); + bool HasFragment(void); }; cPesAssembler::cPesAssembler(void) @@ -57,6 +59,12 @@ void cPesAssembler::Reset(void) { tag = 0xFFFFFFFF; length = 0; + hasFragment = false; +} + +bool cPesAssembler::HasFragment(void) +{ + return hasFragment || length > 0; } bool cPesAssembler::Realloc(int Size) @@ -67,6 +75,7 @@ bool cPesAssembler::Realloc(int Size) if (!data) { esyslog("ERROR: can't allocate memory for PES assembler"); length = 0; + hasFragment = false; size = 0; return false; } @@ -77,6 +86,7 @@ bool cPesAssembler::Realloc(int Size) void cPesAssembler::Put(uchar c) { if (!length) { + hasFragment = true; tag = (tag << 8) | c; if ((tag & 0xFFFFFF00) == 0x00000100) { if (Realloc(4)) { @@ -985,7 +997,7 @@ int cDevice::PlayPes(const uchar *Data, return 0; } int Result = 0; - if (pesAssembler->Length()) { + if (pesAssembler->HasFragment()) { // Make sure we have a complete PES header: while (pesAssembler->Length() < 6 && Length > 0) { pesAssembler->Put(*Data++);