[Sammelthread] Fehlerbehebungen für VDR 2.1.9

kls

Das ist nicht ein Fehler, eher ein feature request fuer die nächsten developer versionen nach vdr-2.2

Wenn ich beim abspielen von records die OK taste drücke, wird angezeigt:

Die actuelle Zeit wo ich mich im Record befinde und die Länge des records bzw. Restzeit des records.

Wenn der record aber mit schnitt Marken versehen ist, stimmt das nicht mit den tatsächlich verfügbaren Zeiten überein.
Zumindest die tatsächlich Länge des records (mit schnittmarken) oder die tatsächlich restzeit (mit schnittmarken) sollte dann angezeigt werden.
Natürlich voll configurierbar, damit der geneigte user das an seine Bedürfnisse anpassen kann

Das ist aber eher eine minor feature request, falls Du und die user das für sinnvoll erachten

Cheers

/bin/joerg

Zitat von hd.brummy

Zumindest die tatsächlich Länge des records (mit schnittmarken) oder die tatsächlich restzeit (mit schnittmarken) sollte dann angezeigt werden.

Im SkinFlatPlus wird das schon so gemacht. Da wird auch angezeigt wie lange die Aufnahme geschnitten ist...

kls

Ich habe da wohl noch einen Fehler gefunden:

Wenn man jetzt mit den Tasten 1 oder 3 in einer Aufnahme ohne Marken springt und dabei länger auf den Tasten bleibt oder mehrfach kurz hintereinander in die gleiche Richtung springt, friert nach kurzer Zeit der vdr ein.

Das passiert nicht, wenn man mit Grün oder Gelb springt oder wenn die Aufnahme Marken hat.
Eine Fehlermeldung im Log erscheint nicht.

Nach der eingestellten Zeit schlägt dann der Watchdog zu:

Feb 07 13:44:49 home-05.home.de vdr[24922]: [24922] replay /Video/video0/Hulk/2015-02-01.17.57.110-0.rec
Feb 07 13:44:49 home-05.home.de vdr[24922]: [24922] loading /Video/video0/Hulk/2015-02-01.17.57.110-0.rec//marks
Feb 07 13:44:49 home-05.home.de vdr[24922]: [25025] resuming replay at index 76525 (0:51:01.00)
Feb 07 13:46:58 home-05.home.de vdr[24922]: [24922] PANIC: watchdog timer expired - exiting!

Die Datei marks hat in dem Fall 0 Byte:

-rw-r--r-- 1 root root 0 7. Feb 13:41 /Video/video0/Hulk/2015-02-01.17.57.110-0.rec//marks

Das passiert aber auch ganz ohne marks-Datei.

Getestet habe ich das mit vdr-2.1.8 + dvbhddevice + remote und folgenden Patches:
- vdr-2.1.8-2.1.9-pre-1.diff
- vdr-2.1.8-binaryskipadaptive.diff
- vdr-2.1.8-skipeditedmarks.diff

Ich hoffe, ich habe jetzt keinen wichtigen Patch übersehen.

Grüsse
kamel5

Ich kann das hier nachvollziehen.
Schau's mir gleich an.

Klaus

Erste Erkenntnis: er bleibt an diesem LOCK_THREAD hängen:

