TBS: CI/CAM support and other improvements (9 Viewers)

[mm1352000]

Addition from FreakyJ

You can find the latest version of the patch compatible with MP 1.4 only here:
https://forum.team-mediaportal.com/...ther-improvements.103276/page-37#post-1017094

You can find the latest version of the patch compatible with MP 1.6 PR and newer here:
https://forum.team-mediaportal.com/...ther-improvements.103276/page-51#post-1051247


Original Post from mm

Hi everyone

For quite a while now I've been quietly working on adding support for TBS's great new products, especially those that have a CI interface:

TBS5922 (single DVB-S2 USB)
TBS5925 (single DVB-S2 USB with advanced professional capabilities)
TBS5980 (single DVB-S2 USB with CI slot)
TBS6922 (single DVB-S2 PCIe)
TBS6925 (single DVB-S2 PCIe with advanced professional capabilities)
TBS6928 (single DVB-S2 PCIe with CI slot)
TBS6984 (quad DVB-S2 PCIe)
TBS6992 (dual DVB-S2 PCIe with CI slots)

I've had several delays and setbacks with the release of MP 1.2 and my computer dying, however I'm very happy to report that I now have something for everyone to test.

Features

The biggest new feature is support for the CI:

- decryption of encrypted channels [working]
- CI menu support [working]
- decryption of multiple encrypted channels on a single transponder [working]

In addition to the the new CI/CAM support there are many other improvements to ensure that MediaPortal works 100% reliably with TBS products:

- DiSEqC support rewritten with support for new parameters and products [working]
- potentially faster custom tuning method added for QBOX products [working] Update - 06/01/2012: access removed from new TBS SDK
- explicit QBOX DiSEqC support added [working]
- tone/data burst (simple DiSEqC) support added for both PCI/PCIe and QBOX products [working]
- explicit 22k tone support added for both PCI/PCIe and QBOX products [working]
- explicit DVB-S2 tuning support for potentially faster tuning added for both PCI/PCIe and QBOX products [experimental, partially tested]
- explicit LNB power control support for potentially lower power consumption added for both PCI/PCIe and QBOX products [experimental, partially tested]

Several people have reported problems using MP with newer TBS products over the past couple of months. Especially with DiSEqC switching. I hope that these improvements will solve the problems.

Feedback

I have not been able to test all of the features as I do not own all of TBS's products D), however I've tested the changes as thoroughly as I can. I'm now asking for everyone's help to test *all* the features (even the ones I've already tested) to confirm that everything is working nicely.

If you have a problem please be sure to:
1. Mention the product(s) that you're testing with.
2. Post full logs (instructions -->here<--).
3. Describe what happened, when it happened, and what you expected to happen.

I will be here to provide support and updates if there are problems.

I also want to hear from you and check your logs even if things seem to work perfectly. Your feedback helps me to confirm that the code is working properly, not just by chance.

Installation Instructions

To get access to these features you will need to install the files in the attached zip archive. These files are only compatible with MediaPortal 1.2.1 (I will provide updates if further improvements or fixes are added, and I'll also provide support for newer versions of MediaPortal).

0. Install the latest driver for your device. This is *really* important.
1. Close MediaPortal, stop the TV service and close TV Server configuration.
2. Take a backup of the TsWriter.ax, TVLibrary.dll, and TvLibrary.Interfaces.dll (added in TBS[2.0].zip) files in your TV Server install folder (typically C:\Program Files (x86)\Team MediaPortal\MediaPortal TV Server).
3. Download and extract the attached zip file into your TV Server install folder.
4. Rename one of the TVLibrary.dll.*** files to TVLibrary.dll (see the details below).
5. Copy the TvLibrary.Interfaces.dll from the patch into your MediaPortal install folder.
6. Start the TV service.
7. Enjoy!

Note that you may also need to install the Microsoft Visual C++ 2010 redistributable from -->here<-- (use the x86 32 bit version even on 64 bit operating systems).

Multiple Channel Decryption

There are 3 TVLibrary.dll files in the zip archive. They are for testing the experimental multiple channel decryption feature. To be very clear: your CAM must support decrypting multiple channels simultaneously for the feature to work. The TBS drivers and DLL must also support this feature - support here is a little unknown at this point since I don't have an appropriate CAM to test with ().

The three versions:

• TVLibrary.dll.cam - this DLL relies completely on the CAM to enable the feature; in my opinion it has the lowest chance of success but is probably the most reliable for single channel decryption
• TVLibrary.dll.exp - this DLL uses explicit instructions to tell the CAM which channels to decrypt; it is the most likely to work with both single and multiple channel decryption
• TVLibrary.dll.diff - this DLL uses "loose" instructions to tell the CAM which channels to decrypt; it is less likely to work than TVLibrary.dll.exp, however if it does work then it may be faster and avoid small glitches in recordings and viewing when you start viewing/recording a new encrypted channel

Update - 16/12/2011
I can now confirm that this feature does work if you have an appropriate CAM.

Known Issues

I make no guarantees that any of these features will work so I don't recommend testing on a "production" system. However, I will be here to provide support as I have already said so I hope you will be willing to help me to test.

These are the issues that I know about at the moment.
1. Sometimes the CI/CAM menu does not show all possible entries. This seems to be a bug in the TBS driver or DLL (possibly only affecting my CAMs).
2. Some CAMs are not compatible. One of my CAMs - an Irdeto CAM like -->this<-- does not work at all for me.]


Update - 16/12/2011
The first issue with missing CAM menu entries is still outstanding. The second issue may be a non-issue. It turns out that the 5980 sample that I received may have been a pre-production unit. Hardware changes were made later that resolved the compatibility with some CAMs. I've received a second sample that works perfectly with the CAM that was previously not working.

Update - 06/01/2012
TBS released a new SDK with significant changes and MP 1.2.2 was also released on 23/12/2011. I'm releasing TBS[2.0].zip as a result. This new version has a new file that must be patched (TvLibrary.Interfaces.dll) in both your MP and TV Server installation as well as an updated TbsCIapi.dll - please use the provided DLL rather than the one from the TBS website. The DLL that I'm providing is a "beta" DLL that I received from TBS which resolves the first issue about missing CAM menu entries => no outstanding issues.


Lastly: TBS kindly sent me a sample TBS5980 CI to work with. ***BIG*** thanks to all the good people at TBS for their support!

Best regards,
mm

 

[DJBlu]

Any chance of the patch file?

I am suffering from slow channel changes from DVB-S to DVB-S2 would like to try this out.

Just given this a whirl and the TVServer keeps crashing.

Using 2xTBS 6981

Log below

Thanks

 

[mm1352000]

Hi DJBlu

I'd prefer not to provide the patch file at this time. My intention is to create a Git branch when I can figure out how to do that (I'm still working with SVN) and I'd welcome your input once that is up.

