279 replies to this topic

[jort38]

Daar ben ik weer over de ondertiteling in combinatie met de Hans settingslijst.

 

Was het in Openpli 4 niet zo heel fijn en moest ik na een update van de settingslijst elke zender opnieuw vertellen dat ik TXT888 ondertitels wil en geen NAR, in Openpli 6.2 is dat iets gewijzigd;

 

Nu moet ik per zender middels de ondertitelknop op de AB (ET10000) aangeven dat ik TXT888 wil. Echter daarna springt het scherm direct na de OK terug naar beeld (jn Pli4 bleef het scherm op deze instelling staan en zag je een kruisje). Ik wacht zeker 10 seconden en dan is er meestal nog geen ondertiteling. Dus weer de ondertitelknop van de AB en zie inderdaad geen kruisje bij TXT888. Opnieuw op OK drukken en zap ik een zender verder of terug en dan is er een tombola. Soms is er ondertiteling en soms niet.

Na een paar keer bovenstaand herhalen lukt het wel hoor en dan blijft de instelling voor die zender ook wel staan.

 

Getest op de FTA kanalen van BBC en ITV.

 

Mag het issue met betrekking tot een soort centrale database alsjeblieft met onder meer deze instelling op de issuelijst?

[theparasol]

Om te beginnen is de naam fout, het "fixed" namelijk niks. Het enige wat het doet is ALLE aanpassingen van de tijd blokkeren. Dat kan zinvol zijn als je de box op transponder time hebt staan, en veel zapt over transponders die een foute tijd hebben. Maar daar hebben we er in onze omgeving niet of nauwelijks van. Het is absoluut een ramp als om e.o.a. reden de tijd van de box fout staat bij het opstarten van Oscam. Want er is dan GEEN ENKELE mogellijkheid meer om de tijd te corrigeren. Of je nu zapt naar een goede transponder, ntp gaat gebruiken, op de commandline met "date" de tijd probeert goed te zetten, niets van dat al werkt, Oscam zet direct de foute tijd weer terug.

 

Het lost dus in slechts specifieke gevallen iets op, en sloopt in meer gevallen iets. Daarom vinden we het middel erger dan de kwaal, en is die fix die niks fixed er uit.

 

Ik denk dat heel veel mensen een verkeerd idee hebben van waar dit precies over gaat.

 

Het bovenstaande geciteerde is niet waar. De source van oscam is public dus ik zou zeggen kijk het even zelf na of laat iemand die je erop vertrouwd het je eens goed uitleggen.

[littlesat]

Dan vergis je je blijkbaar hoe dat met de klok werkt... er is een paar maanden geleden hier een heel lang draadje over geweest... als de klok helemaal fout staat dan gaat het goed. Staat hij een beetje fout dan duurt het tergend langzaam door oscam clockfix dat de tijd wordt bijgeregeld... die clockfix binnen oscam slaat echt wel de plank compleet mis... oscam moet compleet van de tijd afblijven, dat is uit principe al not done.

Edited by littlesat, 15 May 2018 - 22:52.

[WanWizard]

@parasol,

 

Heb ik iets gemist? Jij weet het beter dan ik, ik zie alleen (2x):

#if defined(CLOCKFIX)
	if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec)){ // check for time issues!
		lasttime = tv; // register this valid time 
	}
	else
	{
		tv = lasttime;
		settimeofday(&tv, NULL); // set time back to last known valid time
		//fprintf(stderr, "*** WARNING: BAD TIME AFFECTING WHOLE OSCAM ECM HANDLING, SYSTEMTIME SET TO LAST KNOWN VALID TIME **** \n");
	}
#endif

en dit reset gewoon bot de tijd, als die door iets buiten Oscam is aangepast?

[littlesat]

tja...

Edited by littlesat, 15 May 2018 - 22:54.

[WanWizard]

Het is dus iets genuaceerder.

 

De fix staat wel toe dat de tijd naar de toekomst toe verzet wordt, en daarom gaat het goed van 01-01-1970 naar now(). Maar niet terug, dus eens de tijd te ver in de toekomst staat kun je niet meer corrigeren.

 

Wat ik graag zou willen begrijpen, maar daar is mijn kennis volstrekt onvoldoende voor, is wat er nu precies mis gaat in de ECM handling als de tijd veranderd, en waarom het geen probleem is dat de tijd naar de toekomst aangepast wordt, maar niet naar het verleden.

[littlesat]

Je hebt die klok nodig om bijv max 4 ECM’s per 10 sec naar de kaart te krijgen en daar gebruikt oscam blijkbaar de rtc voor... verder doet e2 en ntp de klok langzaam alias geleidelijk aanpassen als het finetuning is... dus zodra de tijd hoger is dan 1970 of iets dergelijks hoeft oscam niet echts iets met de tijd te doen..

Edited by littlesat, 16 May 2018 - 06:50.

[zeeteefje]

Schoonheidsfoutje: Op mijn ET10K krijg ik de S/N ratio rechtsboven in %, maar rechtsonder in dB. Als ik selecteer om de S/N in dB weer te geven, dan draait dat om.

[Sagitarius †]

Het is dus iets genuaceerder.

 

De fix staat wel toe dat de tijd naar de toekomst toe verzet wordt, en daarom gaat het goed van 01-01-1970 naar now(). Maar niet terug, dus eens de tijd te ver in de toekomst staat kun je niet meer corrigeren.

 

Wat ik graag zou willen begrijpen, maar daar is mijn kennis volstrekt onvoldoende voor, is wat er nu precies mis gaat in de ECM handling als de tijd veranderd, en waarom het geen probleem is dat de tijd naar de toekomst aangepast wordt, maar niet naar het verleden.

