4250 replies to this topic

[sattommy]

Bedankt voor alle info in dit topic. Met de volgende dvbapi file (en request mode 0) heb ik prima resultaten:


# dvbapi configuration
#
# types:
# P - Priority
# format:
# P: <caid>:[<provider>]:[<srvid>]:[<ecmpid>]
# I - Ignore
# format:
# I: <caid>:[<provider>]:[<srvid>]:[<ecmpid>]
# M - Map
# format:
# M: <caid>:[<provider>]:[<srvid>]:[<ecmpid>] <target caid>:[<target provider>]
# D - Delay
# format:
# D: <caid>:[<provider>]:[<srvid>]:[<ecmpid>] <delay (ms)>
#
#

P: 1843 #Duits HD gecodeerd
P: 1702
I: 0622 #NL irdeto
I: 1817 #NL Nagra
I: 1818 #BE Nagra
I: 1819 #?? Nagra
I: 1834
I: 0960
I: 0961
I: 1834
I: 09C4
I: 09C7
I: 09AF
I: 1861

#P: 0100::1B7B:070E #NED1HD
I: 0100::1B7B:0646 #NED1HD

I:0100::0FAB:0643 # NED1 SD
I:0100::0FAC:0644 # NED2 SD
I:0100::0FAD:0645 # NED3 SD
I:0100::07D4:0643 # RTL4 SD
I:0100::07D5:0644 # RTL5 SD
I:0100::0FA2:0641 # SBS6 SD
I:0100::07D6:0649 # RTL7 SD
I:0100::07EF:0647 # Veronica SD CDS
I:0100::0FA3:0642 # NET5 SD

Ja dus ook 1 ignore voor NED1 HD. Want hier word nog een 2de ecm pid meegestuurd. Ik heb ook de source eens bekeken, en eventueel kan ik deze wel aanpassen zodat seca3 voorrang heeft. Klopt het dat de 1818 pid er alleen is op seca3?

Verder doet oscam het volgende, wat volgens mij ook juist de problemen veroorzaakt:
Als hij in het lijstje met pids eenzelfde CAID en PROVID ziet staan start hij een filter voor allemaal. Hierdoor doet bijvoorbeeld NED1 HD lastig. Weet iemand waarom dit gedaan word?

Bovenstaand lijstje, zijn dit de enige seca2 kanalen die er nog zijn?

Edited by sattommy, 17 January 2012 - 19:57.

[Erik Slagter]

@Erik Slagter: en om je netwerk helemaal uit te sluiten: maak effe een crosscable, geef eventueel beide boxen een vast ip en en verbind de 2 boxen rechtstreeks. Als je dan nog disconnects krijgt ligt het aan je boxen of aan oscam.

Ik weet genoeg van ip en met name van tcp dat ik durf te stellen dat de tests die ik gedaan heb 100% een fysiek netwerk-probleem uitsluiten.

[theparasol]

Het spulletje al gewiresharked?

[Erik Slagter]

@Erik: ik werk met CCcam protocol ter interconnect maar niet met extended oscam CCcam protocol, dat ook geprobeert?

Kan ik ook nog wel eens proberen, ik snap alleen niet waarom je een protocol dommer zou maken dan nodig...

[theparasol]

Bovenstaand lijstje, zijn dit de enige seca2 kanalen die er nog zijn?

Discovery, national geographic, cartoon netwerk.
Kortom het hele oude seca pakket van weleer wordt nog (verplicht) ondersteunt op seca2

[Erik Slagter]

Het spulletje al gewiresharked?

Yep, voor de liefhebbers heb ik een pcap file staan, in ascii kan ook. Zie ticket bij oscam ;-)

Daarin zie je dat de verbinding op ip en tcp niveau volstrekt normaal verloopt. Geen retransmits en geen RST's. Dat heb ik ook in het ticket gemeld.

Volgens mij is het gewoon een kwestie van dat de server soms (om verschillende redenen) lang bezig is om een cw te verkrijgen en in de tussentijd niet naar de client luistert. De client constateert timeout op de verbinding, denk dat de verbinding "weg" is ofzo en opent een nieuwe verbinding. Server reageert uiteindelijk toch op de oude verbinding, krijgt daar geen antwoord op en gooit de verbinding weg. Client ziet gesloten verbinding, meldt dat en bouwt weer een nieuwe verbinding op. Ik zie bijna altijd meerdere verbindingen tussen client en server, dat lijkt me op zich al niet kosher. Ik heb ook wel een tijdje "uniq" aan gehad, maar dan gaat het dus helemaal fout.

Ik ga zo nog even testen met de nieuwste oscams en misschien ook nog wel hypercam.

Edited by Erik Slagter, 17 January 2012 - 20:16.

[theparasol]

Global sleep op 0 zetten. Heb ik erg nare ervaringen mee als die op andere waarde staat, vergelijkbaar met wat jij post: multiple connections etc etc.

