Vele 'Unsubscribed' meldingen en beeld vastlopers daardoor

[Alex1970]

Kan je ook iets zeggen welke regels je aangepast hebt en hoe?

[Codx]

@DBdrug,

 

Ik vind het een vreemd verhaal worden. Je test met 1 en daarna 2 ontvangers en ziet geen problemen. Daarna zeg je 3 dagen later dat het weer niet goed werkt. (?)   Wat heb je dan exact uitgeprobeerd en heb je overal logs van?  Je had stapje voor stapje moet kijken en zien wat er gebeurd. Er moet een keer een verandering optreden en die moet verklaarbaar zijn. Is het niet 1 specifieke ontvanger die alles in de soep laat lopen?

 

Laat er desnoods iemand  naar kijken die er verstand van heeft want dit moet binnen 30 min te testen en op te lossen zijn.

 

Unsubscribed meldingen zijn niks anders dan dat de kaart zegt, ik ben niet geautoriseerd om die zender te decoderen.  Dat kan voorkomen wanneer de kaart werkelijk geen rechten voor betreffende zender heeft of wanneer de gestuurde ECM (aanvraag) niet door de kaart kan worden gedecodeerd en dus de aanvraag bijvoorbeeld verminkt is. Alleen probeer je door de ecm lengte en ecm header whitelist verkeerde ecm aanvragen bij de kaart weg te houden en als alle boxen goed werken hoor je ook geen verminkte ecm's te krijgen.  Mocht je aan WAN CS doen dan en lijntjes ruilen met vreemden dan zijn die aanvragen mogelijk onvermijdelijk en dat veranderd de zaak.

 

Je zegt dat de kaart op zwart gaat maar hoe moet ik dat zien? is het de anti-cs die een rol speelt of stopt de kaart op zichzelf met werken? Bij een unsubscribed geeft oscam een NOK, bij een kaart in anti-cs krijg je gewoon CW's. 

 

Allereerst post hier de huidige config van je server. Dus de oscam.conf, oscam.server en oscam.users. Daarna minstens 5 minuten  live-log.  Zet de oscam log desnoods op debug stand 2 waarin je ook de ECM's en CW's kunt zien voorbij komen.

 

 

@toppers, welke regels heb je het over want je praat in raadsels.

 

[Codx]

@DBdrug, 

 

Ik heb nog eens kritisch naar je oscam.txt log gekeken die je eerder hebt gepost.

 

Deze 2 regels gaan goed:  (user2 is de orginele aanvrager en voor user1 komt die dan uit de cache want de ecm en cw zijn al bekend)

 

2016/04/18 09:29:07 4D352548 c (ecm) user2 (0100@00006A/5C00/5225/64:6D4DD6F1A92CA01AE73494338F038794): found (310 ms) by reader1 - NPO 1 HD

2016/04/18 09:29:07 38A8A724 c (ecm) user1 (0100@00006A/5C00/5225/64:6D4DD6F1A92CA01AE73494338F038794): cache2 (310 ms) by reader1 - NPO 1 HD

 

Dan gaat het fout:

 

user3 stuurt een ECM die wel de kaart bereikt maar door de kaart wordt beantwoord met unsubscribed.(nok) Die aanvraag telt echter wel mee voor de ratelimiter.  Helaas kunnen we niet zien hoeveel aanvragen er in de 10 seconde er voor zitten want je log gaat niet zover terug.. In ieder geval zie je dat er in 1 seconde ineens 5 aanvragen van user3 worden gedaan voor NPO1 HD . Aangezien ik daar geen cache melding zie staan vraag ik me af of deze aanvragen de kaart bereiken en verschillend zijn. Zo ja dan is het niet zo vreemd dat de ratelimiter vervolgens op 09:29:17 ingrijpt en zegt... ja sorry maar je bent over de 4 heen gegaan en nu mogen er de komende 10 seconde totaal geen aanvragen meer worden doorgelaten en dan heb je uiteraard zwart beeld maar niet omdat de kaart in anti-cs staat.   Kortom de ecm unique functie in de ratelimiter kan het ook juist verzieken voor de goede aanvragers. Die heeft namelijk geen weet of de ecm correct was. Hij kan alleen kijken naar de volgorde van de ecm aanvragen en het aantal tellen.. Was de vorige ODD dan moet deze EVEN zijn. etc.

 

