4250 replies to this topic

[HPPli]

Inderdaad, ik heb camd35 connecties tussen m'n VU+DUO Server en een tweetal VU+DUO's met Oscam als client.
Werkt ongeloofelijk soepel. Niks mis mee (met versie 6491 en alles zonder oscam.dvbapi)
@theparasol: Zal morgen de cmd08 is uitschakelen en de verschillen testen tussen versie 6491 en 6500, nu wordt er driftig gekeken en staan er recordings op stapel voor deze avond.

[Erik Slagter]

Normaal zou je cmd08 niet moeten hoeven uitschakelen...

[HPPli]

Normaal zou je cmd08 niet moeten hoeven uitschakelen...

Begrijp ik ook en doe ik ook niet, alleen @theparasol vroeg even naar de resultaten c.q. verschillen.
En ................ ik help graag een stukje wat ik binnen mijn ratio kan "behappen" , wordt Oscam allen maar beter van (door @theparasol).
Per slot van rekening is het @theparasol die inmiddels Oscam als softcam beter laat presteren dan CCCam !
Als je ziet hoe we inmiddels perfect de CanaalDigitaal problematiek (limit 4x srvids) kunnen omzeilen zonder enig probleem !
Ben al lange tijd fan van de softcam Oscam en zijn (sinds 6460) perfecte handling van vele providers in zowel Server - als Client-mode.

[frissie]

Een warning hoeft niet per sé ernstig te zijn. Alleen deze kunnen in principe wel een segfault veroorzaken (kleine kans).

Snap ik, maar als alle voorgaande versies prima compileren, en na 6495 deze warning geven ...
Ik maak even een pas op de plaats.

Edited by frissie, 10 March 2012 - 23:35.

[Black Tiger]

Ik ben er in elk geval doodzien van geworden. Het mag toch niet zo zijn dat Oscam raar gaat doen als je dat keepconnected op 0 hebt staan.
Hoe dan ook kreeg ik het met de 6499 nog voor elkaar om de client te laten inloggen, kreeg beeld maar nar korte tijd kon de client machine wel nog de kaart zien en was hij nog connected, maar beeld ho maar. Om nog maar niet te spreken van die spontane crashes met onregelmatige tussenpozes van een aantal uren. Ook gebruikte Oscam weer een stuk meer cpu tijd (tussen de 25 en 50% gemiddeld).
Dus ik heb de hele handel op de ET9000 teruggezet naar Oscam 6480 en meteen daarna draaide alles weer perfekt, ook weer weinig cputijd etc.
Voorlopig blijft die dus fijn draaien en wordt er alleen nog geupgrade als het perse nodig is voor het een of ander.

[Black Tiger]

Nu heb ik al op 2 Fedora 14 32-bits machines oscam gewoon zelf gecompileerd, maar op de derde gaat het mis.
De cmake -DWEBIF=1 gaat goed. Maar als je dan make doet, gebeurt er het volgende:

[ 5%] Building C object CMakeFiles/csmodules.dir/module-camd35.o
/usr/local/src/oscam-svn/module-camd35.c: In function ‘camd35_cache_push_send_own_id’:
/usr/local/src/oscam-svn/module-camd35.c:413:2: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/local/src/oscam-svn/module-camd35.c: In function ‘camd35_cache_push_receive_remote_id’:
/usr/local/src/oscam-svn/module-camd35.c:437:2: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/local/src/oscam-svn/module-camd35.c: In function ‘camd35_cache_push_chk’:
/usr/local/src/oscam-svn/module-camd35.c:487:2: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/local/src/oscam-svn/module-camd35.c: In function ‘camd35_cache_push_in’:
/usr/local/src/oscam-svn/module-camd35.c:628:2: warning: dereferencing type-punned pointer will break strict-aliasing rules

Ik heb hier en daar wel iets erover gezien in de tickets en ook fixed, maar niet hoe het gefixed is.
Iemand een idee hoe dit op te lossen is? Het is maar een waarschuwing, maar het blijft raar, waarom op deze fedora 14 wel en op de andere twee niet?

[Roymar]

sorry verkeerde draadje

Edited by Roymar, 11 March 2012 - 09:47.

[theparasol]

requestmode 1:

en rev 6503: emm updates voor CDS NL weer defect. Corsair heeft nu voor de derde keer mijn fix eruit gesloopt. Die gast snapt werkelijk geen ruk van simulcrypt.
Check als de ecmpid gelijk is en verwijder alle andere demuxers... Houden we over 1817:mediaguard3 ecmpid en 0100:mediaguard3 ecmpid.
Verwijderen van filterdemuxers: naast ecmtype ook opdracht om de emmtype filterdemuxers te droppen.
En hup daar gaat de emm filter want met 0100:seca2 ecmpid dropped ook de emmfilter van 0100:mediaguard 3.

Ik ga die code fixen als ik tijd heb en documenteren in de source. Wellicht dat hij het dan ook eindelijk snapt dat er nog iets anders bestaat dan 1702 en 1833

Edited by theparasol, 11 March 2012 - 12:52.

[mika-nl]

requestmode 1:

en rev 6503: emm updates voor CDS NL weer defect. Corsair heeft nu voor de derde keer mijn fix eruit gesloopt. Die gast snapt werkelijk geen ruk van simulcrypt.
Check als de ecmpid gelijk is en verwijder alle andere demuxers... Houden we over 1817:mediaguard3 ecmpid en 0100:mediaguard3 ecmpid.
Verwijderen van filterdemuxers: naast ecmtype ook opdracht om de emmtype filterdemuxers te droppen.
En hup daar gaat de emm filter want met 0100:seca2 ecmpid dropped ook de emmfilter van 0100:mediaguard 3.

