Jump to content

[EN] Twinhan Cab-CI 2033 1.0.5.8 driver


Klaus_1250

Recommended Posts

Sorry for the English, but my German is terrible and there is no English DVB hardware forum.

 

Is there anyone here with access to the Digital Rise forums (e.g. who has a Digital Rise DVB-C PCI Cable CI card) and can download and post the 1.0.5.8 driver?

 

I've been having problems with my Mantis card ever since I added a second SATA HD to my system. It BSOD's (IRQL_LESS_OR_EQUAL, STOP 0x000000D1, mtsbda.sys) upon heavy disc-access and randomly when DVBViewer Pro starts :-( Tried all possible solutions, but to no avail. Contacting both Twinhan and AzureWave has resulted in one read-receipt :-(

 

The 1.0.5.8 driver supposedly fixes the BSOD's but are only available through the Digital Rise forums (Twinhan site has 1.0.5.4, Digital Rise site has 1.0.5.6) Since the BSOD's are driving me nuts, I would appreciate if anyone could post the 1.0.5.8 driver here :-) The thread with the 1.0.5.8 can be found here: http://forum.digitalrise.biz/viewtopic.php...sc&start=30

  • Like 1
Link to comment

Hi, just wait another two or three days. I will get my dvb-c card from digitalrise on monday or tuesday. From then on I will have access to the forum. But anyway I am wondering why you dont just register yourself. You should have a twinhan oder digitalrise by yourself dont you? You just have to enter te serial in the reg-form. But I guess you have tried it already. Is your card to old?

Link to comment

I have a Twinhan DTV Cab-CI Mantis, 9 months old or so. As for the serial; they only allow DigitalRise one's. E.g. I tried mine, but to no avail (not registered in database). You can also order a forum registration for 23,80€, but I don't need support. I just need good drivers :-( (and 23,80€ for a driver I'm entitled to through Twinhan is a bit steep).

 

I would highly appreciate it if you can PM or send me the driver, Twinhan and Azurewave just don't reply and they don't update their website either (Twinhan still has 3.2 of DigitalTV posted, and 1.0.3.0/1.0.5.4 of the driver, while DigitalRise has 3.3 and 1.0.5.6/1.0.5.8). Really pissed me off. No up-to-date software to fix the issues, no reply to emails other than read receipts and a website that is not updated and highly outdated.

 

If it wasn't for DVBViewer and the Alphacrypt, I would be a very dissatisfied customer.

Link to comment

For those interested. The 1.0.5.8 driver seems to address DPC-latency and no more BSOD's (at least for now), but it does come at a penalty: Switching transponders takes well over 6 seconds. Switching channels on the same transponder: 1.2s (FTA) to 2.5s (ENC). Switching channels on different transponder: 7.5s (FTA) to 8.5 (ENC). Transedit scans also take quite a long time now.

Edited by Klaus_1250
Link to comment
  • 2 weeks later...

Twinhan has updated the driver to 1.0.5.9 in the Digital TV 3.3 build 08 package. Unfortunately, the slow switching of transponders is still present.

Link to comment

It does seem they changed something in the diseqc stuff in 1.0.5.8. It doesn't work anymore with the viewer. ^_^ Maybe the 1.0.5.9 driver adresses this, I can't test it, have no diseqC.

Link to comment

It seems the 1.0.5.9 does initialize the card way faster than the 1.0.5.8 driver. Hint if you don't need diseqC deactivate it in the channellist editor. The function call for it takes quite some time.

 

Oh and you have to download digitalTV from the twinhan site. The drivers only downloads there are old ones (1.0.5.4) even if the say they are 1.0.5.9, at least the drivers I just downloaded there.

Link to comment

The Twinhan site is a mess regarding downloads (and slow). Yesterday the 3.3 download still pointed to the 3.2, but they changed it today. I've put the 1.0.5.9 driver in a rar-file, but it is 639KB (can't upload it as a attachment).

Link to comment

No please do not upload driver or such things here. Without the consense of the owner of the rights on the software (twinhan) we could get serious problems...

Link to comment

Sorry, I thought a 30MB download for a driver was a bit much, but you can find the driver at Digital Rise now.

 

In any case, still long (10sec) channel switch times and I managed to get an 0x7E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) out of the driver under Low Resource simulation with Driver Verifier. Looking at the issues people are having, it seems to me they don't have a beta-test group, which makes sense since they do not seem to communicate directly with customers, only through distributors.

Edited by Klaus_1250
Link to comment

Hi Klaus,

 

1.0.6.0 driver is now up for testing @ Digital Rise.

 

thx for the info. ATM I am running the 1.0.5.9 driver with Windows XP without problems. Nevertheless there are discontinuities as with all previos driver versions. Now I was able to compare the Twinhan card with my older Cablestar2, and with both cards switched to the same frequency, the cablestar does not show the discontinuities while the Twinhan does. So I am hoping for a driver which possibly fixes this problem.

 

Seems that the 1.0.6.0 driver is only availabe for forum members at digital rise ?

 

Edit:

 

Ok, I was able to grab a copy of the 1.0.6.0 WinXP drivers ( thx to the donator ) and for me there is no noticable change against previos versions; the discontiunities are still there. For that reason I am now trying to get the Twinhan 2033 unter Linux to see if this is a driver issue or a hardware issue.

 

Does anybody here tried / managed to get the linux drivers from manu abraham or Twinhan to work within a kernel 2.6.20 enviroment ? Both modules are loading without error messages ( mantis.ko and cu1216.ko ), but the tuner driver is not able to lock onto any frequency.

 

C.U. NanoBot

Edited by NanoBot
Link to comment

The Twinhan-Cab-Ci discontinuities problem is something that seems hard for Twinhan to solve (are they even trying?)...if Twinhan after so many years still release hardware/software with this problem - they are not doing their job and are cheating their customers with a 'fake' product.

 

I have used a 2031 and recently a 2033, both with discontinuity/loss of sync errors (2033 is a bit more stable). I tried the cards with the latest BDA, WDM(only 2031) or linux(only 2031, due to lacking cam support for 2033) drivers and the problem persists...so Twinhan fails where FireDTV or TechnoTrend are doing fine...

Link to comment

Regarding Twinhan. I don't think they have a real driver developer or not enough of them. Seems to me they just made the hardware and figured that was enough, forgetting that drivers make or break hardware. In their case mostly the latter. Same goes for the software player. It is pretty next to useless. If they were smart, they would try to get an OEM-license for DVBViewer or something :-)

 

Combining these with the fact that they seem to refuse communication, support, after-sales and proper marketing, I conclude that there are serious management issues. And they don't seem to be improving with Azurewave / ASUStek.

Link to comment

Hi,

 

I would like to report that I was finally able to compile working linux drivers, especially a working driver for the cu1216 frontend, for the Mantis 2033 and kernel 2.6.20-16 x64.

 

Now I will try to modify either femon or dvbsnoop to count either the uncorrected packets, the missing packets or both over a longer time. If the card shows the same behavior concerning missing packets under linux it is clear, that the hardware design is buggy. But if there are no missing packets under linux this would proof that either the windows driver itself, or the BDA system from windows itself is buggy.

 

C.U. NanoBot

 

P.S.: The drivers are without ci support, but ci support is not needed to investigate the problem of the missing ts packets anyway.

Edited by NanoBot
Link to comment
If the card shows the same behavior concerning missing packets under linux it is clear, that the hardware design is buggy.

 

Or it shows that the linux driver just have the same bug, the windows drivers have.. :)