void cDvbPlayer::Goto(int Index, bool Still)
{
  if (index) {
     LOCK_THREAD;
     Empty();
     if (++Index <= 0)
        Index = 1; // not '0', to allow GetNextIFrame() below to work!

Momentan habe ich noch keine Idee, warum.
Falls jemandem was hierzu einfällt, bitte melden.

Klaus

Da hatte ich wohl beim Zusammenführen der cMarks-Listen von Menü und Player einen Deadlock eingebaut.
Der beiliegende Patch entfernt die cMutexLock wieder von den Stellen, wo sie eigentlich nicht nötig sind, weil die Liste ja nicht veränderrt wird (und der Player verändert sie sowieso nicht). Es wird jetzt nur noch dort gelockt, wo die Liste tatsächlich verändert wird.

kamel5: Vielen Dank für den Bug-Report! Das wäre ein saublöder Fehler gewesen, wäre der in die "stable" geraten...

Klaus

Ich weiss jetzt nicht, ob das in diesen Thread gehört, aber ich würde mir wünschen, dass vlt. in einer der nächsten Versionen der MainMenuHooks-. und der menuselection Patch in den VDR wandern würde.

Gibt es eventuell einen aktuellen "pre-2".diff für die 2.1.9? Der Überblick fällt abermals schwer

Damit wird CPU usage dramatic sinken, ist eingentlich kein fix sondern ein workarround für buggy dvb treibern (tevii S650 dvb-s2 usb)

Origing

http://skyboo.net/pub/driver-fix.diff

diff --git a/device.c b/device.c
index 9da5e7f..ededd0a 100644
--- a/device.c
+++ b/device.c
@@ -1756,6 +1756,7 @@ void cTSBuffer::Action(void)
      bool firstRead = true;
      cPoller Poller(f);
      while (Running()) {
+           cCondWait::SleepMs(1);
            if (firstRead || Poller.Poll(100)) {
               firstRead = false;
               int r = ringBuffer->Read(f);

Da sollten aber doch lieber die Treiber gefixt werden.

Klaus

Zitat von crow

Damit wird CPU usage dramatic sinken, ...

Ist denn bei Dir die CPU Load dramatisch hoch?

Ja ist es, mehr als 100% geht es
nicht. Mit dem onelinepatch läuft alles wieder gut.

@Klaus wollte nur melden, vielleicht
gibt es etwas in den VDR Code was das bei der buggy Treibern verursacht.

cTSBuffer::Action() macht ja an der Stelle einen Poll()-Aufruf. Ich vermute mal, daß bei den betroffenen Treibern das nicht richtig implementiert ist und sofort zurückkehrt. Mehr als Poll() zu machen kann VDR an dieser Stelle nicht wirklich. Jegliches "wait" ist in dem Zusammenhang immer ein Zeichen von "da stimmt was nicht"...

Klaus

Dann wird es so auch sein. Weiß nicht genau wem soll ich das für so alte dvb karte melden

2.1.9 ohne patch

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2871 vdr  20 0  2301M 316M 65620 S 57.3 21.1 3:36.83 /usr/bin/vdr
3108 vdr  20 0  2301M 316M 65620 R 38.1 21.1 0:49.75 device 1 receiv
3109 vdr  20 0  2301M 316M 65620 S 10.3 21.1 0:10.92 device 1 TS buf
2877 vdr  39 19 2301M 316M 65620 S 3.3  21.1 0:09.46 device 1 sectio
3188 crow 20 0  19176 3704 2952  R 1.4   0.2 0:00.87 htop

2.1.9 mit patch

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
6733 vdr  20 0  1996M 177M 66580 S 27.2 11.8 0:24.58 /usr/bin/vdr
6762 vdr  20 0  1996M 177M 66580 S 16.7 11.8 0:09.93 device 1 receiv
6759 vdr  20 0  1996M 177M 66580 S 3.8  11.8 0:03.18 vdr
6763 vdr  20 0  1996M 177M 66580 S 2.9  11.8 0:02.20 device 1 TS buf
6739 vdr  39 19 1996M 177M 66580 S 1.9  11.8 0:02.31 device 1 sectio
6755 crow 20 0  19180 3640 2880  R 1.4   0.2 0:01.10 htop

Mod.: Lesbar gemacht ...

Es ist Igor M. Liplianin. Den habe ich schon ein paar mal ein mail geschrieben, leider noch keiner antwort erhalten.

Zitat

Delivery to the following recipient failed permanently:
liplianin@me.by
Technical details of permanent failure:

DNS Error: Domain name not found

Die sollte noch funktioniern, aber da kommt auch keine Antwort zurück.

liplianin@tut.by