Ik ga die code fixen als ik tijd heb en documenteren in de source. Wellicht dat hij het dan ook eindelijk snapt dat er nog iets anders bestaat dan 1702 en 1833

Haha, goeie gast . Kan je hem dat niet in een PM uitleggen ?
Maar je idee in de source aangeven is misschien wel slim voor de volgende die er aan wil gaan sleutelen.

Wacht dan nog maar even af met updaten, had ik voor vandaag gepland
MiKa

[Erik Slagter]

en rev 6503: emm updates voor CDS NL weer defect. Corsair heeft nu voor de derde keer mijn fix eruit gesloopt. Die gast snapt werkelijk geen ruk van simulcrypt.

Ik denk dat het subtiel anders ligt In de eerste plaats zie je simulcrypt bijna overal, het betekent alleen maar dat er meerdere ecm pids zijn. De truuk die M7 uithaalt is gewoon krom, daar is geen naam voor. Verder denk ik dat Corsair voor "zijn" caid's precies hetzelfde over jouw aanpassingen denkt Jullie hebben kennelijk tegengestelde belangen. Vandaar dat allerlei rare code die het voor ons sloopt maar telkens nooit eens verwijderd wordt. Dat wordt een uitdaging!

[HPPli]

requestmode 1:

en rev 6503: emm updates voor CDS NL weer defect. Corsair heeft nu voor de derde keer mijn fix eruit gesloopt. Die gast snapt werkelijk geen ruk van simulcrypt.
Check als de ecmpid gelijk is en verwijder alle andere demuxers... Houden we over 1817:mediaguard3 ecmpid en 0100:mediaguard3 ecmpid.
Verwijderen van filterdemuxers: naast ecmtype ook opdracht om de emmtype filterdemuxers te droppen.
En hup daar gaat de emm filter want met 0100:seca2 ecmpid dropped ook de emmfilter van 0100:mediaguard 3.

Ik ga die code fixen als ik tijd heb en documenteren in de source. Wellicht dat hij het dan ook eindelijk snapt dat er nog iets anders bestaat dan 1702 en 1833

Prima, met het noemen van de "minder goede" revisie 6503 weet je meteen waarover het gaat.

Overigens rev 6502 is puik, rev 6500 geeft problemen zoals gisteren vermeld.
@theparasol, wanneer kunnen we je commit testen (duurt wel lang, neen ........... grapje )

[Black Tiger]

@theparasol, wanneer kunnen we je commit testen (duurt wel lang, neen ........... grapje )

Nou... zolang Streamboard (en dus ook timeline etc.) niet bereikbaar is, kan het nog wel even gaan duren.

[HPPli]

@theparasol, wanneer kunnen we je commit testen (duurt wel lang, neen ........... grapje )

Nou... zolang Streamboard (en dus ook timeline etc.) niet bereikbaar is, kan het nog wel even gaan duren.

Geen punt, met versie 6491 heb je een uiterst stabiele Oscam aan boord en bovendien voorzien van alle goedwerkende bijdrages van @theparasol !!

[Black Tiger]

Nee dank je wel. Alle 649x versies crashen met onregelmatige tussenpozen spontaan om de zoveel uur op mijn ET9000.
Dus hier draait nu de 6480 en daar zitten ook de goedwerkende bijdragen van theparasol in, dus met die versie ben ik ook happy.

[EasySat]

Op mijn fedoraservertje draait versie 6499 helemaal zonder enig probleem. Zelfs mijn vrouw zeurt niet dat ze weer iets moet missen :-), daar heb ik toch veel last van gehad de laatste weken.

[HPPli]

Op mijn fedoraservertje draait versie 6499 helemaal zonder enig probleem. Zelfs mijn vrouw zeurt niet dat ze weer iets moet missen :-), daar heb ik toch veel last van gehad de laatste weken.

Logisch, een servertje geeft enkel "door" als een proxy. Ik heb inmiddels m'n inhouse NSLU2-server sinds vorige week ook al draaien op versie 6490 (probleemloos)

Het gaat pas spelen als de dvbapi-module moet gaan werken/denken.

[ni_hao]

zag dat in 6506 een fix zat voor caiway betekent dat de andere fixes (cd simulcrypt), welke corsair er uit gehaald heeft, ook weer in zitten?

[Black Tiger]

Logisch, een servertje geeft enkel "door" als een proxy

Zo logisch is dat niet. Bij een vriend draait een Fedora 14 met enorm veel problemen.
Lokale CD kaarten/lezers worden wel gezien maar niet aangesproken, m.u.v. zijn TVV en Sky Duitsland kaarten. Een externe reader die hij als test heeft naar zijn moeder, geeft wel CD gewoon door. Ongeacht de versies dus.

Wat ik me afvraag is of dat met die compile errors te maken heeft, een andere Fedora14 draaide wel zonder problemen, echt vreemd. En easysat heeft hem ook draaien zonder problemen.

Maarja, we vissen het wel een keer uit. Het is alleen raar dat ie eerst enorm mooi draaide en dan helemaal opeens na een upgrade gek deed.

M'n eigen ET9000 draait nog steeds retestabiel op de 6480 (in tegenstelling tot 649X en hoger) dus ik laat het effe fijn zo.

[frissie]

Wat ik me afvraag is of dat met die compile errors te maken heeft, een andere Fedora14 draaide wel zonder problemen, echt vreemd. En easysat heeft hem ook draaien zonder problemen.

Verschillende libc en/of libusb libary's ??
Zie hier eens na. Dit hielp bij mij op debian 6.0.3.

[rwijnberg]

Wat is volgens jullie nu de laatste best werkende oscam versie inclusief de fixes voor CD NL ?
Ik ben het gepruts van corsair namelijk spuugzat.

Edited by rwijnberg, 14 March 2012 - 10:53.