Re: [linux-dvb] State of Twinhan Cab-CI 2031 support (old version, non-mantis)
bbee [EMAIL PROTECTED] writes: I do remember seeing a few DVB-C cards that have a CAM slot hanging off a flatcable, for use in a floppydrive slot. The only ones I have found are full-featured, and those can't receive HDTV. Just out of curiosity, do you have the same problem I've been having? I'm not quite sure. My card fails to tune even unencrypted channels. I don't have the logs from my attempts, and I'm a thousand miles away from the card right now. Around a year and a half ago it worked, with some patches, at least for unencrypted channels. I don't think it's fair to ask Manu to do the work if there is so little interest, so I'm just gonna sell the card to somebody who will use it with products from Redmond. Yes, that's probably the way forward for me as well. I'm very tempted to also sell my Alphacrypt CAM, get two PCI DVB-C tuners without CAM, and switch to using my Phoenix reader + a softcam. I'd end up with an extra tuner and 100 euros in my pocket.. If you get that working, I'm very interested in hearing about it, perhaps by mail. Softcams seem to be the big secret, even for completely legal uses. /Benny ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] State of Twinhan Cab-CI 2031 support (old version, non-mantis)
Hi, On Wed, 19 Dec 2007, Benny Amorsen wrote: bbee [EMAIL PROTECTED] writes: On Wed, 19 Dec 2007, Manu Abraham wrote: 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. If you find another budget (as in provides the raw TS) card with built-in CAM slot or a CAM slot that fits in a 3 1/2 slot, please post to the list. I do remember seeing a few DVB-C cards that have a CAM slot hanging off a flatcable, for use in a floppydrive slot. I can't find a replacement for my Cab-CI, and it hasn't been working for more than a year. Just out of curiosity, do you have the same problem I've been having? I don't think it's fair to ask Manu to do the work if there is so little interest, so I'm just gonna sell the card to somebody who will use it with products from Redmond. I'm very tempted to also sell my Alphacrypt CAM, get two PCI DVB-C tuners without CAM, and switch to using my Phoenix reader + a softcam. I'd end up with an extra tuner and 100 euros in my pocket.. bbee ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] State of Twinhan Cab-CI 2031 support (old version, non-mantis)
bbee [EMAIL PROTECTED] writes: On Wed, 19 Dec 2007, Manu Abraham wrote: 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. If you find another budget (as in provides the raw TS) card with built-in CAM slot or a CAM slot that fits in a 3 1/2 slot, please post to the list. I can't find a replacement for my Cab-CI, and it hasn't been working for more than a year. /Benny ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] State of Twinhan Cab-CI 2031 support (old version, non-mantis)
bbee wrote: Hi Manu, 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.. I will try to make it a parameter or something like that, for your card, though a parameter looks ugly, seems like that's the only way out. Lack of testers held this change back for this card. It would require me to search for the old changes again, thought that no one was interested in that change. 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? The unified interface is the libs that you find in the dvb-apps, which is used by gnutv and zap. 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. The easiest is to get things working with a command line application to work first rather than getting mythtv going on It can be a bug in the HLCI part of the library or a bug in the driver that's causing this behaviour, of course this requires quite a bit of debugging. 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 Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] State of Twinhan Cab-CI 2031 support (old version, non-mantis)
bbee wrote: Hi, I have a 2031A Cab-CI I bought a while ago. It was (and I believe still is) the only single pci slot card that supports DVB-C with CAM on linux. Scouring the lists, I managed to get it running a few months ago, but only after applying the fix of commenting out line 1360 of dst.c. (Why hasn't this fix been committed yet? The card is as good as useless without it.) I could watch video with the following command: $ 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. The stream then stops and I have to restart mplayer, but this also happens with -out null. I thought the signal quality might be bad so I didn't post this before, and I left the card alone for a while. Recently I rewired my house and the signal quality (atleast on analog) is much improved, dvbscan/dvbsnoop etc. still work fine, but I still get the gnutv message periodically. Moreover, the above command no longer works, mplayer says: Seek failed No stream found. Exiting... (End of file) I have gone through a couple kernel revisions in the meantime, so something must have changed while I haven't been using the card. It might also be the CAM's fault, but I don't see why that should have stopped working or how to debug it. Any ideas? Another thing I wasn't aware of when I bought the card was the fact that it has a nonstandard method of accessing the CI, I believe it's called high level CI or the like; it seems only some Twinhan cards use it and almost no software supports it. VLC seems to have (had?) support. I remember reading about the card on the mythtv changelog - mythtv is what I was after in the first place, so I was hopeful I could get it running and itegrated into mythtv. 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 Regarding the messages, you can just change the module parameter to chose the amount of logs to be verbosed out. messages when you use it, leads me to think the driver is really in an alpha state and isn't being developed or supported. If this is true, why is this driver even in mainline kernel, shouldn't it be dropped? Is anyone still working on a unified CI framework so more software might end up supporting the CI on this card? 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. 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. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] State of Twinhan Cab-CI 2031 support (old version, non-mantis)
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 | unc | 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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
