41 replies to this topic

[WanWizard]

libcrypto heeft libssl nodig, ja.

[Sagitarius †]

Binary portability is niet eenvoudig onder linux, en de meeste mensen vergeten daar over na te denken.

 

Daarom zeggen we ook dat je niet zelf moet gaan zitten pielen, maar gewoon de versie uit de feed moet gebruiken. En als je dat niet wilt, gewoon bouwen vanuit onze bouwomgeving via bitbake, dan heb je ook altijd een binary die werkt.

 

Voor zover ik weet gebruikt Oscam geen SSL. maar libssl bevat ook allerlei encoding / encrypting functies waar ook libcrypto van gebruik maakt.

Bedankt Wanwizard voor je uitleg, het zou idd handiger zijn jullie binary te gebruiken, ware het niet dat bepaalde opties die bij jullie uitstaan.

En ik geen zin heb steeds de discussie aan te moeten gaan waarom ik bepaalde opties (clockfix smargo enz) wel graag aan zou willen hebben of het nut daarvan uit te moeten leggen.

En de belangrijkste reden dat ik ze zelf bouw is omdat zo is gebleken mijn binarys gewoon merkbaar sneller zijn en compacter van formaat zijn.

Verder schrijf je dat Oscam geen SSL zou gebruiken, maar waarom staat die dan wel aan in al de Pli binarys.  Je maakte daar laatst nog een opmerking over dat in mijn binary SSL uit stond en bij Pli aan.

Edited by Sagitarius, 1 February 2021 - 16:04.

[40H3X]

Afgezien van het antwoord van WanWizard en het geen SB support board is, al eens een s3 update uitgevoerd?

[WanWizard]

Bedankt Wanwizard voor je uitleg, het zou idd handiger zijn jullie binary te gebruiken, ware het niet dat bepaalde opties die bij jullie uitstaan.

En ik geen zin heb steeds de discussie aan te moeten gaan waarom ik bepaalde opties (clockfix smargo enz) wel graag aan zou willen hebben of het nut daarvan uit te moeten leggen.

 

Dat hoef je ook helemaal niet uit te leggen, vriendelijk vragen is genoeg hoor. Als er geen moverende redenen zijn honoreren we dat gewoon (die waren er voor clockfix wel).

 

clockfix staat in develop al weer aan (nu we ntp in de image hebben), en smargo heeft volgens mij nooit uit gestaan, anders zou mijn triple het ook niet doen?

 

En de belangrijkste reden dat ik ze zelf bouw is omdat zo is gebleken mijn binarys gewoon merkbaar sneller zijn en compacter van formaat zijn.

 

Knap. Kleiner kan best, dat is een kwestie van compile opties. Kleiner is niet altijd beter, zeker als de code niet 100% is, dan is een verkeerde optimalisatie gauw gemaakt. Sneller is helemaal knap, chapeaux hoor.

 

Verder schrijf je dat Oscam geen SSL zou gebruiken, maar waarom staat die dan wel aan in al de Pli binarys.  Je maakte daar laatst nog een opmerking over dat in mijn binary SSL uit stond en bij Pli aan.

 

Wij bouwen met de default makefile van oscam, dus als het daar aan staat, staat het bij ons ook aan. Vraag me niet waarom, ik ben geen code specialist.




 

[Sagitarius †]

Afgezien van het antwoord van WanWizard en het geen SB support board is, al eens een s3 update uitgevoerd?

