4250 replies to this topic

[theparasol]

Wel heb ik vastegsteld dat hij met camd35 en cs en .. tot 4 effectieve sids gaat met 3/11. Zet ik 4/11 gaat hij tot 5 enkel met camd en cs erbij waaruit dan ook anti share mode

Volgensmij onstaat dit effect doordat oscam zijn tijdsinterval (11) niet samenvalt met de ecm rate in de dvbstreams.

Tuner 1 vraagt ecm op tijd 1, oscam interval tijd is 8
Tuner 2 vraagt ecm op tijd 2, oscam interval tijd is 9
Tuner 3 vraagt ecm op tijd 3, oscam interval tijd is 10
Tuner 4 vraagt ecm op tijd 4, oscam interval tijd is 11
Tuner 5 vraagt ecm op tijd 5, oscam interval tijd is 1 -> rate limiter grijpt niet in

Tuner 1 vraagt ecm op tijd 11, oscam interval tijd is 18-11= 7
Tuner 2 vraagt ecm op tijd 12, oscam interval tijd is 19-11= 8
Tuner 3 vraagt ecm op tijd 13, oscam interval tijd is 20-11= 9
Tuner 4 vraagt ecm op tijd 14, oscam interval tijd is 21-11=10
Tuner 5 vraagt ecm op tijd 15, oscam interval tijd is 11-11=0 -> rate limiter grijpt niet in

Los dat de dvbstream een eigen 10 seconden tik heeft voor een nieuwe controlword heeft oscam dat ook om te meten of het aantal controlwords overschreden is.
Aan beiden heeft de kaart geen boodschap: Hoe die exact tikt en telt moeten we proberen te achterhalen. Daarna correcte ratelimits bedenken met inachtneming van bovenstaande effect.

[Erik Slagter]

Wat je bedoeld met "gaar" weet ik niet (bij ons in belgië) wilt dit zeggen goed gekookt. -

LOL, datzelfde hebben wij met sommige Vlaamse uitdrukkingen. Gaar betekent hier net zo goed "voldoende gekookt", maar ook wel foobar, oftewel, compleet stuk.

Maar standaard heeft deze parameter 5 seconden. Hij heeft zowieso ook enkele neven effecten. Maar deze een beetje verhogen heeft stabielere resultaten algemeen naar bv 20 is ideaal bij mij.
Breng ik deze onder de 5 seconden dan treed er soms een segfault op en memory overflow.

Maar ik snap zowiezo niet waarom je die lager dan (oneindig) zou willen zetten, zeker op een lan share. Wat hij doet is echt heel bot, zodra hij even een paar seconden niet meteen antwoord krijgt, gaat hij de verbinding dichtgooien en opnieuw opzetten. Vaak zit je dan nog te wachten op een initiele ecm, nergens voor nodig. Misschien dat het voor niet-lan-sharing nut heeft, geen idee... Dus bij mij staat hij nu op 9999999 en dat werkt prima.

[theparasol]

Wat hij doet is echt heel bot, zodra hij even een paar seconden niet meteen antwoord krijgt, gaat hij de verbinding dichtgooien en opnieuw opzetten. Vaak zit je dan nog te wachten op een initiele ecm, nergens voor nodig. Misschien dat het voor niet-lan-sharing nut heeft, geen idee... Dus bij mij staat hij nu op 9999999 en dat werkt prima.

Als een CCcam share reader niet antwoord op een ecm verzoek kan dat betekenen dat hij nooit meer gaat antwoorden. Heb meen ik ergens gelezen dat CCcam als hij de connectie dropt de client niet inlicht. Gevolg: je blijft ecm's vragen aan een efficient dode readerlink. Als je bv 30 seconden geen antwoord gehad hebt na je ecm verzoek bouwt oscam de connectie zelf opnieuw op en voorkomt zo een permanente dooie connectie met een CCcam peer.

[Erik Slagter]

M.a.w. je kunt 4/11 nimmer gebruiken bij camd35,cs357x of cs378x protocol ?

Bij mij is dit het geval Ja . Maar met 3/11 geen probleem.

Ik had vanmiddag ook 4/11 en een camd35, en jawel hoor, mijn kaart is al weer zwart. Hele tijd gaat het goed met 2 x 2 tuners PiP, we zetten de ene box uit voor het eten, maar die start wel een opname, de andere blijft aan staan (dus in totaal drie tuners) en jawel hoor, raak. Joepie. Da's dus vandaag weer even "klaar" met experimenteren :-(

