350 replies to this topic

[theparasol]

Oorzaak is al vele malen gemeld aan Oscam, met oplossing (synthetic time gebruiken intern ipv realtime zodat intern 60 seconden altijd precies 60 seconden duurt, ongeacht wat de linux klok doet), maar tot op heden alleen maar dovemansoren.

 

En daar zeurt Oscam over, omdat er hardcoded vaste wachtlussen in de code zitten die op bovenstaand principe zijn gebaseerd.

 

Dat dovemansoren is niet erg aardig he!

Er zijn echt serieuze pogingen gedaan dit te fixen maar dat lukt niet omdat het niet compatible blijkt met alle systemen waarop het draait.

Nu snap ik wel dat jij geen dev bent maar je meent er wel iets over te kunnen en moeten roepen.

Oscam is opensource. Niks houdt je tegen om daar zelf aanpassingen in te doen.

Ik weet ook wel dat de clockfix verre van ideaal is maar aangezien het wel voor mijn persoonlijke gebruik de problemen oploste is het voor mij en anderen wel een oplossing.

Namelijk heel simpel kijken met een lokale kaart. Opnames doe ik nooit dus die timer issues zal me aan de spreekwoordelijke anus roesten.

 

Er zitten echt helemaal geen vaste wachtlussen in oscam!

De ellende komt voort uit feit dat elke ecm in de cache een timestamp meekrijgt, als ineens de tijd terug zet wordt dan loopt alles in de soep en krijg je zwart beeld.

Dat zwart beeld is een ergere fout dan een opname die niet strak getimed staat.

Daarbij als de klok eenmaal goed staat wil het er bij mij niet in dat die in een uur meer dan 60 seconden gaat afwijken.

Daar zitten toch echt andere problemen achter. 

Het syncen naar transponder tijd is idioot net zoals het telkens met ntp syncen. Nergens goed voor.

Box start op, tijd wordt goed gezet middels ntp of transponder time en dan kappen met schroeven aan de systemklok. Gebeurde vroeger ook niet met systemen.

De RTC tikte ook rustig door en niemand die daar problemen mee had.

 

Zo en verder soebatten jullie maar verder over de oorzaak en gevolg maar op moment dat ik weer leugens lees mbt oscam dan meld ik me wel weer om die recht te zetten.

Dus ja die clockfix werkt echt, en ja je kunt dan tegen een potentieel timer issue lopen. Maar ik vind dat persoonlijk niet opwegen tegen zwart beeld in je opnames of kanaal wat je real time kijkt.

[luisteraar]

de time functie om time op te vragen omleiden naar een eigen functie.

Die eigen functie doet dan de time opvraag die slaat die dan op.

Als de nieuwe tijd ouder is als de oude tijd bepaal het verschil/offset.

Bij de tijd teruggave uit functie tel die oude offset er bij zodat nieuwe

tijd gelijk is aan oude tijd.

Komt een tijdspring in de toekomst pas de offset weer aan zodat

nieuwe tijd weer gelijk oude tijd.

Is geen ideale oplossing maar zou kunnen werken.

[WanWizard]

Dat dovemansoren is niet erg aardig he!

 
Misschien niet, maar feit blijft dat dit al jaren een probleem is.
 

Er zijn echt serieuze pogingen gedaan dit te fixen maar dat lukt niet omdat het niet compatible blijkt met alle systemen waarop het draait.

 
Dat is voor mij nieuws, maar goed te horen !
 

Nu snap ik wel dat jij geen dev bent maar je meent er wel iets over te kunnen en moeten roepen.
Oscam is opensource. Niks houdt je tegen om daar zelf aanpassingen in te doen.

 
Tja, ach, wat is een dev? Iemand die programmeert? Dat doe ik al bijna 50 jaar. Maar mijn C kennis stamt nog uit de tijd van Turbo C, dat is niet meer van het niveau dat ik het kan vlot schrijven zonder boeken en Google.
 
Dus ik laat het dan maar aan zij die er meer verstand van hebben. Maar ik kan 't prima lezen .
 

