[linux-dvb] A bug in libdvben50221?

Christophe Thommeret hftom at free.fr
Fri Dec 5 02:05:54 CET 2008


Le vendredi 5 décembre 2008 02:02:52 Christophe Thommeret, vous avez écrit :
> Le jeudi 4 décembre 2008 23:58:31 Morgan Tørvolt, vous avez écrit :
> > Hi all.
> >
> > This might be a stupid question, please feel free to call me a moron
> > and tell me how to solve this little problem I am having. I have tried
> > getting in touch with someone on the irc channel to help me sort this
> > out without much luck. Hopefully someone here has some knowledge of
> > the libdvben50221 library. I would imagine that very many use this
> > library with their dvb cards, so there should be someone out there.
> >
> > The camthread in gnutv, which continuously polls the stdcam, calls the
> > stdcam's poll function (obviously). The poll function is in my
> > pointing to the en50221_stdcam_llci_poll function. This function in
> > turn calls en50221_tl_poll, but without passing the return value of
> > this on to the camthread function of gnutv. What happened in my case
> > was that the transport layer crashed in some obscure way (this has
> > only happened once actually), and the en50221_tl_poll function
> > returned -1 all the time, and set the error state to be -3, which is
> > EN50221ERR_TIMEOUT. It did not recover in over an hour of waiting.
> > This message was spamming my console window:
> > en50221_stdcam_llci_poll: Error reported by stack:-3
> >
> > After looking high and low for a way to be able to detect this state,
> > I have come up with nothing. I cannot read the error value directly
> > out of the stuct as it is a forward declaration in the header file and
> > actually declared in the .c file. I can access the error data using
> > the en50221_tl_get_error() function, but that only tells me that at
> > some point there was an error with the given error value.
> >
> > At least on my cam I get this message often when I start a program:
> > "en50221_stdcam_llci_poll: Error reported by stack:-7", which is a
> > message I can test with. My testing suggest that the error is set to
> > -7 and is left there until a new error occurs. In other words, it is
> > not possible to detect if the error -7 occurs every second, every
> > minute, or just once at the start and no errors since then. The same
> > problem exists with the timeout error I had. gnutv could have detected
> > that there had been a timeout error, but could in no way I can see,
> > find out if it had resolved itself or not.
> >
> > The error I saw was a timeout error that happened after more than 24
> > hours from starting the program, and the transport layer was returning
> > -3 continuously.
> >
> > I can think of a few ways to solve this problem.
> >  * One would be a callback function on transport layer error in the
> > stdcam * Have an error counter in the transport layer struct, and a
> > function to read the counter. Must be reflected in the session layer as
> > well it seems.
> >  * Return the transport layer poll's return value in some way from the
> > stdcam poll function. Possibly by setting adding to the stdcam_status
> > enum a value like "EN50221_STDCAM_TL_ERROR". Maybe a bitshifted value
> > as well? It should then be easy to check the error using the
> > en50221_tl_get_error function.
> >  * This is already solved trough some other solution, and I have been
> > to blind to see it all along.
> >
> > I prefer the options from bottom to top.
> > Any takers?
>
> Look at en50221_stdcam_llci_poll(..) in the joined file.
> This is how i solved that.

Forgot to say: don't try to use that file as is, it may have some other 
modifications that you don't want.

-- 
Christophe Thommeret




More information about the linux-dvb mailing list