En wanneer staat de tijd dan te ver in de tijd? Klokken lopen toch meestal achter, behalve die van mijn vrouw die zet de klok altijd vooruit, dan is ze altijd op tijd zegt ze.

[littlesat]

En wanneer staat de tijd dan te ver in de tijd? Klokken lopen toch meestal achter, behalve die van mijn vrouw die zet de klok altijd vooruit, dan is ze altijd op tijd zegt ze. 

[littlesat]

Hier is enige weken geleden een heel lang draadje over geweest op dit forum dat mensen ervoeren dat de klok fout stond en hij met geen mogelijkheid weer goed te zetten was... Na lang zoeken was de door Oscam veroorzaakte bron gevonden....

[WanWizard]

Je hebt die klok nodig om bijv max 4 ECM’s per 10 sec naar de kaart te krijgen en daar gebruikt oscam blijkbaar de rtc voor...

 

Dan snap ik, maar dat is relatieve tijd, niet absolute tijd.

 

Het kan hooguit een issue zijn als de tijd verspringt midden in zo'n 10 sec periode, maar dan is dan een enkele gebeurtenis, dat zal weinig impact hebben op het straf algoritme.

Dit klinkt als een aanpassing speciaal voor cardservers, en daar kan ik niet te wakker van liggen...

[littlesat]

Maar blijkbaar maken ze van absolute tijd relatieve tijd...

[WanWizard]

@littlesat,

 

Eindelijk tijd gevonden om die 10K wizard aan de tand te voelen.

 

Ik krijg geen GS, maar "your receiver doesn't have an internet connection". Ik heb eth1 aangesloten staan (de 1Gbps "VLAN" interface), eth0 heeft geen kabel. Dus er zit meer scheef in die code.

 

Als ik de wizard af breek en naar de Network setup ga, dan zie ik een "VLAN connection" die disabled is, en een "LAN connection 2" die enabled is. Dus er is een interface enable issue, en er is blijkbaar ook een naamgevingsissue.

[littlesat]

Zit het in de code fout (want daar is in dit stuk al jaren niets aangepast) of is het 'iets' in de 'nieuwere' drivers.... Hoe ziet hij nu de netwerken? eth0 en eth1.... Vreemd want hij moet gewoon eigenlijk de eerste pakken....

 

De gsod komt dat als de software geen eth0 en/of eth1 ziet dat een config die ge/misbruikt wordt om een IP een goede format te geven dan niet bestaat....

Edited by littlesat, 16 May 2018 - 15:06.

[WanWizard]

Volgens mij is het zo dat /etc/network/interfaces uitsluitend "eth0" bevat. En die is bij mij niet aangesloten, dus die doet niks. Zodra ik in de netwerk setup "eth1" activeer komt die er bij te staan en heb ik connectiviteit. 

 

De Wizard pakt vervolgens dan alleen eth0, want meer is er op dat moment niet. En dat verklaart dan die melding.

 

Ik zie even niet hoe hij, vers uit de flash, geen eth0 zou meten zien, dus de GSOD kan ik op dit moment even niet verklaren (of reproduceren).

[littlesat]

De wizard gaat alle netwerk interfaces af en als het eth0 of eth1 is kijkt hij of deze 'interface' up is en als die up is wordt die gebruikt... Hij moet does als eth0 down is automatisch eth1 nemen.... 

 

Ik ben bang dat er iets in de drivers zit dat om dit moment eth1 nog niet 'up' is... Hij kan ook alleen 'up' gaan hij een IP kan krijgen...

             if self.index == self.STATE_UPDATE:
                           config.misc.installwizard.hasnetwork.value = False
                           config.misc.installwizard.ipkgloaded.value = False
                           modes = {0: " "}
                           self.enabled = ConfigSelection(choices = modes, default = 0)
                           self.adapters = [(iNetwork.getFriendlyAdapterName(x),x) for x in iNetwork.getAdapterList()]
                           is_found = False
                           for x in self.adapters:
                                  if x[1] == 'eth0' or x[1] == 'eth1':
                                        if iNetwork.getAdapterAttribute(x[1], 'up'):
                                               self.ipConfigEntry = ConfigIP(default = iNetwork.getAdapterAttribute(x[1], "ip"))
                                               iNetwork.checkNetworkState(self.checkNetworkCB)
                                               if_found = True
                                        else:
                                               iNetwork.restartNetwork(self.checkNetworkLinkCB)
                                        break
                           if is_found is False:
                                        self.createMenu()

Edited by littlesat, 16 May 2018 - 15:28.

[Superster]

Weer even over CCcam 2,32, net even op een andere oude VuDuo ook 6.2 gezet, en meteen 2.32 er bij, zelfde probleem, Canal Digitaal kaart wordt dan niet gezien, Digitenne kaart wel. Oscam geen probleem, 2.30 later ook niet.

 

Zal later het 's op een heel ander merk receiver proberen.

[WanWizard]

De wizard gaat alle netwerk interfaces af en als het eth0 of eth1 is kijkt hij of deze 'interface' up is en als die up is wordt die gebruikt... Hij moet does als eth0 down is automatisch eth1 nemen.... 

 

Als die niet in /etc/network/interfaces staat, dan wordt die niet aangemaakt laat staan dat die dan up komt. Hij bestaat dan gewoon niet.

[WanWizard]

Weer even over CCcam 2,32, net even op een andere oude VuDuo ook 6.2 gezet, en meteen 2.32 er bij, zelfde probleem, Canal Digitaal kaart wordt dan niet gezien

 

Ik had bij het wisselen wel issues, maar ik zal ook met een CI module te stoeien. Na een reboot werkte het in ieder geval hier, op een HD2400 en een ET10000, prima.