Ziggo hogere CW tijden

[Hotzenwalder]

Die zenders heb ik ook niet en ik gebruik ook geen CCcam.

[Codx]

hou maar op, het ligt niet aan de config. Elke server heeft dezelfde klachten op dit moment en het is op alle zenders. Met 1 box zul je het niet zien.

[theparasol]

hou maar op, het ligt niet aan de config. Elke server heeft dezelfde klachten op dit moment en het is op alle zenders. Met 1 box zul je het niet zien.

Wel weer goed bedacht van meneer Ziggo dacht ik zo. Maar wat is nu het probleem? een ziggo controlword is echt mega lang geldig, die kun je haast nog met de hand intikken als het moet.

[DoeEensGek]

hou maar op, het ligt niet aan de config. Elke server heeft dezelfde klachten op dit moment en het is op alle zenders. Met 1 box zul je het niet zien.

 

Hou maar op? Ik lees alleen hier in dit topic van het probleem bij 3 mensen? Kan je bij cccam zien welke atr de smartcard heeft?

[DoeEensGek]

Wel weer goed bedacht van meneer Ziggo dacht ik zo. Maar wat is nu het probleem? een ziggo controlword is echt mega lang geldig, die kun je haast nog met de hand intikken als het moet.

 

om de 21 seconde is een nieuwe nodig, maar dat houdt niet in dat je 21 seconde heb om die code in te tikken .

[Bambix]

Hallo allen,

 

Las dit bericht en ging googlen.

In hoeverre is op een server met CCcam 2.3.0 de ECM time naar benenden te halen als de volgende regel in de cccam.cfg wordt opgenomen:

 

LOADBALANCE : /dev/ttyUSB0 /dev/ttyUSB1 (of meer als er meer smargo+ readers gebruikt worden).

[Codx]

Nouja dat wil niet zeggen dat je 21 sec hoge tijden mag hebben. Denk aan skyuk die freezed boven de 600 ms en tussen de ecm's zit veel langer. Bovendien het zappen duurt een eeuwigheid zo als het niet uit cache komt.

[DoeEensGek]

Hallo allen,

 

Las dit bericht en ging googlen.

In hoeverre is op een server met CCcam 2.3.0 de ECM time naar benenden te halen als de volgende regel in de cccam.cfg wordt opgenomen:

 

LOADBALANCE : /dev/ttyUSB0 /dev/ttyUSB1 (of meer als er meer smargo+ readers gebruikt worden).

Zoals cccam.cfg hem zelf omschrijft:

# load balancing between identical cards, list device names of card readers containing identical cards,
# optionally followed by a list of service id's which are to be excluded from loadbalancing
#
# LOADBALANCE : <device1> <device2> .. <devicen> { <exceptsid1>, <exceptsid2> .. , <exceptsidn> }
#
# multiple loadbalance groups can be configured, by adding multiple lines
# warning: restart is required, when loadbalance group config changes
#
#example 1: load balance requests for three identical cards
#
# LOADBALANCE : /dev/ttyS0 /dev/ttyS1 /dev/ttyS2
#
#example 2: load balance requests for two almost identical cards, sid 0df3 and 0de1 are only available
#on one of the cards, so requests for these sids shouldn't be loadbalanced
#
# LOADBALANCE : /dev/ttyS5 /dev/ttyS6 { 0df3,0de1 }

 

Handig als je 2 (nagenoeg) zelfde kaarten hebt.

Daarbij wil ik even toevoegen dat je tryallchids alleen moet gebruiken als je niet zonder kunt.

Chids zijn soort van pakketten, sommige zenders bevatten meer chids, bijvoorbeeld de verrassings zenders en eredivisie live. bij tryallchids zal hij alle 2/3 chids proberen (ook als je deze niet hebt) van deze zenders, dat betekent 2/3 ecms. Dit kan dus tijd kosten. Als je het niet invult, zal hij alleen de ecm met chid sturen, waarvan hij weet dat jouw kaart hem heeft.

Zap je nu snel voorbij nova zenders... vliegen de ecm's de kaart om de oren. Daar zitten 5 tot 10 chids op... aangezien de providers en caid overeen komen zal hij die naar de kaarten sturen. Zou je tryallchids niet ingevuld hebben zal hij die niet vragen, tenzij chid overeenkomt.

 

Hopelijk kunnen jullie er wat mee...

 

Ow en cccam kan ook een log maken, begreep ik. Kan je misschien ook dingen uitlezen?

6 december 2012 aangepast door DoeEensGek

[vinay88]

Na het invoeren van LOADBALANCE : /dev/ttyUSB0 /dev/ttyUSB1

 

zijn me ecms in eens een stuk lager geworden.

 

Nu gemiddeld tussen de 1 en 2.3 secondes.

 

Dus het helpt idd wel een stuk...

6 december 2012 aangepast door vinay88

[gjstroom]

Ik heb even wat testen gedaan met de interne reader van m'n dm800se, ik woon ook in Ziggo west gebied (NetworkID Value="5555" "Ziggo Digitale Televisie 04")

Getest met HB0 HD,

 

CCcam 2.09

Segmentation fault

Werkt dus helemaal niet op OpenPLi3.

 

CCcam 2.12-2.14

13:29:59.996 CCcam: chid 03E7

13:29:59.996 CCcam: local ecm -> card /dev/sci0 0x604(0x000) sid 0x0ea

13:30:00.277 CCcam: local ecm <- card /dev/sci0 ok

13:30:00.279 CCcam: cam[0] ecm even ok caid:0x604 id:0x0 pid:0xfa1 Unknown (took -nan seconds)

Geeft geen timings weer (took -nan seconds).

Maar met wat rekenwerk kom ik op 0.283 seconds .

 

CCcam 2.21

