Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Poll problem with multiple PIDs



Hi again,

I changed again your original program x.c to the following :

while (time(NULL) < t0)
{
        if (pfd.revents & POLLIN != 0)
	{
           unsigned char buf[188];
           int r = read(fd_dvr, buf, sizeof(buf));
           if (r == 188)
	   {
	      fprintf(stderr, "O" );
              int Pid = (((uint16_t)buf[1] & PID_MASK_HI) << 8) | buf[2];
              if (Pid != LastPid) {
//                 fprintf(stderr, "%d %02X ", r, buf[0]);
                 for (int i = 0; i < NumPids; i++) {
//                     fprintf(stderr, "\t");
                     if (Pids[i] == Pid)
                        break;
                     }
//                 fprintf(stderr, "%4d\n", Pid);
                 LastPid = Pid;
                 }
           }
           else
              dsyslog("r = %d", r);
        } else
		fprintf(stderr, "#");
		
//        fprintf(stderr, ".");
        poll(&pfd, 1, 10);
//        fprintf(stderr, ".");
}

It is the same code only without the fprints in the inner loop, and only one 
fprint( stderr, "O") to indicate that the read was OK. 
I then get a lot of "O"'s and from time to time a "#", like it should be.
I think that the console print buffer is filling up too rapidly and that this 
is interferring with the plling function.
Does that seems logical ?

hugo



On Saturday 15 June 2002 16:07, you wrote:
> Ralph Metzler wrote:
> > Klaus Schmidinger writes:
> >  > > When you set that many
> >  > > filters on such high data rate PIDs the kernel has a lot of work to
> >  > > do comparing and copying.
> >  >
> >  > I thought that the filters were set up in the hardware, and that only
> >  > those packets that match any of the desired PIDs would actually get to
> >  > the driver.
> >
> > The Nova cards do not have any hardware filters. The complete TS is
> > always written to memory by DMA and has to be filtered by software in
> > the driver.
>
> Ok, so with my latest test program
> (ftp://ftp.cadsoft.de/pub/people/kls/vdr/x2.c) I receive the entire TS and
> print some test output, but still the data stream breaks after a short
> while (apparently 'pfd.revents & POLLIN' never becomes non-zero after that
> any more).
>
> I keep looking at my code (x2.c), but can't find anything wrong with it
> (which, of course, doesn't necessarily mean that there isn't anything wrong
> with it - maybe I just don't realize it ;-).
>
> Meanwhile Hugo Van Ruyskensvelde has sent me a modified version of my test
> example, where he has done things "a la dvbstream", which seems to work.
> However, he didn't check 'pfd.revents & POLLIN' in his version. If I remove
> that check from my test example, it keeps on working. But I think it would
> be a good idea to check 'pfd.revents & POLLIN', and maybe since this
> doesn't work as expected, there is a hidden problem somewhere in that area
> in the driver...
>
> Klaus


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index