Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben

Immer aktuell - CW Cache Patch

Status
Für weitere Antworten geschlossen.
@OnkelAtze Die Last ist ordentlich, was für eine cachesize ist da zu der Zeit denn am Start? Ist die Last auch ohne Debug-Log so hoch?

Hier eine kurze Anleitung, wie man einen Backtrace erstellt, mit dem man die Ursache ermitteln kann.

Wenn ihr diesen dann postet, kann jemand evtl. was damit anfangen und die Ursache ausmachen/beheben.

Installiert euch "gdb"
Debian/Ubuntu und Derivate:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Baut eure OSCam und nehmt die oscam*.debug als binary (die größere!) und verwendet diese.

Erstellt euch eine Datei namens "run", im Ordner wo die OSCam-Binary liegt, mit folgendem Inhalt:

Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Ersetzt "/path-to-your-oscam-config/" mit dem entsprechenden Pfad zu eurem OSCam-Config-Ordner.
Weitere Startparameter können dahinter angehangen werden.

Startet nun OSCam:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Nun seht ihr die Ausgabe von startenen Threads usw.

Wenn OSCam nun mit einem segfault aussteigt erscheint etwas in der Art:

Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Und weitere Zeilen.

nun in der gdb-shell "bt" eingeben:

Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Die Zeilen in den letzten beiden Code-Blöcken sind die relevanten um sich der Sache annehmen zu können.
 
Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!
Cache Size mom: 3940
meist ~ 3000 - 5000

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!
Die OSCam lief normal, ohne Debug mit den Angaben wie gestern geschrieben.
Sofern ich cacheex_cw_check_for_push = 1 setze und dann speichern klicke (im User / CacheEx2) steigt die Last exorbitant an.

vG OA

Ohne die Funktion, mit meinen Parametern (siehe Spoiler -> Immer aktuell - CW Cache Patch) läuft alles perfekt.

An dieser Stelle nochmals vielen Dank für Deine tolle Arbeit.

vG OA
 
Edit! :
Da habe ich das localgenerated-flag feature mit dem tryfix des cx3-crash's kaputt gemacht.... Fix folgt dann bei Zeiten


Kleines Update mit nem Feature zum Service-spezifischem setzen der no_wait_time-Funktion (bekannt aus den User-Settings).
Praktisch wenn sich lokale Karten langweilen, oder aber von einer CAID nicht alles lokal vorhanden ist, sehr oft via Cache kommt und die anderen Services gerne ohne wait_time lokal bedient werden sollen.

Anwendung wie auch schon bei der 48bit-Thematik:

Dem Service das Flag "no_wait_time=1" mitgeben und gut ist.


Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Zudem inkl. Tryfix für crashes bei CacheEx3 bzgl localgenerated-flag

@OnkelAtze bei dir würde ich auf ein Lastproblem tippen, da die cacheex_cw_check_for_push durchaus was zu tun hat, mach doch mal ein backtrace, vllt sieht man da was.

Edit! :
Da habe ich das localgenerated-flag feature mit dem tryfix des cx3-crash's kaputt gemacht.... Fix folgt dann bei Zeiten
 
Zuletzt bearbeitet:
@w33dburner

Danke für den neuen Patch! Wurde noch etwas geändert?

Ich habe eben mit dem Patch eine neue OSCam (extra auch mit debug) gebaut, wollte aber erst "normal" testen & was soll ich sagen, bisher läuft die oscam völlig normal mit cacheex_cw_check_for_push = 1 gesetzt.

OSCamUser: 4.71 %System: 3.87 %Summary: 8.57 %
Cachesize: 4039 - also auch nicht mehr oder weniger als sonst

Er macht auch was er soll: 2020/04/17 17:49:14 6D6DF6D3 p (cacheex) push denied - cacheex_check_cw.counter: 2 > er->cw_count: 1

Nachdem ich mir den 512er Log angesehen, hier rein kopiert und auf die Statusseite zurückgeschalten habe, stieg die Last enorm an:

OSCamUser: 51.31 %System: 10.13 %Summary: 61.44 %

Zurück ins Log, auf 0 gesetzt:

OSCamUser: 6.79 %System: 3.81 %Summary: 10.60 %

Ich hatte bei den Test's zuvor auch immer den 512er Log beobachtet, um zu sehen ob die Funktion greift & diesen nicht wieder auf 0 zurückgesetzt.
(hätte mir auch früher einfallen können - ich weiß)

Nachtrag:
Schalte ich die Funktion (cacheex_cw_check_for_push = 1 ) aus und schaue mir den 512 Log an, steigt die Last zwar, aber nicht so extrem:
OSCamUser: 23.78 %System: 7.93 %Summary: 31.70 %

vG OA
 
Zuletzt bearbeitet:
Kann es sein das mit der Verison 9.1.1 keine localgenerated flags mehr im log kommen?
 
Ups, hab ich es kaputt gemacht? :D
Gucke es mir später an.
 
Setz das Flag dann Zuhause beim local Reader, mit dem Eintrag werden keine Flags gesetzt und das ist auch gut so :smile: wenn beide oscam gepatched sind wird das Flag weitergereicht
 
Zuletzt bearbeitet von einem Moderator:
Ok, ich habe daheim als "lokal Reader" HD+ in einer Vu+ Ultimo4K, diese hat keine CacheEx Verbindung zum Server, da ich mir "gedacht" habe, die meisten Zugriffe auf die Karte kommen eh vom VPS, somit reicht es wenn der dort generierte Cache weitergeleitet wird.

vG OA
 
Du könntest im Reader auf deinem VPS "localcards =" setzen. Dann wird der Proxy als lokaler Reader gehandhabt und somit sollte es wieder mit Flag versehen werden.
 
Ich glaube nicht das dann das Flag gesetzt wird, aber zu 100% weiß ich es auch nicht, soweit ich weiß setzt er das Flag nur wenn es kein Network Reader ist, und das bleibt es auch mit localcard = , somit sollte es nicht gesetzt werden, was auch so sein sollte, sonst kann jeder einen Network Reader Flaggen wo die Quelle verseucht ist mit schlechten Cache, damit wäre das ganze eher nutzlos
 
Zuletzt bearbeitet von einem Moderator:
Status
Für weitere Antworten geschlossen.
Zurück
Oben