12:56:43.203 CCcam: chid 03E7

12:56:43.203 CCcam: local ecm -> card /dev/sci0 0x604(0x000) sid 0x0ea

12:56:43.484 CCcam: local ecm <- card /dev/sci0 ok

12:56:43.485 CCcam: cam[0] ecm odd ok caid:0x604 id:0x0 pid:0xfa1 Unknown (took 0.282 seconds)

 

 

CCcam 2.30

12:54:16.202 CCcam: chid 03E7

12:54:16.202 CCcam: local ecm -> card /dev/sci0 0x604(0x000) sid 0x0ea

12:54:16.481 CCcam: local ecm <- card /dev/sci0 ok

12:54:16.483 CCcam: cam[0] ecm even ok caid:0x604 id:0x0 pid:0xfa1 Unknown (took 0.280 seconds)

 

OSCam #7949

2012/12/08 13:10:51 7700BC80 c dvbapi: [ADD PID 0] CAID: 0604 ECM_PID: 0FA1 PROVID: 000000

2012/12/08 13:10:51 7700BC80 c dvbapi: [ADD PID 1] CAID: 0602 ECM_PID: 1389 PROVID: 000000

2012/12/08 13:10:51 7700BC80 c dvbapi: Found 2 ECMpids and 3 STREAMpids in PMT

2012/12/08 13:10:51 7700BC80 c dvbapi: New program number: 00EA (HBO HD) [pmt_list_management 3]

2012/12/08 13:10:52 7700BC80 c dvbapi: Start descrambling PID #0 (CAID: 0604) 1

2012/12/08 13:11:04 7700BC80 c dvbapiau (0604&000000/03E7/00EA/44:7DFFB3C53771696E49C757FDB94CBF5A): found (204 ms) by upper

 

Op mijn Ubuntu server met OSCam heb ik timings van rond de 160ms.

 

Wat dat betreft is er niets aan de timings verandert...

8 december 2012 aangepast door gjstroom

[Codx]

Nogmaals met 1 box ga je dit niet zien. Goed leren lezen mensen.

[gjstroom]

Nogmaals met 1 box ga je dit niet zien. Goed leren lezen mensen.

Daarom staat er ook onderaan: "Wat dat betreft is er niets aan de timings verandert..."

Volgens mij onstaan er verschillen door de verschillende Ziggo sub regio's, In Ziggo west gebied zijn dat er 5.

8 december 2012 aangepast door gjstroom

[Bambix]

Ik heb even wat testen gedaan met de interne reader van m'n dm800se, ik woon ook in Ziggo west gebied (NetworkID Value="5555" "Ziggo Digitale Televisie 04")

Getest met HB0 HD,

 

CCcam 2.09

Segmentation fault

Werkt dus helemaal niet op OpenPLi3.

 

CCcam 2.12-2.14

13:29:59.996 CCcam: chid 03E7

13:29:59.996 CCcam: local ecm -> card /dev/sci0 0x604(0x000) sid 0x0ea

13:30:00.277 CCcam: local ecm <- card /dev/sci0 ok

13:30:00.279 CCcam: cam[0] ecm even ok caid:0x604 id:0x0 pid:0xfa1 Unknown (took -nan seconds)

Geeft geen timings weer (took -nan seconds).

Maar met wat rekenwerk kom ik op 0.283 seconds .

 

CCcam 2.21

12:56:43.203 CCcam: chid 03E7

12:56:43.203 CCcam: local ecm -> card /dev/sci0 0x604(0x000) sid 0x0ea

12:56:43.484 CCcam: local ecm <- card /dev/sci0 ok

12:56:43.485 CCcam: cam[0] ecm odd ok caid:0x604 id:0x0 pid:0xfa1 Unknown (took 0.282 seconds)

 

 

CCcam 2.30

12:54:16.202 CCcam: chid 03E7

12:54:16.202 CCcam: local ecm -> card /dev/sci0 0x604(0x000) sid 0x0ea

12:54:16.481 CCcam: local ecm <- card /dev/sci0 ok

12:54:16.483 CCcam: cam[0] ecm even ok caid:0x604 id:0x0 pid:0xfa1 Unknown (took 0.280 seconds)

 

OSCam #7949

2012/12/08 13:10:51 7700BC80 c dvbapi: [ADD PID 0] CAID: 0604 ECM_PID: 0FA1 PROVID: 000000

2012/12/08 13:10:51 7700BC80 c dvbapi: [ADD PID 1] CAID: 0602 ECM_PID: 1389 PROVID: 000000

2012/12/08 13:10:51 7700BC80 c dvbapi: Found 2 ECMpids and 3 STREAMpids in PMT

2012/12/08 13:10:51 7700BC80 c dvbapi: New program number: 00EA (HBO HD) [pmt_list_management 3]

2012/12/08 13:10:52 7700BC80 c dvbapi: Start descrambling PID #0 (CAID: 0604) 1

2012/12/08 13:11:04 7700BC80 c dvbapiau (0604&000000/03E7/00EA/44:7DFFB3C53771696E49C757FDB94CBF5A): found (204 ms) by upper

 

Op mijn Ubuntu server met OSCam heb ik timings van rond de 160ms.

 

Wat dat betreft is er niets aan de timings verandert...

 

Kan ik uit jou testen concluderen, dat je het beste met CCcam 2.2.1. en hoger kan werken??

[gjstroom]

Kan ik uit jou testen concluderen, dat je het beste met CCcam 2.2.1. en hoger kan werken??

Het maakt allemaal niet echt uit, het ligt er aan wat je er mee doet en of er 'verschillende' clients aan de server zijn verbonden.

Als je puur naar de snelheid kijkt, zal ik zeggen OSCam.

[FCU]

kan je het ook verminder met een nieuwe cccam