4250 replies to this topic

[Erik Slagter]

tcp_conn_close(): fd=29, cl->typ == 'p' is_udp 0 label == 'local' reason close

Die meldingen heb ik heel veel gehad. Het betekent in ieder geval niet dat er iets met je netwerk is Deze melding komt voort uit een actieve connection close, in mijn geval kwam het omdat ik de reconnect-timeout heel laag had staan, waardoor een antwoord altijd "te laat" kwam en oscam concludeerde dat de verbinding "dood" was. Ik heb het nu bijna nooit meer.

[Erik Slagter]

Waar ik benieuwd naar ben is of er al 'ruimere' marges gebruikt zijn m.b.t. de ratelimiter. Dit omdat er voorheen dus 2 ECM's werden verstuurd naar de kaart en sinds de patch/verbetering van The Parasol dus niet meer.
Ik heb helaas de middelen niet om de limieten op te zoeken maar hoop dat anderen hier meer duidelijkheid in kunnen scheppen? En uiteraard om het te weten zodat daar ook weer een variabele de wereld uit is...

Ik begrijp niet precies wat je bedoelt, maar ik kan wel melden dat de mysterieuze penalty-mode-optredens met een rate limit van 4/10 sinds een week ofzo wel opgelost zijn, inderdaad. Met 4/11 krijg ik toch weer penalty-mode, overigens.

Ik heb alleen nu het gevoel dat de rate limiter op mijn kaart helemáál niks doet, ik nu weer een kaart in penalty mode zonder enige melding van oscam over ecm rates.

[Erik Slagter]

Al geprobeerd met het weghalen van keepalive of ccckeepalive ???

Wat is er eigenlijk mis met keepalive?

[beebee]

De ECM's voor NED1,2,3 SD komen niet in de DM7000 aan: de CCcam 2.1.4 kaart ECM info hoogt niet op.......
Om de e.o.a. reden worden de ECM's alleen voor deze kanalen geblokkeerd door OSCAM
Geblokkeerd voor de proxy naar de DM7000,
niet als ik de kaart in de reader van de DM8000 stop.
Wat is hier nu het verschil.....

Nu met load balancer aan:

STATUS CONFIGURATION READERS USERS SERVICES FILES FAILBAN CACHEEX SCRIPT SHUTDOWN
show all hide 'not found' reset statistics store valid ecm len in whitelist

Loadbalance statistics for reader dm7000

Channel Channelname ECM Length Result Avg-Time Last-Time Count Last checked/ found
0100:00006A:17C0:0000 Ned2 HD 0064 found 325ms 324ms 2 08.03.12 11:20:45 Delete Entry
0100:00006A:1B7B:0000 Ned1 HD 0064 found 322ms 330ms 53 08.03.12 11:33:19 Delete Entry
0100:00006A:5230:0000 Ned3 HD 0064 found 324ms 324ms 2 08.03.12 11:21:03 Delete Entry
Timeout delete all timeout
0100:00006A:0FAB:0000 NED1 SD 0064 timeout 5000ms 5000ms 0 08.03.12 11:29:46 Delete Entry
0100:00006A:0FAC:0000 NED2 SD 0064 timeout 3486ms 5000ms 1 08.03.12 11:32:51 Delete Entry
0100:00006A:0FAD:0000 NED3 SD 0064 timeout 5000ms 5000ms 0 08.03.12 11:33:13 Delete Entry
Total ECM count: 58

Edited by beebee, 8 March 2012 - 11:47.

[beebee]

tcp_conn_close(): fd=29, cl->typ == 'p' is_udp 0 label == 'local' reason close

Die meldingen heb ik heel veel gehad. Het betekent in ieder geval niet dat er iets met je netwerk is Deze melding komt voort uit een actieve connection close, in mijn geval kwam het omdat ik de reconnect-timeout heel laag had staan, waardoor een antwoord altijd "te laat" kwam en oscam concludeerde dat de verbinding "dood" was. Ik heb het nu bijna nooit meer.