Link to comment

Hi Moses,

 

Or it shows that the linux driver just have the same bug, the windows drivers have.. ;)

 

Yeah, thats another possibility :)

 

ATM I am checking the received stream with

 

dvbsnoop -adapter 1 -s ts -tsraw -ph 0 | grep "continuity error"

 

and it looks like dvbsnoop is able to analyze the complete stream at once. My other card, the cablestar2 is not able to deliver the whole TS without errors. And of course let's see if there are packets lost or not.

 

Edit: Ok, the cards hardware itself seems to be the problem:

 

nanobot@Aladin:~$ dvbsnoop -adapter 1 -s ts 767 -ph 0 | grep "continuity error"

continuity_counter: 13 (0x0d) [= (continuity error!)]

 

while the cablestar2 running parallel does not show this error. This error occured about 10 minutes after I started the test, and thats about the same time window when an error occur under windows.

 

And I have a dumb idea what could be the problem, because lspci shows the following data about the cards:

 

05:06.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)

Subsystem: Twinhan Technology Co. Ltd Unknown device 0008

Flags: bus master, medium devsel, latency 32, IRQ 16

Memory at c6000000 (32-bit, prefetchable)

 

05:07.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)

Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card

Flags: bus master, slow devsel, latency 32, IRQ 17

Memory at c5000000 (32-bit, non-prefetchable)

I/O ports at a000

 

4kByte of Ram for buffering / transferring a stream with upto 50 MBit/s might be a little less, or what do you think ? I will back check this by analyzing a qam64 transponder which has only about 35 Mbit/s.

 

C.U. NanoBot