Daarbij als de klok eenmaal goed staat wil het er bij mij niet in dat die in een uur meer dan 60 seconden gaat afwijken.
Daar zitten toch echt andere problemen achter.

 

Daar zijn we het helemaal over eens. Vandaar ook mijn opmerking die die clockfix "dit" probleem niet fixt.
 

Het syncen naar transponder tijd is idioot net zoals het telkens met ntp syncen. Nergens goed voor.
Box start op, tijd wordt goed gezet middels ntp of transponder time en dan kappen met schroeven aan de systemklok. Gebeurde vroeger ook niet met systemen.
De RTC tikte ook rustig door en niemand die daar problemen mee had.

 

Daar kan ik het maar deels mee eens zijn.

De transponder tijd sync is nodig voor als je box geen internet verbinding heeft, maar moet inderdaad niet de primaire tijdbron zijn. Dat is bij ons dus ook NTP, en die doet automatisch een sync als de netwerk interface op komt.

Echter, de meeste STB hardware is dusdanig brak dat de tijd, ook op dure boxen, makkelijk een seconde per uur kan afwijken. Veel meer dan bv PC hardware. Daarnaast heeft praktisch geen enkele box een RTC.

Dat, in combinatie met het feit dat CAM's in het algemeen graag de juiste tijd willen (ook Oscam dus), lijkt het me verdedigbaar dat NTP eens per uur een update doet. Vreet verder ook geen brood.
 

Zo en verder soebatten jullie maar verder over de oorzaak en gevolg maar op moment dat ik weer leugens lees mbt oscam dan meld ik me wel weer om die recht te zetten.
Dus ja die clockfix werkt echt, en ja je kunt dan tegen een potentieel timer issue lopen. Maar ik vind dat persoonlijk niet opwegen tegen zwart beeld in je opnames of kanaal wat je real time kijkt.

 

Geen idee over welke leugens je het hebt.

 

Dat die clockfix doet waarvoor het gemaakt is geloof ik wel, en betwist ik ook niet.

Die clockfix lost echter het probleem van de TS niet op (daarvoor moet de oorzaak van die 60s gevonden worden), en die clockfix heeft ook zeer vervelende bijeffecten, zeker bij boxen die niet aan het internet hangen. En dus zetten wij hem niet aan.

[WanWizard]

de time functie om time op te vragen omleiden naar een eigen functie.

 

Precies., Geen realtime clock, maar een pseudo of synthetic clock dus.

 

Voor (bijna?) alle gevallen die ik in de code heb gezien is de exacte tijd helemaal niet van belang, maar gaat het om delta's, in de vorm van "timestamp + x seconden". Wat die timestamp is, is niet relevant (zolang die maar van een betrouwbare bron is afgeleid), die x seconden wel.

 

Als dus de realtime clock als niet voldoende betrouwbaar hebben vastgesteld (en dat lijkt me hierboven wel aangetoond) dan kun je net zo goed de clock op 0 zetten bij de start van Oscam, en die intern laten "ticken".

[littlesat]

Een applicatie zoals oscam hoort de klok niet vast te zetten op het systeem…. Dat is not done… als de klok verloopt waardoor de ecm timestamps gekke dingen doen moet op het systeem opgelost te worden waar het op draait. Als het systeem dat niet kan zou het handig zijn dat als je het in de applicatie doet een optie is… die ja alleen aanzet voor die systemen… zeker een oscam server die langere tijd normaal draait is het niet handig dat oscam de tijd vasthoud/de baas is…

[luisteraar]

Dat de time opvraag voor de user niet altijd correct is is al lang bekend.

Bij client software die afhankelijk is van die tijd moet opvang routines hebben.

In een lang verleden daar ook problemen mee gehad in het bijzonder bij

omschakeling van zomer naar wintertijd en omgekeerd terwijl de bediener

van client de lands tijd wil zien.

De hulp roep van theparasol stoort mij zeer van het is opensource je bent vrij

het op te lossen,dit noem ik geen normale hulp oproep.

[theparasol]