About the slow channel changing problem: as suggested on the internal forum I think that the modulation parameters that are being passed in the tune request are possibly wrong. The above DLLs specify when tuning to a DVB-S or DVB-S2 channel explicitly using a TBS interface so I expect they would help if they worked for you. Can you confirm whether it is DVB-S => 8 PSK DVB-S2, DVB-S => QPSK DVB-S2, or both that are slow? I only have 8 PSK channels here so can't test QPSK.

As for the error causing the crash here the issue seems to be:

2011-12-07 17:05:16.637163 [(5)]: Turbosight: IsCiSlotPresent result = True

2011-12-07 17:05:16.637163 [(5)]: Turbosight: IsCamReady result = False

Obviously a 6981 doesn't have a CI slot. I'll look at the code tonight and see what is going on.

mm

 

[DJBlu]

It is dvb-s -> DVB-S2 QPSK

Setting the channel data correctly still has a tune time of 2-3 seconds. I have tried all sorts.
I am waiting on a 6984 which should be arriving tommorow. I will test when it arrives.

 

[stene]

I have a TBS6984 and i had problems with diseqc before but now with this patch my initial tests are successful. I have only installed the patch, tried scanning (4x diseqc switch) and so far everything seems to work as expected. I will continue testing later this week but it sure looks promising.

 

[mm1352000]

I have a TBS6984 and i had problems with diseqc before but now with this patch my initial tests are successful. I have only installed the patch, tried scanning (4x diseqc switch) and so far everything seems to work as expected. I will continue testing later this week but it sure looks promising.

Fantastic!
Thanks for the feedback.
If you have a chance I would really like to get a quick look at your TV Server logs. No rush though...

It is dvb-s -> DVB-S2 QPSK

That will be the problem. We don't handle DVB-S2 QPSK correctly in our current code, but that should be fixed in my patches. Try changing the modulation for the DVB-S2 QPSK channel to OQPSK and make sure the correct FEC rate is set. If the actual FEC rate is 8/9 then use 5/11. Likewise, if it is 9/10 use 7/8. Otherwise use the real FEC rate. The other question would be: does this QPSK channel require pilot or rolloff settings?

mm

