Moderator Control Panel ]

TBS6984 and vdr-sasc-ng

Re: TBS6984 and vdr-sasc-ng

Postby djkiller » Sat Sep 17, 2011 5:12 pm

You're welcome :)
djkiller
 
Posts: 6
Joined: Mon Aug 29, 2011 4:23 am

Re: TBS6984 and vdr-sasc-ng

Postby fibres » Mon Sep 19, 2011 2:14 am

Hi Guys

I have just bought this card.

I have installed the drivers after applying the patch as per the above instructions.

I have installed sasc from hg, however is have updates to rev 570 as that is apparently the latest version that works properly.

I tried applying the patch from the howto but when I do this sasc fails to compile.

I tried copying the dff above into a file and applying using patch -p1 < fileabove.patch and that fails. I have gone through the file and made some changes as per the above patch but half the lines above are not in the cam.c I have and the lines that are when changed fail to compile.

Without the patch it compiles and connects to my cccam server running on a Dreambox with my Paytv card in.

The only trouble is the picture keeps freezing.

Everything works ok. Free channels are fine but when on paytv the picture freezes for a few secs every few mins. Sometimes it clears and other times it freezes for too long and causes myth to drop out.

Anyone got any clue as to why this happens?

Regards
fibres
 
Posts: 1
Joined: Mon Sep 19, 2011 1:54 am

Re: TBS6984 and vdr-sasc-ng

Postby nickfudge » Mon Oct 03, 2011 3:01 pm

djkiller Wrote:
nickfudge Wrote:There's a couple of problems. The SET_CA_DESCR error was a code bug, which was fixed a couple of days ago, so you need to fetch the latest sources. Having done that, you should find that encrypted channels will be decrypted, but then sasc-ng will likely lock-up.

I've written the following patch which will get you a stable picture when using sasc-ng's newcamd cardclient protocol -- I haven't bothered porting the patches to the other cardclient protocols because I'm still trying to improve the overall stability of sasc-ng. I'd push these patches upstream, but I've not got an e-mail address for the author.


Thank you soooooo much :). I tried your patch, but I had problem applying a patch to last vdr-sasc-ng source codes. Finally I made some modifications manually, but I'm not sure if everything correctly. Can you please make diff from last source codes from http://85.17.209.13:6100/sc?

I tried the version with your patch and clean from the repository, both work, but time is a problem with communication after newcamd:

[cardclient.newcamd] 0004 msgid bad! = 0003
Sep 15 12:38:18.438 [cardclient.newcamd] sync error msg ID. Retrying ...

I'll help you to debug everything. :)


OK, so after a couple of weeks of testing and experimentation, here's the patch that I now use. It fixes a couple of startup crash bugs and fixes that "sync error msg ID" too. The diff was created from a sync against the source tree of today.

Code: Select All Code
diff -r 442eee2f550d cam.c
--- a/cam.c   Sun Oct 02 21:09:13 2011 +0200
+++ b/cam.c   Mon Oct 03 07:50:27 2011 +0100
@@ -65,6 +65,7 @@
 #define L_HEX_HOOK  LCLASS(L_HEX,32)
 #define L_HEX_ALL   LALL(L_HEX_HOOK)
 
+
 static const struct LogModule lm_hex = {
   (LMOD_ENABLE|L_HEX_ALL)&LOPT_MASK,
   (LMOD_ENABLE)&LOPT_MASK,
@@ -2277,13 +2278,21 @@
 
 void cCam::Tune(const cChannel *channel)
 {
-  cMutexLock lock(&camMutex);
-  if(source!=channel->Source() || transponder!=channel->Transponder()) {
-    source=channel->Source(); transponder=channel->Transponder();
-    PRINTF(L_CORE_PIDS,"%s: now tuned to source %x(%s) transponder %x",devId,source,*cSource::ToString(source),transponder);
+  bool stop = false;
+  {
+    cMutexLock lock(&camMutex);
+    if(source!=channel->Source() || transponder!=channel->Transponder()) {
+      source=channel->Source(); transponder=channel->Transponder();
+      PRINTF(L_CORE_PIDS,"%s: now tuned to source %x(%s) transponder %x",devId,source,*cSource::ToString(source),transponder);
+      stop = true;
+    } else {
+      PRINTF(L_CORE_PIDS,"%s: tune to same source/transponder",devId);
+    }
+  }
+
+  if (stop) {
     Stop();
-    }
-  else PRINTF(L_CORE_PIDS,"%s: tune to same source/transponder",devId);
+  }
 }
 
 void cCam::PostTune(void)
@@ -2500,7 +2509,7 @@
 
 void cCam::LogEcmStatus(const cEcmInfo *ecm, bool on)
 {
-  cMutexLock lock(&camMutex);
+  //cMutexLock lock(&camMutex);
   if(on) LogStartup();
   if(logger) logger->EcmStatus(ecm,on);
 }
diff -r 442eee2f550d contrib/Makefile
--- a/contrib/Makefile   Sun Oct 02 21:09:13 2011 +0200
+++ b/contrib/Makefile   Mon Oct 03 07:50:27 2011 +0100
@@ -21,7 +21,7 @@
 
 
 cccam_ca.so: cccam_ca.c
-   gcc -O -fbuiltin -fomit-frame-pointer -fPIC -shared -o $@ $< -ldl
+   gcc -O -m32 -fbuiltin -fomit-frame-pointer -fPIC -shared -o $@ $< -ldl
 
 bsdiff:      bsdiff.c
    gcc -O3 -o $@ $< -lbz2
diff -r 442eee2f550d contrib/sasc-ng/dvblb_plugins/plugin_cam.c
--- a/contrib/sasc-ng/dvblb_plugins/plugin_cam.c   Sun Oct 02 21:09:13 2011 +0200
+++ b/contrib/sasc-ng/dvblb_plugins/plugin_cam.c   Mon Oct 03 07:50:27 2011 +0100
@@ -260,6 +260,7 @@
 
   if (sidmsg->calen == 0) {
     free_sidmsg(sidmsg);
+    msg->type = MSG_PROCESSED;
     return;
   }
   for(ch=Channels.First(); ch; ch=Channels.Next(ch)) {
@@ -280,6 +281,7 @@
         }
       }
       free_sidmsg(sidmsg);
+      msg->type = MSG_PROCESSED;
       return;
     }
   } else {
diff -r 442eee2f550d contrib/sasc-ng/dvblb_plugins/plugin_ffdecsa.c
--- a/contrib/sasc-ng/dvblb_plugins/plugin_ffdecsa.c   Sun Oct 02 21:09:13 2011 +0200
+++ b/contrib/sasc-ng/dvblb_plugins/plugin_ffdecsa.c   Mon Oct 03 07:50:27 2011 +0100
@@ -123,11 +123,13 @@
           pthread_mutex_unlock(&csa->state_lock);
           return;
         }
+        pthread_mutex_lock(&csa->keylock);
         if(! csa->keyindex[index].valid) {
           csa->keyindex[index].valid = 1;
           csa->keyindex[index].status = 0;
           csa->keyindex[index].queued = 0;
         }
+        pthread_mutex_unlock(&csa->keylock);
         pop_entry_from_queue_l(pid_ll, &pidmap_empty_queue, struct pid, &list_lock);
         pid_ll->pid = pid;
         pid_ll->index = index;