De hulp roep van theparasol stoort mij zeer van het is opensource je bent vrij

het op te lossen,dit noem ik geen normale hulp oproep.

 

De gebruikers zijn tegenwoordig verwend: Ze verwachten op hun wenkjes bediend te worden en als A niet voor je werkt ga je "gewoon" B gebruiken.

Ik geef hier alleen aan waarom de boel op zwart gaat icm oscam en wat ik daar persoonlijk aan gedaan heb en waarom het voor mij wel werkt.

 

Ik heb zelf geen hulp nodig: zoals ik al eerder stelde kan ik persoonlijk prima leven met de huidige werking van oscam!

Vandaar dat ik hier zeg het is opensource en je bent vrij om het zelf op te lossen.

 

Ik heb dat zelf ook jaren terug gedaan toen iedereen nog CCcam gebruikte en ik oscam ontdekte en zijn potentie zag.

Het dvbapi gedeelte werkte totaal niet icm canaldigitaal.

Eerst bugs aanmaken die vervolgens genegeerd worden en zelfs devs die de logs fake noemden want symulcrypt kenden ze niet.

Toen ik zag dat "zeuren" toch niets zou opleveren ben ik zelf maar aan de slag gegaan om het opgelost te krijgen.

Ik durf hier rustig te stellen dat ik dit uiteindelijk hoogstpersoonlijk opgelost heb door een complete refactoring van de dvbapi module.

Dat was geen kwestie van maanden maar van jaren: Mijn insteek is altijd mijn eigen "eenvoudig" oscam op STB gebruik.

 

Ik heb er trouwens erg veel plezier aan beleefd en veel van geleerd.

 

Maar er zijn hier verbeteringen voor oscam gesuggereerd mbt time management. En zeker niet voor het eerst.

Deze implementeren blijkt vrij gecompliceerd. Ik en een paar andere devs / oscam test users hebben hier al een paar maanden werk ingestoken voor jaren terug met als resultaat

dat het instabiel werd en oscam ook niet meer op elk device bleek te werken.

Destijds deed ik alles met notepad++ maar met een goede IDE die ook refactoring ondersteund zal het eenvoudiger zijn.

Dus ik zou zeggen stop met rapporteren en start zelf met coden!

[luisteraar]

 

 

 

Dus ik zou zeggen stop met rapporteren en start zelf met coden!

 

Na 40 jaar programmeer ervaring code ik al 20 jaar niet meer zelf maar geef

aanwijzingen aan nieuwe generaties coders.

De coders bij wie het niet wil lukken kunnen bij mij aankloppen en zal ze bijstaan.

[theparasol]

Met alle respect als je al 20 jaar niet meer de handen in het vet hebt gehad op dit gebied kan je rustig stellen dat je bijstand aanbod van nul waarde is.

Oscam is geschreven in C door hoofdzakelijk hobbyisten en je ergert je als ervaren dev groen en geel aan alle slechte implementaties.

Er valt veel te verbeteren maar je moet uiteraard wel tijd en zin hebben!

Ik zou zeggen gebruik je jarenlange ervaring om dit time issue varkentje goed te wassen ipv zoals iedereen hier langs de zijlijn maar wat te blijven roepen!

[luisteraar]

Met alle respect als je al 20 jaar niet meer de handen in het vet hebt gehad op dit gebied kan je rustig stellen dat je bijstand aanbod van nul waarde is.

 

Nu wordt je beledigend .

90% van mijn werk was in c en c++ geschreven.

Later zijn junior programma makers er bij gekomen die ik moest bijstaan om de

zaak draaiende te houden waardoor ik geen tijd meer had om zelf projecten van 0 tot

aflevering zelf te doen de touwtjes hield ik.

Maar als hulp niet gewenst is geen probleem.

Los hiervan zie ik geen toekomst meer in oscam alles gaat naar ci+ dus einde verhaal.

[luisteraar]

Als toevoeging

 

Wat ik triest vind 6 maanden na dat ik met pensioen ging was de zaak failliet de junior

programma makers hadden dus niet genoeg opgestoken.

