Re: A bug in libdvben50221?

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

 



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

_______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux