kurze Audio/Bild Aussetzer / Zusammenhang mit EPGD ?

wir müssen das analysieren, mit dem scraper hat das wie ich es sehe nix zu tun.

Ich meine auch das meine Last auf dem Server vdr/mysql seit dem Wechsel auf 2.0.6 in testing angestiegen ist, ist doch richtig ihr seit alle auf yavdr testing? - Kann aber genauso gut sein das wir was kaputt gemacht haben :o

Christian

Zitat von CKone

wir müssen das analysieren, mit dem scraper hat das wie ich es sehe nix zu tun.

Ich meine auch das meine Last auf dem Server vdr/mysql seit dem Wechsel auf 2.0.6 in testing angestiegen ist, ist doch richtig ihr seit alle auf yavdr testing? - Kann aber genauso gut sein das wir was kaputt gemacht haben :o

Christian

ich bin auf :
deb http://ppa.launchpad.net/yavdr/testing-vdr-dev/ubuntu precise main

Moin,
hier läuft alles auf einem Rechner mit yaVDR stable.

Eine kurzfristige Auslastung von 100% kann ich mit einem restart von epgd oder vdr reproduzieren.
So um 65% nimmt sich dabei mysql.

Servus,

auch bei mir läuft alles auf meinem VDR.
Hardware siehe Signatur.

Keinerlei Aussetzer, alles smooth

Markus

Zitat von Saman

Eine kurzfristige Auslastung von 100% kann ich mit einem restart von epgd oder vdr reproduzieren.
So um 65% nimmt sich dabei mysql.

das ist kein Problem, ich hab auf dem vdr gar keine Last und während des merge schießt es dann natürlich genauso hoch wie während des series Abgleichs mit eplists - das war aber immer so und ist kein Problem. Beim Start des vdr ist das auch klar wenn sich epg2vdr/scraper2vdr kurz auf den neuesten Stand bringen, die logauszüge sind aber aus dem Regelbetrieb.

Auf so potenter HW wie sie hier im Einsatz ist darf da gar nix zucken - wir müssen versuchen das zu reproduzieren, ich werfe später mal die mysql auf dem Testvdr an...

Christian

Hi,

Ich bin auch auf stable. Habe zwei DVB S Karten. Habe die Priorität in der conf Datei für mysqld mal auf -19 gesetzt anstatt 0, dadurch wurde es wesentlich besser.
Die Aufnahmen scrape ich überhaupt nicht und mische tvm und epgdata ohne die DVB eigenen.

Zitat von Imsadi

Die Aufnahmen scrape ich überhaupt nicht...

Aufnahmen spielen hier keine Rolle.

Zitat von Imsadi

...und mische tvm und epgdata ohne die DVB eigenen.

interessant, würde mich sehr interessieren wie du das hinbekommst

Also das ist natürlich Blödsinn, gemischt wird DVB gegen Extern, im multimerge DVB gegen 2x Extern

Christian

Zitat von CKone

merkwürdig in jedem Fall das sich nur User aus yavdr melden...

Ich nutze KEIN yavdr, baue meine Pakete selbst.

Wie ich bereits in diesem Thread geschrieben habe, habe ich auch das Problem mit den Rucklern.
Wenn ich scraper2vdr in der order.conf mit '-' abschalte und den VDR neu starte (nur über upstart, kein Reboot) sind die Ruckler definitiv weg. Wenn ich das Plugin wieder einschalte und den VDR neu starte (upstart) sind sie wieder da.

EPGBugfixLevel = 3
EPGLanguages = 
EPGLinger = 0
EPGScanTimeout = 5

Hardware siehe Signatur.

ca. 150 Aufnahmen
VDR und epgd auf dem selben Rechner
nutze nur TVM, kein epgdata
vor den Aussetzern geht die CPU auf 100%
nach den Aussetzern steht im Log: epgd: 767 DVB pending, mergeepg done after 4.400 seconds

hth
Guido

Zitat von goldbär

nach den Aussetzern steht im Log: epgd: 767 DVB pending, mergeepg done after 4.400 seconds

und die Aussetzer sind dann vermutlich innerhalb des 4.4s intervalls?

Es kann natürlich sein das gerade auf Systemen auf denen der vdr Server nicht 24*7 läuft neben dem kontinuierlichen merge auch der scraper verstärkt parallel mitarbeitet, das würde auch erklären warum es hauptsächlich bei Usern mit einem allinone System auftritt... - müssten wir überlegen -konfigurierbar- auf solchen Systemen das merge für die Dauer des scrapens anzuhalten...

Christian

Hallo zusammen,
also ich habe auh gelegentlich Aussetzer, allerdings habe ich das bis lang noch nicht weiter verfolgt und ich meine auch, das die schon vor dem scraper da waren.
Könnt ihr die Aussetzer irgendwie reproduzieren? Bei mir treten die nämlich sehr sporadisch (vllt. 1mal am Abend) auf.

Zitat von CKone

und die Aussetzer sind dann vermutlich innerhalb des 4.4s intervalls?

ja, genau

Zitat von BooStar

und ich meine auch, das die schon vor dem scraper da waren.
Könnt ihr die Aussetzer irgendwie reproduzieren?

Habe ich oben beschrieben

Der scraper sollte auf alle Fälle mit niedrigerer Priorität laufen, evtl. auch mal über IOThrottle nachdenken:
https://github.com/flensrocker…blob/master/thread.h#L163

Lars.

Zitat von mini73

Der scraper sollte auf alle Fälle mit niedrigerer Priorität laufen, evtl. auch mal über IOThrottle nachdenken:
https://github.com/flensrocker…blob/master/thread.h#L163

Lars.

ja oder so...

ich hatte auch nach meinem letzten Beitrag überlegt lieber zu mergen und stattdessen den scraper zu benachteiligen

Christian

Moin,

ich denke auch dass das die Lösung wäre. scraper2vdr und epg2vdr sollten im Betrieb nicht parallel auf die DB zugreifen. Beim Starten sollte das kein Problem sein, aber im laufenden Betrieb sollten wir das synchronisieren. Laufen die Plugins parallel, ist das wohl in einigen Konstellationen "too much".

Ciao Louis

Zitat von louis

scraper2vdr und epg2vdr sollten im Betrieb nicht parallel auf die DB zugreifen

das merge kommt ja aus dem epgd wie der scraper, der epg2vdr schreibt dazu die DVB Events und alle rödeln teilweise auf der selben DB Tabelle schreibend, scraper2vdr greift ja nur lesend zu das tut nicht so weh.

Zitat von louis

Laufen die Plugins parallel, ist das wohl in einigen Konstellationen "too much".

ja wir halten ja selber schon den epghandler während des merge an, damit der nicht parallel auf der DB rumschreibt.

Frage wäre kannst du den scraper alle paar Minuten kurz anhalten - wenn das mal lange dauert sicher besser als ein oder zwei Stunden den merge zu stoppen? - Oder aber den scraper langsam im Hintergrund vor sich hin scrapen lassen...

Christian

Zitat von CKone

ja wir halten ja selber schon den epghandler während des merge an, damit der nicht parallel auf der DB rumschreibt.

Frage wäre kannst du den scraper alle paar Minuten kurz anhalten - wenn das mal lange dauert sicher besser als ein oder zwei Stunden den merge zu stoppen? - Oder aber den scraper langsam im Hintergrund vor sich hin scrapen lassen...

Christian

Man müsste halt genau wissen, was da "too much" ist. Der Scraper im epgd läuft ja immer nur, wenn in der DB neue zu scrapende Einträge sind. Und die sind nur da, wenn neue Daten vom tvm oder sonstwoher kamen. scraper2vdr läuft dagegen periodisch und prüft auf neue Aufnahmen und neue gescrapte Events in der DB.

Ich denke, das beste wäre es, wir bauen erst mal noch ein bisschen mehr Debugausgaben ein, damit wir sehen können, in welcher Konstellation es zu der hohen Last kommt.

Ciao Louis