[Edit: I take it you're using the latest driver?]

 

[superbaton]

Hi mm1352000,

I made some test with my TBS 5980 CI and your patch. I am using following configuration on my HTPC
- backend: TVServer 1.2.1
- frontend: XBMC PVR pre-eden with MediaPortal (TSReader) (margro bulid >> XBMC - Prebuild versions with (experimental) PVR support <<)
- your patch (TVLibrary.dll.cam)

After my tests I can say that:
1. Channel scanning work very good
2. I can access my CAM module menu without any problems. I using Conax module (nCAM HD form following polish providers "Telewizja na Karte" and "n na Karte")
3. All decrypted channels from my subscription are working right now. I am able to watch them using preview function in TV-Server.
4. However I found some problem when I tried to switch between channels in my XBMC frontend. After fresh start up tuning channels work, but when I do not watch TV my TV-card go to idle state (red diode instead of blue) and I am not able to switch on any channel. Other issue is that when tuned channels and I am going through my channel list in my frontend, the channel which I currently tuned stops after while. I’m not able to say it is something wrong with my frontend or TVServer?

I attached logs files from today. During this test I run one paid channel from my frontend and tried to switch in between channels. After third or fourth change I was not able to see any picture on my frontend.

Next week I have holidays so I will be able to test more extensively your patch, probably with MediaPortal and XBMC PVR as frontend.

Once again thanks for great job.

Regards,
superbaton

 

[mm1352000]

Hi superbaton

Thanks for the logs and feedback!

4. However I found some problem when I tried to switch between channels in my XBMC frontend. After fresh start up tuning channels work, but when I do not watch TV my TV-card go to idle state (red diode instead of blue) and I am not able to switch on any channel. Other issue is that when tuned channels and I am going through my channel list in my frontend, the channel which I currently tuned stops after while. I’m not able to say it is something wrong with my frontend or TVServer?

I think it is a problem with the XBMC PVR plugin, but it could be a mixture of TV Server as well. In the logs I see:

2011-12-08 07:17:07.630398 [(19)]: TVServerXBMC: Exception while processing connection: System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)

at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)

--- End of inner exception stack trace ---

at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)

at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)

at System.IO.StreamWriter.Flush()

at TVServerXBMC.Commands.DataWriter.write(String line)

at TVServerXBMC.ConnectionHandler.WriteLine(String line)

at TVServerXBMC.ConnectionHandler.handleCommand(String command, String[] arguments)

at TVServerXBMC.ConnectionHandler.ProcessConnection(StreamReader reader)

2011-12-08 07:17:07.630398 [(19)]: TVServerXBMC: Connection closed

2011-12-08 07:17:07.723998 [(31)]: TVServerXBMC: Exception while processing connection: System.Threading.AbandonedMutexException: The wait completed due to an abandoned mutex.

at System.Threading.WaitHandle.WaitOne(Int64 timeout, Boolean exitContext)

at System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean exitContext)

at System.Threading.WaitHandle.WaitOne()

at TVServerXBMC.ConnectionHandler.handleCommand(String command, String[] arguments)

at TVServerXBMC.ConnectionHandler.ProcessConnection(StreamReader reader)

This happens after a conflict where you try to use the tuner while the EPG grabber is still using it. The conflict is probably the fault of TV Server and gibman is working on a resolution for that. What happens after the conflict seems to be the fault of the XBMC PVR plugin. TV Server keeps on working grabbing EPG after that error but I can't say what happens on the frontend.

Unfortunately I'm not able to provide good support for your configuration. I really do know nothing about XBMC or the PVR functions. You could try disabling the EPG grabber and see if that helps. If you have logs for the situation where the channel stops after a while in the frontend then I would be happy to look at those as well.

mm

 

[superbaton]

Hi mm1352000,

Thanks for your anwser. One probelm colud be on TVServer side, but found also info on github site of my XBMC PVR that XBMC PVR can crash during livetv channel changing when EPG data are missing. It was fixed yesterday, but I it isn't included in current version of XBMC-PVR.

I will test your patch also by using MediaPortal as backend and frontend with turned off EPG grabbing, then will see if I can overcome my problems. I will post my log files.
I also will try to switch off the EPG grabing in MP-TVServer and in my XBMC PVR plugin and see whats happen.
EPG grabbing for me is not crucial function

Best regards,
superbaton

 

[DJBlu]

I'd prefer not to provide the patch file at this time. My intention is to create a Git branch when I can figure out how to do that (I'm still working with SVN) and I'd welcome your input once that is up.

tourettes has written a great guide on how to use github.

Just tried your suggestions.

2011-12-08 11:25:07.584756 [(28)]: dvb: Submit tunerequest calling put_TuneRequest
2011-12-08 11:25:10.236761 [(28)]: dvb: Submit tunerequest done calling put_TuneRequest

Still getting 3 second delays.

I'll hang on for your changes as we can live with the slow change at the moment.

If you need any help then let me know.