Erik, wat was te laag, en hoe staat het nu?

[Erik Slagter]

Het gaat om de instelling "reconnecttimeout" in de oscam.server file, bij de betreffende server. Die had ik "-1" staan, als "oneindig", maar oscam maakt daar intern "0" van en dat betekent dat elke request per definitie al timeout is. Ik heb er nu "10" staan, dat werkt wel goed.

[cemeli]

tcp_conn_close(): fd=29, cl->typ == 'p' is_udp 0 label == 'local' reason close

Die meldingen heb ik heel veel gehad. Het betekent in ieder geval niet dat er iets met je netwerk is Deze melding komt voort uit een actieve connection close, in mijn geval kwam het omdat ik de reconnect-timeout heel laag had staan, waardoor een antwoord altijd "te laat" kwam en oscam concludeerde dat de verbinding "dood" was. Ik heb het nu bijna nooit meer.

dank je voor het antwoord ,ik had de reconnecttimeout op 30 staan wel raar

[alias haha]

bij mij valt oscam uit als ik een netwerk kabel uit een ontvanger trek als de box nog draait, krijg dan melding segfault at 274........, verder draait hij super, heb dit ook gehad met een klapperend draadloos netwerk, als dus de verbinding niet netjes word afgesloten dan crashed oscam nog, of is er ondertussen al een fix voor geweest?

[teletub]

Met de volgende regels na 40 seconden vastlopers op cds met S3 kaart , ziggo bleef het wel doen in oscam svn 6477 1.20 unstable

I: 0100 #ignore all old seca providers
I: 0500 #ignore viaccess
I: 0622 #ignore old irdeto
M: 1817:00006A 0100:00006A #map NL nagracaid 1817:00006A to seca 0100:00006A
M: 1818:00006C 0100:00006C #map BE nagracaid 1818:00006C to seca 0100:00006C
P: 1817:00006A #Prio NL 1817
P: 1818:00006C #Prio BE 1818


na wat gepuzzel in dvbapi kreeg ik ze allebei weer aan de praat , door een vereenvoudigde dvbapi erin te zetten

oscam.dvbapi in combinatie met cds en ziggo en

P: 0100:00006A
I: 0622 # ignore old irdeto

de regel
I:0 blocked de ziggo kaart ,

de regel
I:0 blocked de ziggo kaart ,

zet dan

P: 0604
P: 0602

in oscam.dvbapi

Groet

[theparasol]

Wat mij opgevallen is, dat tijdens het kijken naar een zender en je bijvoorbeeld het netwerk loskoppelt van de box dan gaat het beeld stilstaan, wat normaal is ja.
Maar als je het netwerk weer aanzet dan speelt ie niet verder op die zender, wel kun je zappen naar de overige zenders.
Ik gebruik de loadbalancer en oscam zet dus na het onderbreken van het netwerk die pids op de blacklist.
Als ik dan even via de webif de stats leegmaak dan komt ier wel weer doorheen.

Ook zonder load balancer heb je dit fenomeen. Het probleem is dat als op enig moment geen server gevonden kan worden voor een bepaalde zender, oscam het na drie retry's opgeeft. Hij gaat het pas weer proberen na een zap. Ik vind dat heel naar; als je even aan het klooien bent op je kaartserver, en je client staat een opname te maken, dan mis je niet dertig seconden, maar gewoon de rest van de opname. Als iemand mij kan vertellen hoe ik daar wat aan kan doen OF hoe dat gefixt kan worden in de source houd ik me ten zeerste aanbevolen.

Volgensmij hier:

module-dvbapi.c

regel 2069 if (!forceentry && demux[i].tries>3)

met force kunt je decodering blijven afdwingen, echter door dat verrekte simulcrypt werkt dat weer niet he.
Je zou wel tries aanzienlijk hoger dan 3 kunnen zetten.

[HPPli]

Volgensmij hier:

module-dvbapi.c

regel 2069 if (!forceentry && demux.tries>3)