[Erik Slagter]

Ik had het over de readerrestartseconds = van oscam conf niet de reconnecttimeout = van uit oscam.server effen verward. deze laatste laat ik op de default die 30 is.

Wat die doet is mij ook net zo goed een raadsel. Aan de ene kant suggereert de documentatie dat de tijd is waarna een "afgeschreven" reader weer gebruikt gaat worden. Aan de andere kant blijkt het bij mij geen bal uit te maken wat ik daar invoer. Een afgeschreven reader blijft vaak afgeschreven.

[Erik Slagter]

Wat hij doet is echt heel bot, zodra hij even een paar seconden niet meteen antwoord krijgt, gaat hij de verbinding dichtgooien en opnieuw opzetten. Vaak zit je dan nog te wachten op een initiele ecm, nergens voor nodig. Misschien dat het voor niet-lan-sharing nut heeft, geen idee... Dus bij mij staat hij nu op 9999999 en dat werkt prima.

Als een CCcam share reader niet antwoord op een ecm verzoek kan dat betekenen dat hij nooit meer gaat antwoorden. Heb meen ik ergens gelezen dat CCcam als hij de connectie dropt de client niet inlicht. Gevolg: je blijft ecm's vragen aan een efficient dode readerlink. Als je bv 30 seconden geen antwoord gehad hebt na je ecm verzoek bouwt oscam de connectie zelf opnieuw op en voorkomt zo een permanente dooie connectie met een CCcam peer.

Brak protocol dus Zoiets hoor je "in-band" te signaleren en niet de tcp stack voor te misbruiken. Ik gebruik camd35 en dat gaat dus inderdaad ook goed.

Edited by Erik Slagter, 10 February 2012 - 19:17.

[master1601]

Vandaag ook nog even aan het testen geweest, 4/11 > na verloop van tijd op zwart, op 3/10 op dit moment nog geen probleem. (LB over 3 kaarten, LBmode=2)

[fjskmdl]

Ik wil van ontvanger 1 de tvvkaart doorsharen naar een tweede receiver. Ik wil echter enkel bepaalde sids doorsharen. Ik heb dus een services entry genaamd "sids" gemaakt, en in de reader entry services = sids gezt voor mijn tvv kaart.
Het probleem is echter dat ik vanop de tweede box toch nog alle tvv kanalen kan openen. Ik gebruik de default reshare_mode (0)
Moet ik hiervoor de reshare mode wijzigen naar 3?
Ik heb echter nog een tweede kaart in ontvanger 1 zitten, en ik wil dat deze volledig doorgeshared wordt, zonder dat ik hiervoor moet aanvinken wat doorgesharen moet worden voor deze kaart. (wat je bij reshare mode 3 net wel moet doen)

Kortom: ik wil een sid beperking van ontvanger1 smartcard 1 naar ontvanger 2 toe
Maar ontvanger 1 smartcard2 moet volledig doorgeshared worden naar ontvanger 2 zonder dat ik hiervoor service entries moet aanvinken.... is dit eigenlijk mogelijk?

[christophecvr]

oscam.services

[sidspas k1user1]
caid=0100
provid=00006A
srvid= xxxx,xxx1,xxx2,xxx3, enz .....

oscam.user

[user]

services= sidspas k1user1

[rytec]

Is er ergens een recente oscam.services te vinden waar alle sids van TV vlaanderen in staan. Die wil ik weer gebruiken voor een !block op een reader die alleen CD NL moet doen, maar niet voor de BE zenders.
Wat op 0100:00006A zit mag gebruikt worden, maar 0100:00006C mag alleen worden aan gesproken voor zaken die niet in 0100:00006A zitten. Een complete blokkade op 0100:00006C heeft tot gevolg dat ook TVV niet meer doorkomt... is ook weer niet de bedoeling.

Ik kan natuurlijk ook alle zenders in het pakket van TVV aflopen en kijken welke er niet in het CD NL pakket zitten, maar als iemand de moeite al genomen heeft... graag

