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!

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.

Is there a config value to disable this behaviour? This needs to be addressed and fixed at the linux level, not in any user binary (and that includes Enigma).

http://www.streamboa...trunk/config.sh

default: CONFIG_CLOCKFIX=y

All oscam builds with clockfix have "Clockfix with realtime clock: yes" (you can check in webif -> files -> oscam-version)

To have it removed: this can only be done at compiletime... so before compiling the oscam bin flip it to CONFIG_CLOCKFIX=n

Is it a unusual and dirty thing: yes, I agree but hey it works and fixes things (even on my setup hence the default on)

If anyone can improve the oscam code the right way just do it. But be warned you will enter a fucing rabbithole.

BTW I'm more than happy to commit a sound and clean solution to fix this properly in oscam but only problem is it needs to be made first...

Till then the second best option is in effect and all complains are ignored.

Ignore mode on again...

oscam-1.20-HPB-r732-EMU-r397-746-r11391

So you reverted back to begin 2017 version of emu patch to get it stable again.

What's the difference between a EMU version of oscam and the one without that EMU?

Read it here: https://github.com/oscam-emu/oscam-emu

From my point of view: emu patch contains all the code that endangers the legal status of the oscam project.

Using emupatch on top of oscam code is for sure illegal since you can watch pay tv with it without the need of a valid subscription.

Some would say Oscam it self is already illegal since you can watch pay tv with it using a solotion not supported and approved by the providers.

I would say I have a valid subscription so I can and want to watch the content I paid for. How I accomplish that it is my personal struggle.

If there are folks out there using oscam to watch without a valid subscription is their personal problem.

You cant forbid sales of crowbars either since some burglars use them.

Ten years ago oscam didn't work for my personal usage. After raising some tickets no one seems interested in fixing.

So I started changing things myself and contribute them to oscam. Now it works fine for my usage.

So if it doesnt work ok for your usage:improve the code and contribute!

De providers zijn overigens *niet* degenen die afdwingen.

Het zijn echt de zenders en content leveranciers zelf die hoge beveiligingseisen stellen aan de distributie van hun "kostbare" content.

Kan een provider niet voorzien in bepaald veiligheidsniveau van distributie dan mogen ze de content of niet distribueren of tegen een aanzienlijk hogere prijs. 

De dwingelanden tref je dus niet door over te stappen naar een andere provider.

Die pak je alleen door massaal te bedanken voor hun zogenaamde premium content.

https://github.com/O...15e36f09c997453

Wordt altijd met veel plezier gelezen hier

In zelfde bericht stond ook een opmerking over niet meer werken van smart wi en clone+ adapters....

Dus lijkt mij uitfasering van de seca layer op alle officiele ontvangers en omschakeling naar de nagra merlin layer zoals bv de M7 801 al deed.

Als de omschakeling van de officiële ontvangers lukt dan kunnen ze vervolgens met een druk op de knop direct alle cardservers en softcams op zwart zetten door de seca layer te deactiveren. Of alleen deactiveren voor bepaalde "premium" kanalen.

Enfin, koffiedik kijken voor iedereen. Maar hier zat ik aan te denken toen ik het bewuste emailje las

Well sure I can add support to oscam to output it to some kind of file but why not implement it in engima2 code? That way everyone can benefit from it, even the setups not

using oscam at all. Therefor I think enigma is a far better place to implement this.

The exact same data is used by oscam to fetch caid, provid and ecmpid.

But provid is not always communicated in pmt by the provider in that case oscam zero's it too.

this code is used in dvbapi to parse it: (I stripped away already some silly stuff you dont need)

void dvbapi_parse_descriptor(int32_t demux_id, uint32_t info_length, unsigned char *buffer)
{
    // int32_t ca_pmt_cmd_id = buffer[i + 5];
    uint32_t descriptor_length = 0;
    uint32_t j, u, k;
    
    if(info_length < 1)
        { return; }

    for(j = 0; j + 1 < info_length; j += descriptor_length + 2)
    {
        descriptor_length = buffer[j + 1];
        
        if(buffer[j] != 0x09) { continue; }
        
        if(demux[demux_id].ECMpidcount >= ECM_PIDS) { break; }

        int32_t descriptor_ca_system_id = b2i(2, buffer + j + 2);
        int32_t descriptor_ca_pid = b2i(2, buffer + j + 4)&0x1FFF;
        int32_t descriptor_ca_provider = 0;

        if(descriptor_ca_system_id >> 8 == 0x01)
        {
            for(u = 2; u < descriptor_length; u += 15)
            {
                descriptor_ca_pid = b2i(2, buffer + j + u + 2)&0x1FFF;
                descriptor_ca_provider = b2i(2, buffer + j + u + 4);
                dvbapi_add_ecmpid(demux_id, descriptor_ca_system_id, descriptor_ca_pid, descriptor_ca_provider);
            }
        }
        else
        {
            if(caid_is_viaccess(descriptor_ca_system_id) && descriptor_length == 0x0F && buffer[j + 12] == 0x14)
                { descriptor_ca_provider = b2i(3, buffer + j + 14) &0xFFFFF0; }

            if(caid_is_nagra(descriptor_ca_system_id) && descriptor_length == 0x07)
                { descriptor_ca_provider = b2i(2, buffer + j + 7); }
            
            if((descriptor_ca_system_id >> 8 == 0x4A || descriptor_ca_system_id == 0x2710) && descriptor_length > 0x04 )
                { descriptor_ca_provider = buffer[j + 6]; }

            dvbapi_add_ecmpid(demux_id, descriptor_ca_system_id, descriptor_ca_pid, descriptor_ca_provider);            
        }
    }

And even that is not correct.... I measured my boxes while they where in action.... this is with quad+ in init 4 mode, oscam killed:

aes-128-cbc      16496.25k    20222.17k    21363.80k    21673.98k    21738.84k

Gauw gaan leren dan zou ik zeggen want ook je laatste bijdrage smijt je weer met dingen daar gaan mij de rugharen van overeind staan.

Absoluut niet, is volledig officieel, je kunt zelfs nakijken dat hun certificering officieel is hier:

http://www.symantec....stomers#secTab2

Device manufacturer host -> "Impex-Sat GmbH & Co. KG"

En een keer overschrijven en daarna dan kun je alles: image updaten, rebooten... bedenk het maar!

Loopt bij mij al meer dan een week stabiel, ik durf het nog bouter te zeggen: reboot en opstarten gaat zelfs sneller