Edited by NanoBot
Link to comment
4kByte of Ram for buffering / transferring a stream with upto 50 MBit/s might be a little less, or what do you think ? I will back check this by analyzing a qam64 transponder which has only about 35 Mbit/s.

 

C.U. NanoBot

 

Hi Nanobot,

 

The classic 3c905C 10/100Mbit netcard also has a 4Kb buffer (2Kb for receive and 2Kb for transmit FIFO buffers). Of course the netcard can always ask for a missed packet to be retransmitted, but looking at ifconfig's output it doesn't seem to be missing any packets....

 

RX packets:13179429 errors:0 dropped:0 overruns:1 frame:0

TX packets:7430715 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:4209362490 (3.9 GiB) TX bytes:754671300 (719.7 MiB)

 

So it seems to be very possible with such a 'small' buffer!

 

Ciao from Cloudy

Link to comment

Hi cloudy,

 

thanks for that information.

 

I am now trying to increase the PCI latency of the Twinhan card within the driver to see if that might help.

 

C.U. NanoBot

Link to comment
  • 3 weeks later...

Any news regarding this issue - lately I have had a lot of problems with my 2033 Mantis under Windows. The stream is OK for the first 10-15 minutes of the recording, then a burst of errors and the card never recovers from that.

Link to comment
  • 2 weeks later...

You might want to try the most recent (beta) drivers, 1.0.8.0 which you can find @ the digital rise forum or through some Mantis-owners here. I have a similiar issue, after about 10-15 minutes of watching there usually is a very small discontinuity or glitch, but it is very minor. Can you describe the exact issue ("burst of errors" and "not recovering").

 

I still have a mixed opinion about the most recent drivers. Switching transponders is back to normal speed, but switching to encrypted channels is much slower (4-5s, was 2.5-3s).

Edited by Klaus_1250
Link to comment

Hi,

 

I did a few more tests with the mantis 2033 under linux using a PCI latency of 64. I did this tests by monitoring only the video PID of a QAM256 modulated program parallel with the cablestar2 and the mantis. To do that I used czap and dvbsnoop.

 

The result: With the mantis card, the number of discontinuites seems to be a bit lower than with the default latency of 32, but they are still there. Nevertheless the cablestar2 did not show discontinuities at all.

 

But what may cause the problem:

 

Either the tuner of the mantis ( philips cu1216 based ) is not as good as the tuner of the cablestar ( stv0297 based ). Or the problem is, that the cablestar2 has hardware PID filters in the B2C2 chip, while the Mantis chip does not have hardware PID filters. The latter means that the mantis driver has to do the PID demultiplexing completly in software.

 

Please, would anybody be so kind to donate the 1.0.8.0 windows drivers to me, so I can test them too ?

 

C.U. NanoBot

Link to comment
You might want to try the most recent (beta) drivers, 1.0.8.0 which you can find @ the digital rise forum or through some Mantis-owners here. I have a similiar issue, after about 10-15 minutes of watching there usually is a very small discontinuity or glitch, but it is very minor. Can you describe the exact issue ("burst of errors" and "not recovering").

 

I still have a mixed opinion about the most recent drivers. Switching transponders is back to normal speed, but switching to encrypted channels is much slower (4-5s, was 2.5-3s).

I haven't been able to get a hold of the new 1.0.8.0 drivers so far.

 

However, I might have fixed the problem. I read from another forum that the Twinhan card is badly shielded so I wrapped two layers of aluminum foil around the end of the card where the tuner lies (with one layer of regular paper first to isolate the foil from the card and the components) and connected the foil to the PC case. I did a test capture of 7-8 minutes, capturing 5 channels from the same transponder. No discontinuities, no glitches. I'll have to see whether a longer capture will show anything, but at least the signal level rose a few percent and the initial results are good.

 

Also when I earlier tried switching PCI slots and the card was closer to the GeForce 6600GT, the discontinuities occurred more often - this might also indicate bad shielding.

 

Still, it would be very nice if someone could supply me with the latest beta drivers >_< Twinhan probably won't have them available for a very long time.

Link to comment

Hi Boulder,

 

on my 2033 card the tuner is build into a metall case, so it is shielded. So I can't imagine that an additional shielding with aluminium foil would help, but if it really helps in your case I am willing to give it a try. Ore are there other hardware revisions of the 2033 where the tuner is not in a metall case ?

 

And 8 minutes is not enough at all to test for discontinuites, could you please repeat the test with a duration of at least the length of a movie, let's say, at least 2 hours ?

 

Thanks in advance, NanoBot

 

P.S.: Just doing the first test with the 1.0.8.0 driver, I will report in later

Link to comment