@@ -146,7 +148,9 @@
           ll_find_elem(pid_ll, csa->pid_map, index, index, struct pid);
           if(pid_ll == NULL) {
             //no valid pids on this index
+            pthread_mutex_lock(&csa->keylock);
             csa->keyindex[index].status = 0;
+            pthread_mutex_unlock(&csa->keylock);
             if(list_empty(&csa->pid_map)) {
               //state = ENCRYPTED_NOT_READY;
               csa->state = NOT_ENCRYPTED;
diff -r 442eee2f550d contrib/sasc-ng/dvbloopback/src/msg_passing.c
--- a/contrib/sasc-ng/dvbloopback/src/msg_passing.c   Sun Oct 02 21:09:13 2011 +0200
+++ b/contrib/sasc-ng/dvbloopback/src/msg_passing.c   Mon Oct 03 07:50:27 2011 +0100
@@ -46,11 +46,16 @@
 {
   struct msgctrl *msgctrl;
   int priority;
+  int x;
   for (priority=0; priority <= MSG_HIGH_PRIORITY; priority++) {
     msgctrl = &message_control[priority];
     bzero(msgctrl, sizeof(struct msgctrl));
     INIT_LIST_HEAD(&msgctrl->msglist);
     INIT_LIST_HEAD(&msgctrl->empty_queue);
+    for (x = 0; x < 10; x++) {
+      struct msg *msg = (struct msg *)malloc(sizeof(struct msg));
+      list_add(&msg->list, &msgctrl->empty_queue);
+    }
     pthread_mutex_init(&msgctrl->mutex, NULL);
     pthread_cond_init(&msgctrl->cond, NULL);
   }
@@ -95,6 +100,8 @@
         list_del(&msg->list);
         break;
       }
+      if (!msg)
+        break;
       //If we've seen all elements on the queue, or the queue is empty,
       //we are done
       if(ptr == &msgctrl->msglist)
diff -r 442eee2f550d contrib/sasc-ng/sc/sasccam.cpp
--- a/contrib/sasc-ng/sc/sasccam.cpp   Sun Oct 02 21:09:13 2011 +0200
+++ b/contrib/sasc-ng/sc/sasccam.cpp   Mon Oct 03 07:50:27 2011 +0100
@@ -16,7 +16,7 @@
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
  */
-
+
 #define SASC
 
 #include <stdlib.h>
@@ -41,14 +41,12 @@
 
 bool cScSascDevice::SetCaDescr(ca_descr_t *ca_descr, bool initial)
 {
-  printf("Called cScSascDevice::SetCaDescr\n");
   _SetCaDescr(cardIndex,ca_descr);
   return true;
 }
 
 bool cScSascDevice::SetCaPid(ca_pid_t *ca_pid)
 {
-  printf("Called cScSascDevice::SetCaPid\n");
   _SetCaPid(cardIndex,ca_pid);
   return true;
 }
--- a/systems/cardclient/cc.c   Sun Oct 02 21:09:13 2011 +0200
+++ b/systems/cardclient/cc.c   Mon Oct 03 07:50:27 2011 +0100
@@ -110,7 +110,7 @@
 
 bool cCardClient::SendMsg(const unsigned char *data, int len)
 {
-  if(!so.Connected() && !Login()) return false;
+  if(!so.Connected() /*&& !Login()*/) return false;
   if(so.Write(data,len)<0) {
     PRINTF(L_CC_CORE,"send error. reconnecting...");
     Logout();
@@ -121,7 +121,7 @@
 
 int cCardClient::RecvMsg(unsigned char *data, int len, int to)
 {
-  if(!so.Connected() && !Login()) return -1;
+  if(!so.Connected() /*&& !Login()*/) return -1;
   int n=so.Read(data,len,to);
   if(n<0) {
     if(errno==ETIMEDOUT && (len<0 || to==0)) return 0;
diff -r 442eee2f550d systems/cardclient/newcamd.c
--- a/systems/cardclient/newcamd.c   Sun Oct 02 21:09:13 2011 +0200
+++ b/systems/cardclient/newcamd.c   Mon Oct 03 07:50:27 2011 +0100
@@ -472,17 +472,25 @@
 
 bool cCardClientNewCamd::ProcessECM(const cEcmInfo *ecm, const unsigned char *data, unsigned char *cw)
 {
-  cMutexLock lock(this);
-  if((!so.Connected() && !Login()) || !CanHandle(ecm->caId)) return false;
-  so.Flush();
+  if (!CanHandle(ecm->caId))
+    return false;
+  {
+    cMutexLock lock(this);
+    if (!so.Connected() && !Login())
+      return false;
+    so.Flush();
+  }
 
   struct CustomData cd;
   InitCustomData(&cd,(unsigned short)ecm->prgId,0);
-  if(!SendMessage(data,SCT_LEN(data),true,&cd)) return false;
   unsigned char buffer[CWS_NETMSGSIZE];
   int n;
-  while((n=ReceiveMessage(buffer,true))==-2)
-    PRINTF(L_CC_NEWCAMD,"msg ID sync error. Retrying...");
+  {
+    cMutexLock lock(this);
+    if(!SendMessage(data,SCT_LEN(data),true,&cd)) return false;
+    while((n=ReceiveMessage(buffer,true))==-2)
+      PRINTF(L_CC_NEWCAMD,"msg ID sync error. Retrying...");
+  }
   switch(n) {
     case 19: // ecm was decoded
       // check for zero cw, as newcs doesn't send both cw's every time


I don't think the locking is fine-grained enough in sasc-ng, so I would recommend running the application for each virtual adapter you have e.g.

/usr/local/bin/sasc-ng -p 5456 -j 0:2 --cam-budget --cam-dir=/etc/camfiles.1 -b 16M
/usr/local/bin/sasc-ng -p 5456 -j 1:3 --cam-budget --cam-dir=/etc/camfiles.1 -b 16M

So if sasc-ng gets 'stuck', then it won't necessarily break all signals.

It's also better not to rely on sasc-ng to do the network talk because minor network glitches will kill your stream. So consider making it talk to a locally running OSCam server instead. And have the OSCam talk to the outside network (OSCam will be acting like a proxy).
nickfudge
 
Posts: 4
Joined: Tue Sep 13, 2011 5:08 pm

Re: TBS6984 and vdr-sasc-ng

Postby nickfudge » Mon Oct 03, 2011 3:20 pm

fibres Wrote:The only trouble is the picture keeps freezing.

Everything works ok. Free channels are fine but when on paytv the picture freezes for a few secs every few mins. Sometimes it clears and other times it freezes for too long and causes myth to drop out.


This happens because the encryption keys change every few seconds and for some reason you've missed one. The time taken to recover the encrypted stream will be about 10 seconds, which will exceed MythTV's buffers and timeout.

Edit: I strongly recommend that you change the startup options for mythtv-backend to reduce logging -- add option "-v none" to the command line. The reason is that you will periodically get occasions when a key is missed. mythtv-backend will log a DTVRec error for each corrupt frame, which uses up valuable time writing log lines to hard disk. Reducing logging will significantly increase the chances of recovery before failing back to the main menu.

vdr-sasc-ng can only talk to one cardserver at a time, so my recommendation is to run OSCam locally and make vdr-sasc-ng talk to that instead. OSCam can talk to multiple cardservers in parallel and will use the keys of the cardserver that responds the fastest. To get a stable decrypted stream, you may need to use more than one provider so that you are not fully reliant on a stable network connection between your house and their server (the network hops inbetween are out of both yours and their control).

So to summarise:

- vdr-sasc-ng talks to a locally running OSCam
- OSCam proxies your key requests to your cardservers in parallel and will return the results to vdr-sasc-ng which will then be able to decrypt the stream.
Last edited by nickfudge on Sat Oct 08, 2011 1:38 am, edited 1 time in total.
nickfudge
 
Posts: 4
Joined: Tue Sep 13, 2011 5:08 pm

Re: TBS6984 and vdr-sasc-ng

Postby djkiller » Fri Oct 07, 2011 4:55 pm

Thank you :) It works very well.
djkiller
 
Posts: 6
Joined: Mon Aug 29, 2011 4:23 am

Re: TBS6984 and vdr-sasc-ng

Postby torrieborrie » Mon Dec 12, 2011 7:48 pm

I had big problems with getting the new driver (V111118) work with sasc-ng.
No problems compiling and no problems with FTA on the real adapters.
Sasc-ng compiled with no errors and the system seems to be running well.
However as soon as you want to use the virtual adapters (mythfrontend or mythtv-setup) Mythtv freezes.
Finally a managed to get it working with the "old" driver (V110717) with the patches mentioned in this threath.
I think the new driver still need some work.
torrieborrie
 
Posts: 3
Joined: Mon Dec 12, 2011 7:37 pm

Re: TBS6984 and vdr-sasc-ng

Postby nickfudge » Thu Dec 15, 2011 12:22 am

I had problems with the V111118 driver too, but I think it's because I forgot to apply the linux-2.6.38-mutex.patch. I just reverted to the older driver until I have time to investigate further.

* Update: running with V111118 and kernel 3.0.7. All is running just fine for me.
nickfudge
 
Posts: 4
Joined: Tue Sep 13, 2011 5:08 pm

Re: TBS6984 and vdr-sasc-ng

Postby Rasmus » Thu Dec 22, 2011 1:59 am

I am Having problems with this setup.

Have tried different drivers and sasc-ng sources but with no luck.

If I just use latest driver and latest sasc-ng I get a console error in mythtv backend setup (v. 0.24.1) something like: Cant open dvb frontend unknown card or device

and it seems I get the same result with the patched sasc-ng. I then tried to patch the drivers but I am unable to do so since im running kernel 2.6.35 in ubuntu 10.10

been scratching my head for the last 3 days :S

Have somebody managed to get this working on a 2.6.35 kernel.?
if so could you please give me a hint on how to succeed.

merry christmas
Rasmus
 
Posts: 5
Joined: Sat Dec 17, 2011 7:03 pm

Previous

Return to Linux

Who is online

Users browsing this forum: No registered users and 2 guests