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? Best regards Morgan _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