Nadat de periode van 10 seconde weer voorbij is worden er weer aanvragen van user1 en user2 doorgelaten die wel goed zijn.

 

Het lijkt er dus in dit geval op dat user3 de veroorzaker is maar er is te weinig log om goed te beoordelen.  En verder is het vreemd dat je zoveel aanvragen blijft zien. Normaal heb je om de 10 seconde een ecm dus hoor je niet 20 aanvragen per seconde te krijgen, want dan is oscam op de client mogelijk niet goed ingesteld en dit verklaard misschien ook waarom je uberhaupt verkeerde aanvragen krijgt.  

24 april 2016 aangepast door Codx

[Toppers]

@DBdrug,

 

Ik vind het een vreemd verhaal worden.

 

Laat er desnoods iemand  naar kijken die er verstand van heeft want dit moet binnen 30 min te testen en op te lossen zijn.

 

Unsubscribed meldingen zijn niks anders dan dat de kaart zegt, ik ben niet geautoriseerd om die zender te decoderen.  Dat kan voorkomen wanneer  wanneer de gestuurde ECM (aanvraag) niet door de kaart kan worden gedecodeerd en dus de aanvraag bijvoorbeeld verminkt is.

 

@toppers, welke regels heb je het over want je praat in raadsels.

 

 

Allereerst, met bovengenoemde passages ben ik het in zijn geheel eens !

 

En inderdaad, ik spreek in misschien raadsels omdat @DBdrug niets heeft ondernomen c.q. getest tot op heden en ik enkel (nogmaals) wil verduidelijken dat we meer nodig hebben dan een vermelding van welke Oscam-binary hij gaat gebruiken. (Waarin, in Server of STB). Kortom, ik vind het ook een vreemd verhaal (lees topic) worden.

[DBdrug]

Jammer is dat toch dat DBdrug niet doet wat er gevraagd wordt, trekt goede adviezen al bij voorbaat in twijfel en dan klagen dat hij ondanks dat Unsubscribed melding blijft houden.

 

Euh... trekt goede adviezen in twijfel? Waarop doel je nu precies? Met alleen 'probeer dit eens' zonder verdere uitleg danwel verklaring voor de aangepaste settings, ben ik inderdaad wellicht wat (iets te?) sceptisch. Ik sla de adviezen zeker niet in de wind, maar snap graag het hoe en waarom erachter. 

 

Ik heb de config van Toppers geprobeerd, ben teruggegaan naar een oudere binary (wellicht dom dat ik eerst weer terug ben gegaan naar 11211 en niet naar 11205, maar 11211 heeft bij mij tijd zonder problemen gewerkt eerder). Het is de ratelimiter die parten speelt na ontvangen van een 'unsubscribed' aanvraag. Doordat deze foute aanvragen inderdaad in veelvoud binnenkomen (waarom dit gebeurd weet ik niet, hoe zet je dit uit?), zorgt de ratelimiter ervoor dat daarna de juiste aanvragen niet meer de kaart bereiken. Met beeld op zwart tot gevolg... meestal heb ik 10 seconden erna weer beeld, maar soms binnen een minuut beeld weer op zwart...

 

Zoals al in mijn eerste bericht is te lezen, ik maak gebruik van een thuis servertje (Ubuntu 12.04.5 LTS x86), waarop ik de libusb-pcsc binary van download.oscam.cc draai.

 

Ik draai op de ontvanger met user3 OSCam (uit OpenPLi, weet niet exact welke versie, maar box is recent ge-update). Wat moet ik daar op instellen, zodat bij een NOK deze ontvanger daarna niet vele malen nogmaals dezelfde foute ECM aanbiedt bij mijn server? 

 

