[linux-dvb] A bug in libdvben50221?

Morgan Tørvolt morgan.torvolt at gmail.com
Mon Dec 8 14:10:55 CET 2008


Thanks a lot Christophe.

Maybe something like this should be done in the official version as well?


-Morgan-

On Fri, Dec 5, 2008 at 1:05 AM, Christophe Thommeret <hftom at free.fr> wrote:
> 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