Edited by theparasol, 17 January 2012 - 20:06.

[Erik Slagter]

Global sleep op 0 zetten. Heb ik erg nare ervaringen mee als die op andere waarde staat, vergelijkbaar met wat jij post: multiple connections etc etc.

Heeft altijd op 0 gestaan...

Wat voor timeouts heb jij ingesteld? Op server en client? Het is mij nog steeds totaal niet duidelijk wat die waarde in de praktijk doet.

[theparasol]

Client timeout = 9800

Client max idle time = 120

Keepalive op alle readers aanstaan

Of bedoel je wat anders?

[posixx]

@Erik Slagter: en om je netwerk helemaal uit te sluiten: maak effe een crosscable, geef eventueel beide boxen een vast ip en en verbind de 2 boxen rechtstreeks. Als je dan nog disconnects krijgt ligt het aan je boxen of aan oscam.

Ik weet genoeg van ip en met name van tcp dat ik durf te stellen dat de tests die ik gedaan heb 100% een fysiek netwerk-probleem uitsluiten.

Dat zal allemaal best, maar om mijn beurt durf ik wel te beweren dat het probleem niet in oscam zit. Je bent zowat de enige die hier last van heeft..

[Erik Slagter]

Client timeout = 9800
Client max idle time = 120
Keepalive op alle readers aanstaan
Of bedoel je wat anders?

Ja die. Keepalive heb ik ook overal aan staan.

[Erik Slagter]

Dat zal allemaal best, maar om mijn beurt durf ik wel te beweren dat het probleem niet in oscam zit. Je bent zowat de enige die hier last van heeft..

Ik ben zowiezo een van de weinigen die 100% alleen oscam gebruikt, voor lokaal en voor intern sharen. Het is helemaal niet zo gek als daar een bugje zou zitten. En hoeveel mensen pluizen nou hun logfiles uit... En er zijn genoeg instellingen in oscam die kunnen uitmaken... Ook wel opvallen dat ik hier een paar maanden geleden gewoon geen last van had.

Edited by Erik Slagter, 17 January 2012 - 20:46.

[theparasol]

Nice staat bij mij op de ene op default (=99) en de andere op 0. Waarom ik dat ooit gedaan heb weet ik niet meer, vermoedelijk vergeten terug te zetten

[posixx]

Ik heb hier alle clients gedraaid en geprobeerd, allemaal werken ze ok. Tot vandaag gebruikte ik ook alleen oscam op m'n clients. Nu heb ik mgcamd draaien volgens SatMann's handleiding en moet zeggen dat dit toch wel beter/sneller werkt dan de oscam client. Daarnaast heb je het voordeel dat mgcamd ook een emu is. Wellicht kan je die eens testen? Ik weet niet hoeveel clients je ter beschikking hebt maar zou je de server (oscam dus) ook eens op een andere box kunnen draaien, kijken of dat hetzelfde resultaat geeft.

[Erik Slagter]

Heb ik ook mee geexperimenteerd, maakt niet uit. Als het betekent wat ik denk (linux proces prio) dan is alleen de range -19 .. + 19 zinvol.

[Erik Slagter]

@posixx: ik ben niet geinteresseerd in emu's...

[theparasol]

Bovenstaand lijstje, zijn dit de enige seca2 kanalen die er nog zijn?

Discovery, national geographic, cartoon netwerk.
Kortom het hele oude seca pakket van weleer wordt nog (verplicht) ondersteunt op seca2

EEN SD en KetNet/Canvas SD hebben ook een seca2 pid

[posixx]

@posixx: ik ben niet geinteresseerd in emu's...

Dus, samengevat:

- je draait oscam als server + dvbapi op box 1
- op box 2 draai je oscam als client + dvbapi connected naar box 1

Wanneer je met box 1 als client connect naar 127.0.0.1, krijg je dan ook de timeouts? Waarschijnlijk heb je dit al geprobeerd maar kon het niet zo gauw terugvinden.

[Erik Slagter]

Ik heb even de source erbij gepakt, immers meten = weten.

Deze melding is niet het gevolg van een "network error". De melding is gewoon wat misleidend. Het betekent dat deze oscam zelf de connectie sluit. Dat kan volgens de code op twee "oorzaken" gebeuren, "ergens" een timeout (de precieze timeout heb ik er zo snel niet uit kunnen halen) of een tcp connect die mislukt is. Maar ik heb de melding ook met udp, dus moet het "oorzaak" 1 zijn. Dus ik ga nog maar weer wat spelen met de diverse timeouts.

[Erik Slagter]

De tijd gaat al weer veel te hard, morgen weer verder. Dan zal ik wat debug code in oscam toevoegen, zodat ik beter weet wat er gebeurt. Precies hier geeft oscam heel weinig logging.