Ik zal ook nogmaals loggen, zodat situatie wellicht meer duidelijk wordt. Vorige log is inderdaad wat kort.

25 april 2016 aangepast door DBdrug

[DBdrug]

@DBdrug,

 

Ik vind het een vreemd verhaal worden. Je test met 1 en daarna 2 ontvangers en ziet geen problemen. Daarna zeg je 3 dagen later dat het weer niet goed werkt. (?)   Wat heb je dan exact uitgeprobeerd en heb je overal logs van?  Je had stapje voor stapje moet kijken en zien wat er gebeurd. Er moet een keer een verandering optreden en die moet verklaarbaar zijn. Is het niet 1 specifieke ontvanger die alles in de soep laat lopen?

 

 

Ik had donderdag 2 ontvangers aan, gisteravond stonden er 3 aan. Niet specifiek ter test, maar 'gewoon'. Mogelijk is het inderdaad de derde ontvanger met OSCam, welke de boel verstierd. Maar niet eerder geconstateerd dat het specifiek deze ontvanger zou zijn, waarna het misgaat. 

 

Mogelijk omdat ik deze ontvanger wel recentelijk heb ge-update, met daarna waarschijnlijk een nieuwere OSCam binnen OpenPLi, is dit wellicht de achterliggende oorzaak?

[Codx]

DBdrug schreef op 25 Apr 2016 - 10:29:

Het is de ratelimiter die parten speelt na ontvangen van een 'unsubscribed' aanvraag. Doordat deze foute aanvragen inderdaad in veelvoud binnenkomen (waarom dit gebeurd weet ik niet, hoe zet je dit uit?), zorgt de ratelimiter ervoor dat daarna de juiste aanvragen niet meer de kaart bereiken. Met beeld op zwart tot gevolg... meestal heb ik 10 seconden erna weer beeld, maar soms binnen een minuut beeld weer op zwart...

 

ja ok dit is het geval in je jou korte stukje log maar daar dan zou ik eerder zeggen, kijk is goed waarom je die verkeerde aanvragen krijgt. Dat is immers de oorzaak van dit alles lijkt het nu.. Verder zou ik de ecm unique uitzetten en de cwcycle check aan op 0100  en "only log bad CW" . En dan wil ik graag een log van jou zien met ecm/cw's waarin het fout gaat.

 

Trouwens hoeveel CDS kaarten heb je in de server zitten ? want als je met 1 kaart probeert 3 ontvangers te voeden zal dat niet altijd lukken. Er zijn immers een aantal zenders waar als je meer dan 2 aanvragen gelijktijdig op de kaart doet deze alsnog in anti-cs belandt. (de 2/10 ipv 4/10 zenders)  Het beste is dit via een oscam.ratelimit file te regelen waar je het per zender aangeeft wat de limit is ipv globaal.  

 

Voor de exacte oscam client instellingen zal ik ff moeten kijken, ik gebruik CCcam als client.

[Toppers]

Euh... trekt goede adviezen in twijfel? Waarop doel je nu precies? Met alleen 'probeer dit eens' zonder verdere uitleg danwel verklaring voor de aangepaste settings, ben ik inderdaad wellicht wat (iets te?) sceptisch. Ik sla de adviezen zeker niet in de wind, maar snap graag het hoe en waarom erachter. 

Misschien zinvol en om e.e.a. beter te snappen is om uitleg en toelichting te vragen op het specifieke Oscam-board genaamd Streamboard http://www.streamboard.tv/wbb2/index.php

[Toppers]

Trouwens hoeveel CDS kaarten heb je in de server zitten ? want als je met 1 kaart probeert 3 ontvangers te voeden zal dat niet altijd lukken. Er zijn immers een aantal zenders waar als je meer dan 2 aanvragen gelijktijdig op de kaart doet deze alsnog in anti-cs belandt. (de 2/10 ipv 4/10 zenders)  Het beste is dit via een oscam.ratelimit file te regelen waar je het per zender aangeeft wat de limit is ipv globaal.  