[teo1966]

 

 

 

OSCam met clockfix (het is svn11712) zo weet je zeker dat het onderstaande is gelukt (OpenPLi zit op 11711). Kopier het bestand bv met FTP naar je ontvanger in /usr/bin en het volgende doen

cd /usr/bin
killall oscam
cp oscam oscam.org
rm oscam
cp oscam-cf oscam
chmod 755 oscam
oscam -b

is het misschien toch een idee in de feed van de ontvangers een oscam versie met en zonder clockfix te zetten dan kan iedereen zelf kiezen

hetzefde als met oscam en zonder oscam-emu

Edited by teo1966, 17 September 2022 - 12:35.

[theparasol]

Oscam is qua project niet ingewikkeld en heeft geen (bege) leiding gevende hulp nodig maar domweg aanpakkers.

Maar idd je zult het vooral om de uitdaging voor jezelf moeten doen. Net zoals je een kruiswoord raadsel oplost en er je plezier en vermaak van hebt.

Maar doordat het opensource is zul je met je oplossingen anderen inspireren die op hun beurt jouw oplossingen verbeteren of domweg overnemen.

Je laat iets achter wat niet meer verdwijnt itt een commercieel produkt.

De CI+ modules zijn niet alleen een bedreiging voor oscam maar ook voor openpli.

Immers de software moet kunnen praten met de ci module en een voorwaarde daarvoor is dat je over het certificaat beschikt waarmee je je autoriseert en de ci zijn

werk gaat doen. Openpli en andere opensource projecten gaan nooit officiele manier dit  certificaat krijgen en leven momenteel bij de gratie van gelekte certificaten. 

Persoonlijk als gebruiker maakt het mij geen bal uit wat de stream uiteindelijk decrypt als het maar beeld oplevert.

Waar we vroeger ecms uit de stream aanboden aan de kaart en er een controlword voor decryption voor terugkregen jagen we nu een encrypted stream door de ci module

en krijgen we er een decrypted stream voor terug.

Inmiddels zijn we al zo'n 20 jaar verder en ik gebruik sinds een jaar of 2 de schotel ontvanger enkel nog voor FTA ontvangst.

In de huiskamer staat nu een mediaspeler met daarop de canaldigitaal app en dream player premium app waarmee ik comfortabel alle kanalen die ik vrij kan ontvangen kan kijken.

Gebruik ik nog oscam? nee, want ik heb inmiddels nl al 3 jaar geen abonnement meer voor ontvangst per schotel.

En daarmee is het ook klaar met het geven van bijdrages aan oscam.

[luisteraar]

 

Inmiddels zijn we al zo'n 20 jaar verder en ik gebruik sinds een jaar of 2 de schotel ontvanger enkel nog voor FTA ontvangst.

In de huiskamer staat nu een mediaspeler met daarop de canaldigitaal app en dream player premium app waarmee ik comfortabel alle kanalen die ik vrij kan ontvangen kan kijken.

Gebruik ik nog oscam? nee, want ik heb inmiddels nl al 3 jaar geen abonnement meer voor ontvangst per schotel.

En daarmee is het ook klaar met het geven van bijdrages aan oscam.

Hebben we toch een gemeenschappelijk punt gevonden.

Ik kijk ook alleen fta op schotel heb nog 1 legaal kosteloos kaartje door oude rechten.

Voor openpli zie ik geen gevaar er zijn veel fta zenders.

Openpli zou wel meer activiteit kunnen steken in iptv het sleutel gedoe drm hbbtv enz

[theparasol]

Openpli zou wel meer activiteit kunnen steken in iptv het sleutel gedoe drm hbbtv enz

 

Iptv werkt toch al? Ik zie tenminste in de kanalen lijst van Hans meer kanalen op ip streams staan dan dvb kanalen.

Het sleutel gedoe? maak dat eens concreet want ik volg het in elk geval niet.

Drm?  Wat is de toegevoegde waarde daarvan. Wat is het praktische nut?

