Hi Manu, On Wed, 19 Dec 2007, Manu Abraham wrote: > bbee wrote: >> $ gnutv -channels ~/.czap/channels.conf -out stdout "Nederland 1" | >> mplayer - >> >> This would work fine, but after a while gnutv outputs lots of these lines: >> en50221_app_ai_parse_app_info: Received short data > > After this message is verbosed, what does dst_test, app_info option say ? > dst_test can be found in dvb-apps. There are nonprintable characters in the output, I'll give you dumps. If I run a gnutv -out null command, the output is as follows: Using frontend "DST DVB-C", type DVB-C CAM Application type: 01 CAM Application manufacturer: 4a20 CAM Manufacturer code: 4a20 CAM Menu string: AlphaCrypt CAM supports the following ca system ids: status SCVYL | signal 8800 | snr 1400 | ber 00000000 | unc 00000000 | FE_HAS_LOCK Received new PMT - sending to CAM... Things work fine for a bit, dst_test -a: main: App Info dst_comms: Msg=[9f 80 30 ] dst_comms: Msg=[9f 80 31 ] dst_get_app_info: ================================ CI Module Application Info ====================================== dst_get_app_info: Application Type=[4], Application Vendor=[1542], Vendor Code=[1544] dst_get_app_info: Application info=[*] dst_get_app_info: ================================================================================================== The nonprintable (*) bit is (hexdump): 17 02 17 22 17 62 4a 20 05 Then gnutv will flood these lines: en50221_app_ai_parse_app_info: Received short data During the flood the dst_test -a is: main: App Info dst_comms: Msg=[9f 80 30 ] dst_comms: Msg=[9f 80 31 ] dst_get_app_info: ================================ CI Module Application Info ====================================== dst_get_app_info: Application Type=[0], Application Vendor=[65535], Vendor Code=[65535] dst_get_app_info: Application info=[*] dst_get_app_info: ================================================================================================== The * bit: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff After this gnutv "recovers": CAM Application type: 01 CAM Application manufacturer: 4a20 CAM Manufacturer code: 4a20 CAM Menu string: AlphaCrypt CAM supports the following ca system ids: Then after a while it prints the error lines again. >> The fact that the years-old line 1360 fix hasn't been commited, as well as >> the fact that the CI module driver dst_ca defaults to flooding kernel > > There are exactly 2 card types having the same identification, adding support > for this one card breaks the other card. With that fix in there, in fact almost no > one reported the requirement for the fix Hmm, is there no way to detect at runtime which cards would need the fix? Something must have changed on the card itself, even if the pci id hasn't. Wouldn't like to have to keep making this change in every kernel I compile.. > Regarding the messages, you can just change the module parameter to chose > the amount of logs to be verbosed out. Yes, I was just wondering why being that verbose is the default. > AFAIK, some apps supported this, such as gnutv, VLC, kaffeine, someone had a > patch for MythTV as well, but don't know whether it was used with MythTV. I remeber reading somewhere on the list archive that a unified interface was in the works, is that still gonna happen? If I could get myth to work reliably, I'd be a happy camper, but it seems I'd have to get gnutv to work first. Or doesn't myth use libdvb? If libdvb is at fault, that is. >> Should I be getting rid of this card and getting something that will waste >> a PCI slot?? Anyone else out there still even using it? > > If it is a big headache and doesn't do what you want, better to get rid of it. I just might, if we can't figure it out. Thanks for your help! bbee _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