@Codx ...........Weet jij misschien welke headers in de Seca3 // CDS ecmheaderwhitelist = 800061006A00075C00,800061006A01075C00,803061006A00075C00,803061006A01075C00,810061006A00075C00,810061006A01075C00,813061006A00075C00,813061006A01075C00

behoren bij de 4/10 kanalen en welke bij de 2/10 kanalen. Ofwel, wordt er in de ECM-headers hiervoor nog onderscheid gemaakt dat je weet ?

[DBdrug]

Dat weet ik wel, wordt geen onderscheid in gemaakt, helaas. Je kunt niet aan de ECM header dit herkennen.

[beeheap]

Misschien zinvol en om e.e.a. beter te snappen is om uitleg en toelichting te vragen op het specifieke Oscam-board genaamd Streamboard http://www.streamboard.tv/wbb2/index.php

 

Er is al een heleboel info te krijgen in de Oscam Wiki waarheen je geleid wordt door te klikken op de labels van de diverse invoervelden in de WebIf. Je kunt ook direct naar de Oscam Wiki gaan en daarin de gewenste parameters opzoeken.

[Toppers]

Er is al een heleboel info te krijgen in de Oscam Wiki waarheen je geleid wordt door te klikken op de labels van de diverse invoervelden in de WebIf. Je kunt ook direct naar de Oscam Wiki gaan en daarin de gewenste parameters opzoeken.

Kon deze repliek natuurlijk verwachten   Maar ondanks de richting die je aanwijst (klikken op labels, uitvoerige WiKi of Streamboard zelf) nergens geen uitleg over verschillen in parameters binnen de headers kunnen vinden.

Toch bedankt dat je het voor mij hebt geprobeerd

[beeheap]

Kon deze repliek natuurlijk verwachten   Maar ondanks de richting die je aanwijst (klikken op labels, uitvoerige WiKi of Streamboard zelf) nergens geen uitleg over verschillen in parameters binnen de headers kunnen vinden.

Toch bedankt dat je het voor mij hebt geprobeerd

 

Was geen antwoord aan jou gericht maar een aanvulling op jouw antwoord aan BDdrug. (En: nergens geen = overal )

 

 

Euh... trekt goede adviezen in twijfel? Waarop doel je nu precies? Met alleen 'probeer dit eens' zonder verdere uitleg danwel verklaring voor de aangepaste settings, ben ik inderdaad wellicht wat (iets te?) sceptisch. Ik sla de adviezen zeker niet in de wind, maar snap graag het hoe en waarom erachter.

25 april 2016 aangepast door beeheap

[Toppers]

Was geen antwoord aan jou gericht maar een aanvulling op jouw antwoord aan BDdrug. (En: nergens geen = overal )

Ik keek er al van op dergelijk bericht van jou aan mij gericht, nou weet ik niet zoveel over/van Oscam maar de truc om uitleg via de labels aan te klikken in de webif had ik en zowel @DBdrug al onder de knie.

 

Overigens, nergens geen = overal klopt als een bus. Maar beter lezen, de opmerking van nergens geen was ook aangevuld met de specifieke locaties ( klikken op labels, uitvoerige WiKi of Streamboard zelf )

25 april 2016 aangepast door Toppers

[Codx]

@Codx ...........Weet jij misschien welke headers in de Seca3 // CDS ecmheaderwhitelist = 800061006A00075C00,800061006A01075C00,803061006A00075C00,803061006A01075C00,810061006A00075C00,810061006A01075C00,813061006A00075C00,813061006A01075C00

behoren bij de 4/10 kanalen en welke bij de 2/10 kanalen. Ofwel, wordt er in de ECM-headers hiervoor nog onderscheid gemaakt dat je weet ?

 

Zoals DBdrug al zegt is dat niet te zien in de header.  Die 8000/8100 wordt alleen gebruikt voor mezzo/motors tv die van csat afkomstig zijn en die 01 na 6A geeft aan of het nano 01 is. 

 

803061006A00075C00,803061006A01075C00, 813061006A00075C00,813061006A01075C00