hier zo'n beetje een dergelijke lijst
[tvv-vs-cds]
caid = 0100
provid = 00006C,00006A
srvid = 0041,0046,07DA,07DF,07E4,07E9,07EE,07EF,07FA,07FD,0FAB,0FAC,0FAD,0FAE,0FAF,139C,139F,13A5,13A6,1419,13B0,1421,141F,13B9,1415,1789,178E,1793,1798,179D,17A2,17AC,17B1,17C0,17CE,1B62,1B67,1B71,1B7B,1F47,219F,232A,2525,31E7,31E8,31F4,3335,333B,333C,5156,51CC,51D1,51D6,5221,5226,5230,6FB8,6FEF,6FF0,6FF1,6FF3,6FFF,7007

[Hotzenwalder]

Bedankt.... heb het ondertussen al anders opgelost en dat werkt beter (reshare_mode = 3, oscam.services met alleen caid,provid, geen sids. Geen services toegewezen aan users of readers).

[mysat]

Mijn SECA2 draait als een tierellier in een DM800 (net zoals TVV en TNTSAT). Indien ik de kaarten centraal in een server steek, doet ze het allemaal prima, behalve de SECA2 C+ kaart. Ik zie wel de entitlements in Oscam (server kant natuurlijk), maar krijg constant het antwoord "not found" terug. Gek dat ie het dus wel doet i.c.m oscam.dvdapi maar aan de serverkant in een smargo het nog niet doet....

Indien dit een bug met low prio zou zijn, zou ik wel overwegen om de kaart om te ruilen omdat ik de indruk heb dat een SECA3 het wel in een server doet

Dat maakt het wat duidelijker. Kan het zijn dat je clients wellicht geen seca2 ecm's aanvragen bij de seca2 reader maar seca3 ecm's?
Dan zou je met een whitelist voor seca2 moeten gaan werken maar dan komt je seca3 weer in de knoei.

Altijd een beetje lastig is meerdere onderwerwepen in 1 draadje. Ik ben nog even bezig met mijn SECA2 kaartje en heb nog geen functionele oplossing anders dan het omruilen voor een SECA3 (en dat is een zwakte bod want ik weet niet eens of de SET TOP pakket mogelijk is sinds dit niet meer in het assortiment zit). Ik kan me overigens niet voorstellen dat ik de enige ben met een SECA2 in een smargo via een server maar aan de andere kant loopt iemand altijd als eerste tegen een probleem aan.

Ik zie twee opties:
- Probleem loggen bij oscam developers ( maar wat is de prioriteit voor seca2 kaartjes)
- Toch een methode te vinden om mij abo om te zetten naar een SECA3 (maar hoe dan ?)

Of zijn er nog andere wegen die naar Rome leiden. (Sharen via de werkende oplossing in een DM800 is niet de uitdaging in deze)

[christophecvr]

Dit echt oplossen gaat oscam niet doen, Daar er mogelijkheden genoeg zijn via de dvpapi of oscam.whitelist.

Wat echter wel moet werken is bij je server
in file oscam.server bij de reader waar de seca twee kaart zit enkel de kanalen seca 2 toelaten. Hoe ?

[reader]
bla
bla
bla
services = Seca2sid

in de oscam.services zet je een entry waarbij enkel de sids in staan die zowel seca2 als 3 doen.

[Seca2sid]

caid=0100
provid=00006A
srvid=0FAB,0FAC,0FAD,07D4,07D5,0FA2,07D6,07EF,0FA3,1B7B,07F4,31E7,31E8

Naar je kaart gaan nu nog steeds alle seca3 voor die pids voor die sids die leveren dan not found op. Maar het is reeds beperkter.

Laat je oscam.whitelist well blanco of laat enkel de lijn
w: # staan

Bij je oscam klant, in U geval de dm800 zet je.

In oscam.conf bij dvbapi
[dvbapi]
request_mode = 0 #staat ofwel mag dit lijntje gewoon weg. met 1 WERKT HET NIET !!

Bij oscam.dvbapi zet je

