[linux-dvb] Re: we might be losing multicast packets

[Jeremy Hall]

Hello,

I commented all of the locations in which it was safe to do so where 
EAGAIN was returned in the driver either by EAGAIN or EWOULDBLOCK.  There 
are some places where I didn't mark because to do so might impact 
functionality or cause a hefty rewrite of the code and introduction of new 
variables.  It would help to know where the section filtering code is 
because if I need to rewrite something for debugging I don't want to be 
wasting time.

On a probably unrelated note, I happened to have this modified driver 
running while using vdr and consistently saw a marker in av7110_av.c

in vdr_play

if (nonblock && !FREE_COND)
return -EWOULDBLOCK;

_J

In the new year, Jeremy Hall wrote:
> oh I know the group is correct etc.
> 
> I'm looking, but don't see an fcntl call, for example, right now there is 
> nothing being transmitted on the group, and so my app is sitting waiting 
> for data on a read call.  It will continue to sit there until data packets 
> are ready.
> 
> I remember a similar discussion about returning EAGAIN because we had just 
> seen a buffer overflow, but I don't remember all the specifics.  When is 
> it acceptable to return EAGAIN when not using nonblocking i/o?
> 
> _J
> 
> In the new year, Johannes Stezenbach wrote:
> > Jeremy Hall wrote:
> > > On a different stream, no matter what the RECV buffer size is, I get
> > > 
> > > recvfrom: resource temporarily unavailable
> > 
> > Well, that's hardly a DVB related error when you read from a network
> > socket. EAGAIN means you are using O_NONBLOCK and there is no data.
> > 
> > > and now when I look at my ifconfig stats, I see that there are 3 errors, 
> > > all three of them framing errors, although I have seen resource 
> > > temporarily unavailable many more times than 3.
> > 
> > If ifconfig shows incoming packets, but your app is not getting any,
> > then maybe the address is wrong or something. Try tcpdump.
> > 
> > Johannes
> > 
> > 
> 
> 
>