OSCAM restart zodra ratelimitecm wordt geraakt

[RempageR1]

Goedemiddag,

 

Nadat ik al een aardige tijd problemen had met het spontaan restarten van OSCAM ben ik eens op zoek gegaan waar dit in zat:

- Andere image geprobeert op mijn VUPlus box, (van VTI naar BH)

- Andere site voor OSCAM binaries

- Minimale config

- Andere VUPlus box.

 

Uiteindelijk bleek dat allemaal niet veel uit te maken. Na nog wat graven kwam ik er achter dat OSCAM voornamelijk crashte als ik zelf veel zenders keek (in de woonkamer en client op de slaapkamer).

 

Bij normale instellingen voor mijn kaart:

--------

ratelimitecm = 4

ratelimitseconds = 15

--------

 

Gaat het dus fout als ik zelf picture in picture draai, een zender opneem en er boven ook TV wordt gekeken.

 

Reproduceren kan met deze minimale config:

--------

oscam.conf

[dvbapi]

enabled = 1

au = 1

pmt_mode = 4

boxtype = dreambox

[webif]

httpport = 8001

httprefresh = 5

httphideidleclients = 1

httpallowed = 192.168.0.1-192.168.0.255

oscam.server

[reader]

label = cardreader

protocol = internal

device = /dev/sci0

detect = cd

mhz = 500

group = 1

emmcache = 1,3,2

ratelimitecm = 1

ratelimitseconds = 15

--------

 

Ik weet dat ratelimitecm = 1 niet echt een normale setting is, maar het triggered wel snel de ratelimitecm code. Als je nu picture in picture gebruikt op 1 box (dus niet eens clients) crashed OSCAM.

 

Kan iemand hier alsjeblieft naar kijken? Via bugtracker (http://www.streamboa...cam/ticket/3091) krijg ik geen reactie. Dit probleem zit zeker in rev. 8118, 8191 en zeker niet in 7488. Deze laatste versie draai ik nu en die is wel stabiel.

 

Bedankt!

3 februari 2013 aangepast door RempageR1

[alias haha]

Zet ratelimitseconds = 15 maar eens op ratelimitseconds = 10

[RempageR1]

Dan zal hij misschien iets minder snel tegen de ratelimit aanlopen maar dat is toch niet de oplossing? OSCAM zou niet moeten crashen van een setting als deze.

[RempageR1]

Na wat proberen ben ik er achter gekomen dat het fout gaat op 'reader->rlecmh[foundspace].last = time(NULL);' in oscam-chk.c, zie mijn patch.

 

zie: patch.txt

 

Na deze regel te remarken gaat het goed zonder cooldown. Met cooldown ben ik nu aan het testen.

 

Is er iemand die hier verder naar kan kijken? Die regel zal vast wel ergens goed voor zijn.

 

Bedankt!

3 februari 2013 aangepast door RempageR1

[theparasol]

Als je time(NULL); vervangt door time((time_t *) 0);

helpt dat?

[RempageR1]

Als je time(NULL); vervangt door time((time_t *) 0);

helpt dat?

 

Helaas, hetzelfde probleem dan.

[theparasol]

Ik verwacht ergens dat die vu doos niet de correcte tijd heeft. Kun je dat controleren?

[RempageR1]

Ik verwacht ergens dat die vu doos niet de correcte tijd heeft. Kun je dat controleren?

 

--

root@bm750:~# date

Mon Feb 4 09:07:29 CET 2013

--

 

Dat was dus 1 minuut geleden. Mocht je meer nodig hebben hoor ik het graag.

[RempageR1]

Na nog wat google kwam ik deze tegen:

http://stackoverflow...l-fail-on-linux

 

De call zou dus kunnen falen als een embedded device geen real-time clock heeft. Aangezien mijn VUPlus altijd opstart met epoch tijd (1970) zou hij inderdaad wel eens die real-time clock kunnen missen....

 

Voor de volledigheid: Zodra een zender wordt bekeken wordt de tijd aangepast na de juiste, OSCam crashed ook als de box al een tijd up is en dus de goede tijd heeft.

4 februari 2013 aangepast door RempageR1

[RempageR1]

Dit gaat bijvoorbeeld al mis:

-----------

time_t actualtime = time(NULL);

cs_debug_mask(D_TRACE, actualtime );

-----------

 

Het is niet het updaten van actualtime, maar het opvragen ervan wat de crash veroorzaakt. Andere tellers werken wel gewoon, zoals de uptime van OSCAM en hoe lang clients online zijn. Is het mogelijk om de ratelimit code zo aan te passen als dat daar ook gebruikt is?

 

Bedankt.

[muppet]

Ik lees al een tijdje mee maar waar kan ik het bovenstaande vinden ? Vind het best intresant werk zelf ook met oscam

[RempageR1]

Zie http://www.sat4all.com/forums/topic/329610-oscam-compileren-met-de-simplebuild-van-gorgone/

[RempageR1]

Deze patch.txt lijkt het probleem te fixen. Er wordt een berekening gedaan als: actualtime - reader->rlecmh[h].last en aangezien de actualtime in time_t format is was dat ook voor de reader->rlecmh[h].last nodig zo lijkt.

 

Hiermee heb ik geen crashes meer en zou de code toch nog goed moeten werken (voor zover ik het snap).

[RempageR1]

Te vroeg gejuicht, weer gecrashed..... de 1e patch werkt wel alhoewel dat dus iets van de code remarked.