Jazeker, bij iedere start word de boel geupdate zit nu al op versie 313,

 

    _________________
   /   _____/\_____  \   ===============
   \_____  \   _(__  <   Ver. 313 -NEXT-
   /        \ /       \  ===============
  /_______  //______  /  by gorgone 2020
          \/        \/   ===============

root@debian10:/opt/s3#

 

En de laatste versie toolchain voor de solo4k ga ik na mijn aanpassing niet updaten natuurlijk.

[Sagitarius †]

 

Bedankt Wanwizard voor je uitleg, het zou idd handiger zijn jullie binary te gebruiken, ware het niet dat bepaalde opties die bij jullie uitstaan.

En ik geen zin heb steeds de discussie aan te moeten gaan waarom ik bepaalde opties (clockfix smargo enz) wel graag aan zou willen hebben of het nut daarvan uit te moeten leggen.

 

Dat hoef je ook helemaal niet uit te leggen, vriendelijk vragen is genoeg hoor. Als er geen moverende redenen zijn honoreren we dat gewoon (die waren er voor clockfix wel).

 

clockfix staat in develop al weer aan (nu we ntp in de image hebben), en smargo heeft volgens mij nooit uit gestaan, anders zou mijn triple het ook niet doen?

 

En de belangrijkste reden dat ik ze zelf bouw is omdat zo is gebleken mijn binarys gewoon merkbaar sneller zijn en compacter van formaat zijn.

 

Knap. Kleiner kan best, dat is een kwestie van compile opties. Kleiner is niet altijd beter, zeker als de code niet 100% is, dan is een verkeerde optimalisatie gauw gemaakt. Sneller is helemaal knap, chapeaux hoor.

 

Verder schrijf je dat Oscam geen SSL zou gebruiken, maar waarom staat die dan wel aan in al de Pli binarys.  Je maakte daar laatst nog een opmerking over dat in mijn binary SSL uit stond en bij Pli aan.

 

Wij bouwen met de default makefile van oscam, dus als het daar aan staat, staat het bij ons ook aan. Vraag me niet waarom, ik ben geen code specialist.




 

 

Kijk dat bedoel ik nu met die discussies en uitleg te moeten geven, ik wil het zelf kunnen bepalen, maar toch bedankt voor je vast goed bedoelde adviezen....

Edited by Sagitarius, 1 February 2021 - 18:17.

[mimisiku]

I.d.d. dezelfde versie die ik ook gebruik. Afgelopen weekend gebruikt om diverse boxen van de lastste OScam versies te voorzien.. Zelfs de oeroude DM500HD testbak van de laatste versie voorzien.... Ik bouw hem altijd met Smargo en Stinger ondersteuning...

[Sagitarius †]

Maar vast niet voor Pli8.0  Oh nee die gebruik je zelf niet hé alleen voor je klanten

Edited by Sagitarius, 1 February 2021 - 18:19.

[mimisiku]

Nee, (nog) niet voor OpenPli 8.0... Moet daar nu iedere keer over gesneerd worden? Dat ik OpenPli niet gebruik wil nog niet zeggen dat ik het anderen niet gun!

[WanWizard]

Kijk dat bedoel ik nu met die discussies en uitleg te moeten geven, ik wil het zelf kunnen bepalen, maar toch bedankt voor je vast goed bedoelde adviezen....

 

Er is toch niemand je om discussie en uitleg vraagt? Als jij zegt "de smargo reader staat uit, kan die aan?", dan zeg ik "goed joh, zo gebeurd". Geen discussie, geen uitleg mogeljk.

 

Eigenwijs zijn is je goed recht . Maar ook dat kan gewoon met een bitbake build. En dan heb je een binary die wel gewoon altijd werkt. En daar was het om begonnen.
 

[catastrofus]

Yep, daar moet uiteraard iedere keer over "gesneerd" worden naar jou als absolute openpli hater en ultieme vix lover (EN ALLE ANDERE IMAGES ZIJN HELEMAAL RUK) hier op dit forum.

Wat jij anderen gunt gaat ons niet aan. Sterker nog, ik wil het niet weten...

 

 

Nee, (nog) niet voor OpenPli 8.0... Moet daar nu iedere keer over gesneerd worden? Dat ik OpenPli niet gebruik wil nog niet zeggen dat ik het anderen niet gun!

Edited by catastrofus, 1 February 2021 - 20:43.

[mimisiku]

Waarom reageer je er dan op?
En als je probeert te quoten... Het is VTi en geen OpenVIX...

[catastrofus]

Lekker belangrijk.

[mimisiku]

Tsja, wat wil je als Intrigant.. Je moet wat.....

[Sagitarius †]

Er is toch niemand je om discussie en uitleg vraagt? Als jij zegt "de smargo reader staat uit, kan die aan?", dan zeg ik "goed joh, zo gebeurd". Geen discussie, geen uitleg mogeljk.

 

Eigenwijs zijn is je goed recht . Maar ook dat kan gewoon met een bitbake build. En dan heb je een binary die wel gewoon altijd werkt. En daar was het om begonnen.
 

 

Nee maar om commentaar ook niet, lekkere vent ben je toch....  Dan kun je mijn vraag misschien wel beantwoorden, wat is een bitbrake en hoe doe ik dat, en kan ik dan alle opties kiezen die ik wil en de binary comprimeren.

Edited by Sagitarius, 1 February 2021 - 20:56.

[WanWizard]

bitbake is de open embedded build toolset.

 

Als je daar serieus in geinteresseerd bent, dan wil je daar best wel mee helpen. De basis staat hier: https://wiki.openpli..._your_own_build.

 

Nu gaat dit uit van het bouwen van een hele image, als dat werkt, kan ik je wel uitleggen hoe je individuele ipk's bouwt,en hoe je een build recipe moet overriden.

[Sagitarius †]

Dan hou ik het toch maar bij Simplebuild.  Maar toch bedankt voor je hulp.

[theparasol]

Als het testen met de develop release geen issues oplevert gaat dan die clockfix ook weer aangezet worden voor openpli 8 release builds?

[WanWizard]

Yes.

[Rigo]

Het is algemeen bekend dat een echte cccam versie zie verslikt in ecms die langer zijn dan 255 bytes.... en laat nu net op de transponders van canaldigitaal viaccess ecms zitten met dit euvel. Hierdoor loopt cccam telkens een beetje vast totdat het zelfs kan crashen en het verstoort ook eea in oscam dingen die eraan hangen....

Hmm, kan dat de reden zijn dat ik elke maand mijn Focussat kaart even in de Conax module moet steken om weer te kunnen kijken ? (Focussat is een broertje van TV Vlaanderen en Canal Digitaal)

En verder loopt CCcam (ik denk 2.3.2 op alle receivers) af en toe wel vast, op de server of op de clients.

Misschien toch eens Oscam proberen, ook al word ik depressief als ik de configuratie tracht te begrijpen.