P: 0100:00006A:0FAB:0643 # NED1 SD
P: 0100:00006A:0FAC:0644 # NED2 SD
P: 0100:00006A:0FAD:0645 # NED3 SD
P: 0100:00006A:07D4:0643 # RTL4 SD
P: 0100:00006A:07D5:0644 # RTL5 SD
P: 0100:00006A:0FA2:0641 # SBS6 SD
P: 0100:00006A:07D6:0649 # RTL7 SD
P: 0100:00006A:07EF:0647 # Veronica SD CDS
P: 0100:00006A:0FA3:0642 # NET5 SD
P: 0100:00006A:1B7B:0646 # NED1 HD
P: 0100:00006A:07F4:064D # Comedy Central / Kindernet
P: 0100:00006A:31E7:03E3 # Een SD
P: 0100:00006A:31E8:03E4 # Ketnet/Canvas SD
P: 0100:00006A

Edited by christophecvr, 12 February 2012 - 10:48.

[christophecvr]

Om het bovenstaande af te maken. Kan je indien je wilt alle seca3 pids blokeren naar je server enkel en enkel voor de specifieke canalen die je kaart seca2 kan. (het is dan wel voo de hele server, maar op zich moet dit geen probleem zijn en je dm zal perfect werken met je kaart.

oscam.whitelist deze moet bij je server staan niet in dm.

i: 0100:00006A:0FAB:070B # NED1 SD 070B
i: 0100:00006A:0FAC:070C # NED2 SD 070C
i: 0100:00006A:0FAD:070D # NED3 SD 070D
i: 0100:00006A:07D4:070B # RTL4 SD 070B
i: 0100:00006A:07D5:070C # RTL5 SD 070C
i: 0100:00006a:0FA2:0709 # SBS6 SD 0709
i: 0100:00006A:07D6:0711 # RTL7 SD 0711
i: 0100:00006A:07EF:070F # Veronica SD CDS 070F
i: 0100:00006A:0FA3:070A # NET5 SD 070A
i: 0100:00006A:1B7B:070E # NED1 HD 070E
i: 0100:00006A:07F4:0715 # Comedy Central / Kindernet 0715
i: 0100:00006A:31E7:070D # Een SD 070D
i: 0100:00006A:31E8:070E # Ketnet/Canvas SD 070E
w:

[rwijnberg]

Het is de laatste tijd goed mis met oscam. Vanaf build #6359 ben ik geen build meer tegengekomen die het langer dan een uur volhield. Ik heb het dan over de pc-i386 versie. Zit er een memory-leak in de laatste versies?

[christophecvr]

Het is de laatste tijd goed mis met oscam. Vanaf build #6359 ben ik geen build meer tegengekomen die het langer dan een uur volhield. Ik heb het dan over de pc-i386 versie. Zit er een memory-leak in de laatste versies?

Nu toch al lang geen echte problemen met pc versies. Zelf heb ik nu 6378, Die reeds meer dan 12 uur draait zonder problemen. Is wel pc 64 (Ik compileer zelf)

Edited by christophecvr, 13 February 2012 - 12:58.

[frissie]

Het is de laatste tijd goed mis met oscam. Vanaf build #6359 ben ik geen build meer tegengekomen die het langer dan een uur volhield. Ik heb het dan over de pc-i386 versie. Zit er een memory-leak in de laatste versies?

Welke distributie draai je ?
Ik zelf draai debian 6.0.3 met de nieuwste udates.
Na de laatste libc updates draait het beter.
Ik draai op aanraden van christophecvr nu versie 6288.

Van christophecvr de tip gekregen om oscam op te starten met de optie -r 2
Krijg nog wel segfaults, maar Oscam stopt niet meer.
Dus ./oscam.x86 -r 2
Met de -r 2 optie wordt er bij een segfault, oscam niet onderuit geschoffeld.

Edited by frissie, 13 February 2012 - 14:39.

[Erik Slagter]

Misschien heel oude (verouderde...) libraries?

[christophecvr]

De laatste versie oscam is 6381 . Deze is ok op ubuntu 11.04 (updated) .
Ps de vorige die ik had 6378 heeft meer dan 12 uur zonder enige harstart of auto start tengevolge van segfault gelopen.

Segfaults kunnen ook optreden door misconfiguratie. Check je configs die je hebt met de laatste doc info

[Erik Slagter]

Segfaults kunnen ook optreden door misconfiguratie. Check je configs die je hebt met de laatste doc info

Segfaults zijn ALTIJD het gevolg van:

- hardware probleem
- probleem met een library
- maar zo goed als altijd: programmeerfout door: stray pointers, buffer overrun enz. enz.

Een foute configuratie mag nooit een segfault opleveren, slecht programmeerwerk.