I did a 1.5-hour capture with a particularly troublesome channel and will soon see what comes out when I demux it with ProjectX. Before the extra shielding there were discontinuities and errors reported by ProjectX already in the first couple of minutes. The tuner is inside a metal case but apparently it's not enough.

Link to comment

The test was successful, not a single glitch in the capture according to ProjectX. I guess it proves that improving the shielding of the tuner will help and actually make Twinhan a useful card. I don't know about temperature issues that may arise though, I mostly use DVBViewer for capturing and disable a/v while doing that.

Link to comment

Hi Boulder,

 

I just did the "modification" using three layers:

 

one plastic bag, the aluminium foil and a second plastic bag and fixed it with adhesive plaster :-) Well, the card is ill so it needs a plaster *g*

 

Let's see if the illness is cured with this therapy.

 

C.U. NanoBot

Link to comment

Cheers Boulder, cool you found a solution to this. I'll check back here to see how it's going for you and the metal foil :unsure:

If the card proves to be working correctly, Twinhan should be informed of their problem!

I have since returned the 2033 card, but still have a 2031 lying around. I might be tempted to try the metal foil wrapping although it does sound a bit dangerous >_< I'm surprised the tuner isn't shielded properly, after all it could be used inside a high voltage TV.

Link to comment

Be sure to use anti-static plastic bags. As for the shielding issues. It might well be that the tuner isn't the problem per sé but some components around the tuner or on the card that receive interference from inside the case which is not adequately filtered. One thing that might be causing problems is the extension-cable running from the coax-connector to the tuner, which is rather thin and might not be shielded properly.

 

PS: You can also use transedit to scan for "missing" packets on the whole transponder.

Edited by Klaus_1250
Link to comment
  • 1 month later...

For those interested, there is a new beta driver 1.1.0.100beta2 available for Twinhan Mantis cards: http://forum.digitalrise.biz/viewtopic.php?p=6378#6378

 

Your mileage may vary though: On my XP SP2 32bit system, the new driver causes an instant BSOD upon initialization (present in several earlier beta drivers as well).

 

See also: http://www.DVBViewer.info/forum/index.php?showtopic=21667

Edited by Klaus_1250
Link to comment
Your mileage may vary though: On my XP SP2 32bit system, the new driver causes an instant BSOD upon initialization (present in several earlier beta drivers as well).

 

Please unregister thsource.ax from DVBViewer directory and register thsource.ax from new DigitalTV once again.

I think you try to access the new driver with the thsource.ax installed from DVBViewer ...

 

Martin

Link to comment

Thanx for the suggestions, but I always keep a current version of thsource.ax in the DVBViewer filter dir (with register/unregister script).

 

I managed to circumvent the issue by first starting DigitalTV or by removing the CAM before starting DVBViewer and then plugging it in.

 

PS: Anyone here tried the Linux driver with CI/CAM support? (available on the Twinhan site)

Edited by Klaus_1250
Link to comment
To make sure, I always replace the thsource.ax in DVBViewer with the one of DigitalTV (currently the one of 7-6-2007) to make sure I don't end up with an old one somewhere. DVBViewer doesn't seem to replace this one with its own.

 

After many many attempts, I figured out a way to stop the BSOD from happening. If I remove my CAM (Alphacrypt Classic rev 1.1 with 3.12 firmware) before starting DVBViewer, it starts up ok. Inserting the CAM while DVBViewer is running and going to the hardware options and select that is has a CI, works and doesn't crash DVBViewer or Windows. The only problem is that I'm pretty sure neither the card or the CAM are built for everyday insertion and it takes a lot longer to decrypt the first channel (up to 30 seconds, probably because the CAM loses all the current keys without power).

 

Sorry, but we cannot reproduce this behaviour.

Booting the system with AlphaCrypt CAM inside and using DVBViewer without starting DigitalTV before, never results in BSOD here.

Not with the current Beta driver 1.1.0.100.

 

Could you publish your dump file on a filesharing site like rapidshare?

For Vista: "My computer" - "Properties" - "Advance System Settings" - "Advanced" - "Startup and Recovery Setting"

 

kerneldumpvista.gif

 

Martin

Link to comment

Tried to get a memory dump, but my pagefile is on a seperate drive (e.g. won't work). Moved the Pagefile to C: temporarily, but no BSOD (?!)... Why should the Mantis-driver care where the Pagefile is located? And why is that only an issue when the CAM is used?

Edited by Klaus_1250
Link to comment

Yep. If the pagefile is on C: no problem, but if it is on an other drive, I get a BSOD from the Mantis-driver (but only with the CAM plugged in, without the CAM, it works fine too, regardless of pagefile location).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...