met force kunt je decodering blijven afdwingen, echter door dat verrekte simulcrypt werkt dat weer niet he.
Je zou wel tries aanzienlijk hoger dan 3 kunnen zetten.

Bedoel je deze ??? ; lb_retrylimit = 500

Edited by HPPli, 9 March 2012 - 00:05.

[Black Tiger]

Gisteravond laat is een paar keer zomaar m'n Oscam (SVN6483 dacht ik) gecrashed op de ET9000. Zojuist daarom geupgrade naar 6490.
Maar nu zie ik kort hierna het volgende een aantal keren terugkomen in de status:

2012/03/09 02:00:00 0 dropped old reader answer rc=5 from undef time 15133ms
2012/03/09 02:00:00 0 dropped old reader answer rc=5 from undef time 15133ms

Opeens gebeurde dit niet meer. Maar wat betekent dit, of waar kan dit vandaan komen?

[ni_hao]

Erik heeft het hier ook al eens gevraagd, maar ik heb nog geen verklaring gelezen: wie kan me eens uitleggen wat de functie van oscam.tiers is? De structuur is - voor zover ik heb gezien - hetzelfde als oscam.srvid

Edited by ni_hao, 9 March 2012 - 08:33.

[Erik Slagter]

Het schijnt iets te maken te hebben met programmapakketten op SKY (Deutschland). Hier niet van toepassing.

[Erik Slagter]

Volgensmij hier:

module-dvbapi.c
 
 
regel 2069 if (!forceentry && demux.[i]tries>3)

met force kunt je decodering blijven afdwingen, echter door dat verrekte simulcrypt werkt dat weer niet he.
Je zou wel tries aanzienlijk hoger dan 3 kunnen zetten.

Bedoel je deze ??? ; lb_retrylimit = 500

De vraag is natuurlijk naar welke config entries (inderdaad) deze waarden verwijzen. Mijn ervaring is dat dat met oscam nog een heel zoekwerk is, als het al een config entry is.

Waar staat die forceentry bijvoorbeeld voor? En die "3" duidelijk hardcoded, joepie. Wat je eigenlijk wilt is dat hij het met een kleine pauze blijft proberen.

[mika-nl]

Volgensmij hier:

module-dvbapi.c
 
 
regel 2069 if (!forceentry && demux.[i]tries>3)

met force kunt je decodering blijven afdwingen, echter door dat verrekte simulcrypt werkt dat weer niet he.
Je zou wel tries aanzienlijk hoger dan 3 kunnen zetten.

Bedoel je deze ??? ; lb_retrylimit = 500

De vraag is natuurlijk naar welke config entries (inderdaad) deze waarden verwijzen. Mijn ervaring is dat dat met oscam nog een heel zoekwerk is, als het al een config entry is.

Waar staat die forceentry bijvoorbeeld voor? En die "3" duidelijk hardcoded, joepie. Wat je eigenlijk wilt is dat hij het met een kleine pauze blijft proberen.

Gaat dit misschien een oplossing zijn.
http://streamboard.g.../changeset/6491

MiKa

[Erik Slagter]

Ik heb even naar de code gekeken en nee, ik denk het niet.

[mika-nl]

Ik heb even naar de code gekeken en nee, ik denk het niet.

Denk dat ik het nu ook zie ja, hij probeert 3x en gaat dan over op een andere caid.

[Erik Slagter]

Dat geeft op zich niet, alleen na drie keer (hardcoded) alle caids geprobeerd te hebben, kapt hij ermee.

[theparasol]

En weet je hoe je dat kunt voorkomen?

Forceentry zet je zo:

P:0100:00006a 1

Alleen @#$%@# $ niet te gebruiken met symulcrypt. Hij blijft stug de 0100:00006a aanvragen maar ik verwacht dat het met requestmode 1 wel weer gaat werken.
Of je gooit die ouwe M:1817:00006a 0100:0006a erin met een P: 1817:00006a 1