HbbTv? In mijn beleving een soort van teletext on steroids. Bron van ellende allemaal closed source en ik ken niemand die het gebruikt behalve om eens te zien wat het is.

[WanWizard]

Iptv werkt toch al? Ik zie tenminste in de kanalen lijst van Hans meer kanalen op ip streams staan dan dvb kanalen.

 

Het zou bv wel handig zijn als je een stream zo kunnen opnemen zonder deze opnieuw te moeten openen.

 

 

Drm?  Wat is de toegevoegde waarde daarvan. Wat is het praktische nut?

 

DRM heb je nodig voor de netflixen van deze wereld. Valt in principe ook onder IPTV, en het lijkt wel iets te zijn waar de wereld naar aan het verhuizen is.

 

Niet dat er wat mee gebeurd,  het enige wat DRM ondersteunt op dit moment is Kodi.

 

HbbTv? In mijn beleving een soort van teletext on steroids. Bron van ellende allemaal closed source en ik ken niemand die het gebruikt behalve om eens te zien wat het is.

 

Dat is niet (meer) correct.

 

De HBBTV standaard is open, altijd al zo geweest. De browser implementaties zijn closed source geweest, maar dat is veranderd met de komst van de OpenHbbTV browser. Die werkt nog niet 100%, maar daar wordt aan gewerkt.

 

Ik zou persoonlijk graag zien dat de GUI van de box zou worden vervangen door HbbTV, is gelijk het probleem van IPTV en DRM opgelost ( want het werkt op basis van qtwebengine / chromium ).

[WanWizard]

is het misschien toch een idee in de feed van de ontvangers een oscam versie met en zonder clockfix te zetten dan kan iedereen zelf kiezen

 

De vraag is wat we daar mee opschieten.

 

Zoals eerder gezegd, het lost niet jou probleem op, het verdoezeld het alleen, en introduceerd mogelijk andere problemen.

 

Daarnaast wordt voor ons de ondersteuning lastiger, we moeten dan bij elk probleem gaan uitzoeken welke oscam versie de gebruiker geinstalleerd heeft. En we gaan er klachten bij krijgen van gebruikers die met geen mogelijkheid de klok meer correct krijgen (de reden waarom we het in het verleden juist uitgezet hebben).

 

Kortom, het is leuk voor een techneut die precies weet wat het doet, wat de bijeffecten kunnen zijn, en een bewuste keuze kan maken. Maar 99.99% van de OpenPLi gebruikers schiet er niks mee op.

 

Ik ben er dus geen voorstander van.

[littlesat]

HbbTV is heel lastig omdat dit ook met licenties te maken heeft en de leveranciers…dmr op open source is ook een dingetje… allemaal niet makkelijk. Voor iptv hebben we al hele goede plugins.

[WanWizard]

HbbTV heeft op zich niks van doen met licenties.

 

Er zijn een aantal partijen die software hebben gemaakt (zoals bv Opera HbbTV), en die software is buyware, en in het verleden gebruikt door een aantal fabrikanten voor hoofdzakelijk de duitse markt.

 

Dit is met OpenHbbTV niet meer aan de orde.

[40H3X]

 

is het misschien toch een idee in de feed van de ontvangers een oscam versie met en zonder clockfix te zetten dan kan iedereen zelf kiezen

 

De vraag is wat we daar mee opschieten.

 

Zoals eerder gezegd, het lost niet jou probleem op, het verdoezeld het alleen, en introduceerd mogelijk andere problemen.

 

Daarnaast wordt voor ons de ondersteuning lastiger, we moeten dan bij elk probleem gaan uitzoeken welke oscam versie de gebruiker geinstalleerd heeft. En we gaan er klachten bij krijgen van gebruikers die met geen mogelijkheid de klok meer correct krijgen (de reden waarom we het in het verleden juist uitgezet hebben).

 

Kortom, het is leuk voor een techneut die precies weet wat het doet, wat de bijeffecten kunnen zijn, en een bewuste keuze kan maken. Maar 99.99% van de OpenPLi gebruikers schiet er niks mee op.

 

Ik ben er dus geen voorstander van

 

Idem dito.