Posts by tag

Zuerst die "gute" Nachricht: Es liegt wahrscheinlich nicht an der Hardware, denn ich habe genau das gleiche Problem. Mein VDR stürzt an derselben Stelle ab. Der Backtrace deutet denke ich eher auf einen Bug beim Auslesen der EPG-Daten hin.

Ich habe mal versucht, das Problem zu debuggen. Anscheinend stürzt mein VDR immer ab, sobald der EPG/EIT/wieauchimmerdasheißt von Comedy Central/VIVA ausgelesen wird. Also habe ich diesen Kanal kurzerhand gelöscht. Seitdem läuft mein VDR wieder stabil. Wo der Fehler jetzt genau liegt, weiß ich aber nicht.

Quote from sinai

SELECT s.spielerid, a.name, b.vorname, spielerid, sum(spiele) AS summe FROM stats s LEFT JOIN spieler a ON (s.spielerid=a.id) LEFT JOIN spieler b ON (s.spielerid=b.id) GROUP BY spielerid ORDER BY summe DESC

Würde ein Join nicht genügen?

Hier ein Versuch, die Zeitleiste etwas übersichtlicher zu gestalten. Wenn man mit der Maus über eine Zeile fährt, wird diese farblich hervorgehoben. Zusätzlich werden für die hervorgehobene Sendung vertikale Linien eingeblendet, damit man die Anfangs- und Endzeiten verschiedener Sendungen leichter vergleichen kann.

Ein Patch für VDRAdmin-AM 3.6.7 ist angehängt, allerdings habe ich ihn nur mit Firefox und IE getestet.

Einige angesprochene Probleme/Fragen kommen mir bekannt vor. Die hatte ich bei reclist nämlich auch. (Das ist ein Programm, um Aufnahmen von einem oder mehreren VDRs aufzulisten, blablabla, genug Schleichwerbung. :unsch) Vielleicht taugen einige Ansätze ja für den VDR?

Zu Metadaten auf SSD oder Hauptplatte: Unschön, denn man muss die Kopien bzw. Symlinks synchron halten. In meinem Programm habe ich einfach die Aufnahmeliste beim Beenden abgespeichert und beim Starten wieder geladen. Dadurch ist die Aufnahmeliste immer sofort verfügbar, selbst wenn der Rechner mit den Aufnahmen mal nicht läuft.

Zum Mischen mehrerer Verzeichnisse und Anzeigen des Wurzelverzeichnisses: In meinem Programm kann ich wählen, ob die Aufnahmen nach Wurzelverzeichnis getrennt werden oder nicht. Ich habe die Erfahrung gemacht, dass ich oft beides nutze. Wenn ich einfach nur Aufnahmen anschauen will, dann ist mir egal, wo die liegen und gleichnamige Verzeichnisse sollten zusammengefasst werden. Wenn ich meine Aufnahmen verwalte, will ich das aber doch wissen. Diese Einstellung sollte man also besser dem Benutzer überlassen.

"... und welche von den Platten nehme ich mit in den Garten?" Hehe Ich hab mir für solche Fälle einen Aufnahmecache gebaut: Per Knopfdruck werden Aufnahmen komplett auf die lokale Platte kopiert. Beim Öffnen schaut mein Programm erst nach, ob die Aufnahme im Cache liegt. Falls ja, wird sie direkt geöffnet. Falls nein, wird der VDR per WoL gestartet und die Aufnahme danach geöffnet. Prima für unterwegs.

Für den VDR wäre sicherlich eine Anzeige interessant, wo eine Aufnahme gerade liegt: Ob lokal, auf irgendeinem (abgeschalteten?) VDR oder auf einer (welcher?) Archivplatte im Regal. Vielleicht will man aber auch einfach nur abspielbereite Aufnahmen sehen und alle anderen ausblenden?

Also "Spambot" würde ich auf jeden Fall drin lassen. Vielleicht noch "Tool-Entwickler" und "Fettnäpfchen-Treter"?

Den Speicher musst du spätestens im Destruktor freigeben und ggf. auch im operator=. Übrigens ist sizeof(char)==1 per Definition. Das kannst du dir aber alles sparen, wenn du einfach eine String-Klasse verwendest, z.B. std::string aus der STL oder cString vom VDR. In der tools.h findest du auch einige andere nützliche Sachen. Beispiel (ungetestet):

#include "tools.h"
...
class cArchive
{
...
    cString ArchivePath;
...
}
...
bool cArchive::CrawlDir(const char *Parent)
{
    cReadDir dir(Parent);
    while (const dirent *e = dir.Next()) {
        if (!(e->d_type & DT_DIR) || (e->d_type & DT_LNK) ||
            !strcmp(e->d_name, "..") || !strcmp(e->d_name, "."))
            continue;
        cString child = AddDirectory(Parent, e->d_name);
        if (!strcmp(e->d_name, UniqueFolder)) {
            ArchivePath = child;
            return true;
        } else if (CrawlDir(child)) {
            return true;
        }
    }
    return false;
}

Quote from GTRDRIVER

Wenn die nun eingeschaltet wird und der VDR startet ist der je nach LAN anbindung (1GB Netzwerk oder WLAN) zwischen 3 und 6 Minuten kaum ansprechbar - geht zwar - aber furchbar langsam - einfach weil in der Zeit das Aufnahme Verzeichnis eingelesen wird.

Vielleicht hilft es, leere Verzeichnisse zu löschen.

Quote from Keine_Ahnung

Genau, deswegen die Frage ob der VDR da irgendwas nicht optimal handhabt (für den Samba/NFS Fall). Eine Möglichkeit wäre z.B. das er die "info" R/W öffnet und Samba deswegen für jede Datei nen riesen Aufriss macht. Oder halt sowas in der Art?

Das dürfte einfach daran liefen, dass der Zugriff übers Netzwerk erfolgt. Wenn der Client eine Datei öffnet oder ein Verzeichnis durchsucht, muss er immer erst beim Server nachfragen und die Antwort abwarten. Selbst wenn eine Datei lokal im Cache liegt, muss der Client immer nochmal nachfragen, da die Datei auf dem Server inzwischen gelöscht worden sein könnte. Das mag nur wenige Millisekunden dauern, aber bei zigtausenden Zugriffen (wie beim Durchsuchen des kompletten Dateisystems) kommt da einiges zusammen. 3 Minuten sind durchaus realistisch, obwohl da sicherlich noch Raum für Verbesserung ist.

Quote from izeman

meine frage zielte genau auf eine moeglichkeit ab noch IRGENDEINE fehlermeldung zu gesicht zu bekommen aus der man was machen koennte. ich wuerde gerne wenigstens eine kernel panic oder sowas sehen.

Eine Möglichkeit wäre, syslog auf einen anderen Rechner umzuleiten, nur für den Fall, dass es eine eventuelle Fehlermeldung aus irgendwelchen Gründen nicht mehr auf die Festplatte geschafft hat.
Eine andere Möglichkeit wären magische Tastenkombinationen, um gezielt eine Kernel-Panic auszulösen und an ein Crash-Dump zu gelangen (habe ich selbst aber noch nicht ausprobiert).

RecList ist ein Programm, um VDR-Aufnahmen aufzulisten und abzuspielen. Es eignet sich insbesondere, um von einem Client (z.B. Laptop) auf Aufnahmen auf einem Server (z.B. VDR oder NAS) zuzugreifen.

• Die Aufnahmeliste wird lokal gespeichert und ist daher jederzeit verfügbar.
• Per Doppelklick kann ein beliebiger Video-Player gestartet werden (z.B. VLC).
• Der Server kann dabei automatisch geweckt werden (Wake on LAN).
• Alternativ können Aufnahmen in einem Cache zwischengespeichert und dann auch ohne Verbindung zum Server geöffnet werden.

[Blocked Image: http://www.student.informatik.tu-darmstadt.de/%7Eguentner/reclist-909.png]
reclist-994.jar

Voraussetzung ist ein installiertes Java Runtime Environment (JRE 7).
Achtung: Wer das Java-Browser-Plugin nicht unbedingt benötigt, sollte es vorsichtshalber abschalten!

Nach dem ersten Start müssen unter Extras/Einstellungen noch die Programme und Verzeichnisse eingetragen werden. RecList benötigt dabei Lesezugriff auf das VDR-Aufnahmeverzeichnis (z.B. über Samba oder NFS).

Die wichtigsten Änderungen seit der letzten Version:

• Wechsel zu Java 7
• Import und Export der Einstellungen
• Verbesserungen der Benutzeroberfläche (z.B. einfachere Cache-Konfiguration, Fortschrittsanzeige für Cache, usw.)

Kommentare können direkt hier oder auch im Entwicklungs-Thread abgegeben werden.

Neue Testversion: reclist-987.jar

Die wichtigsten Änderungen sind weitere Anpassungen an Java 7. (Ein Problem mit Java 6 ist zum Beispiel, dass sich nur äußerst umständlich feststellen lässt, warum Aufnahmen nicht geöffnet werden können: Existieren sie wirklich nicht und müssen aus der Aufnahmeliste entfernt werden? Oder ist bloß der Server gerade nicht erreichbar und die Aufnahmeliste bleibt unverändert? Mit Java 7 geht das etwas einfacher und auch zuverlässiger.)
Zusätzlich gibt es noch ein paar kleinere GUI-Verbesserungen hier und da, z.B. "zappelt" die gerade ausgewählte Aufnahme beim Aktualisieren nicht mehr so herum.

Wenn keine Klagen kommen, gibt es demnächst wieder eine stabile Version.

Quote from winni

Denn wenn %title% und/oder %subtitle% im Verzeichnis auftauchen, hängt epgsearch an das Verzeichnis nicht wie üblich nochmal %title%~%subtitle% an.

Im Prinzip funktioniert das prima, bis auf eine Kleinigkeit: Ein leerer %subtitle% wird nicht wie sonst durchs Datum ersetzt. Bei gut gepflegten EPG-Daten müsste man sich darüber ja keine Gedanken machen, aber ...

Es wäre auch schön, wenn man das für alle Serientimer auf einmal einstellen könnte. Geht das über epgsearchuservars.conf? Kann man irgendwo ein Standardverzeichnis für Serientimer vorgeben? Ich habe nur etwas für normale Timer gefunden. Also habe ich das kurzerhand direkt im Quelltext geändert: epgsearch.diff.txt Dadurch wird bei Serientimern grundsätzlich der Titel nach einer Klammer abgeschnitten. Für meine Bedürfnisse reicht das erstmal.

Eigentlich geht VDR recht sorgsam mit dem Cache um (siehe cUnbufferedFile im Quelltext; Stichwort posix_fadvise).
Als Ursache vermute ich eher einen Recording Hook oder Zugriffe aus dem Netzwerk.

Es wird mal wieder Zeit für eine neue Testversion: reclist-946.jar

Die wichtigsten Änderungen:

• Eine bessere Fortschrittsanzeige für die Cache-Aktualisierung. Die kann ja ziemlich lange dauern ...
• Eine neue Auswahlliste in den Cache-Einstellungen. Anstatt alle Titel einzeln einzutippen, kann man jetzt Häkchen setzen.
• Import und Export von Einstellungen. Es gab zwar schon vorher die Möglichkeit, im Programmverzeichnis eine default.xml abzulegen, die beim ersten Start importiert wurde, aber anwenderfreundlich war das nicht ... Jedenfalls gibt es jetzt in den Einstellungen zwei kleine Buttons für diesen Zweck.

Eine Sache, die mich noch beschäftigt, ist eine Datumsanzeige direkt im Baum. Ich hatte mir erst überlegt, noch eine zweite Spalte fürs Datum einzufügen. Problematisch wird es dann aber bei langen Aufnahmetiteln: Entweder macht man die erste Spalte so breit, dass die Titel alle reinpassen. Dann passt aber die Datumsspalte nicht mehr ins Fenster und es ist alles wieder so wie jetzt. Oder man lässt die erste Spalte so klein, dass das Datum immer sichtbar ist, aber dann sind die Titel abgeschnitten. Gefällt mir beides nicht besonders. Irgendwelche Vorschläge?

Quote from kls

- VFAT_MAX_FILENAME wird in timers.c verwendet, und zwar als Anzahl der UTF-8 Symbole, die der Filename maximal lang sein darf

Apropos: Unter VDR 1.6 gibt es das Problem, dass UTF-8-Sequenzen manchmal in der Mitte geteilt werden. Ist das unter 1.7 auch noch so? (Ich habe die Sache damals nicht weiter verfolgt, sondern kurzerhand VFAT_MAX_FILENAME und MAX_SUBTITLE_LENGTH auf 255 gesetzt und neu kompiliert. ;))

Quote from kls

- Unter Windows (VFAT?) ist anscheinend die maximale Länge des gesamten Pfadnamens (also Directories plus Filename) auf 255 Zeichen beschränkt. Zumindest hat das ein Versuch auf meinem Laptop mit Windows XP ergeben. Laut http://en.wikipedia.org/wiki/Long_filename sind das 255 UTF-16 Zeichen, daher wohl auch die Berechnung mit UTF-8 Symbolen anstatt Bytes in timers.c.

Es sind sogar 260. Das schließt den Laufwerksnamen (x:\) bzw. Freigabenamen (\\server\freigabe\) und das NUL am Ende mit ein. Was tatsächlich übrig bleibt, ist also vom Einzelfall abhängig und lässt sich nur schwer vorhersagen.

Quote from Keine_Ahnung

Ich fände es viel logischer wenn es statdessen einen Parameter --max_path <integer, default 255> (oder so in der Art benannt) gäbe mit der der Nutzer die Länge festlegen kann. Dann ist man von der aktuellen Windowsversion unabhängig, und der Mount Path auf der Windows Kiste könnte vom Nutzer auch nach Wunsch berücksichtigt werden.

Da stimme ich zu. Wobei ich den Standardwert deutlich niedriger setzen würde, auf 200 oder so. Das sollte in den meisten Fällen noch genug Platz für den Server- bzw. Freigabenamen lassen, und wer wirklich noch längere Verzeichnisnamen braucht, kann das immer noch ändern.

Quote from zochi

Da verstehe ich nicht auf was Du dich beziehst.

Ich meine die Partitionstabelle:

Quote from zochi

Code

Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1   *      0+   7394-   7394-  59392000   83  Linux
/dev/sda2     242679+ 243201-    522-   4191233    5  Extended
/dev/sda3       7394+ 242679- 235286- 1889930239   83  Linux
/dev/sda4          0       -       0          0    0  Empty
/dev/sda5     242679+ 243201-    522-   4191232   82  Linux swap / Solaris

Schau doch mal, wo sda2 (bzw. sda5) beginnt und sda3 endet. Ich wundere mich bloß ein bisschen, dass es überhaupt möglich ist, Partitionen "verkehrt herum" anzulegen. Ich hätte erwartet, dass die Reihenfolge der Partitionen in der Partitionstabelle mit der tatsächlichen Reihenfolge auf der Platte übereinstimmen muss, aber anscheinend muss sie das nicht.

Es spielt keine Rolle, ob oder wann fsck läuft. Bei XFS macht fsck sowieso nichts (man 8 fsck.xfs).

Der Write-Cache der Festplatte könnte aber tatsächlich das Problem sein. Stehen im syslog irgendwelche Meldungen bzgl. write barriers? Wenn die nicht funktionieren, musst du den Write-Cache wohl dauerhaft abschalten. Nur erklärt das leider auch nicht, warum das Dateisystem im laufenden Betrieb beschädigt wurde.

Vermutlich ist es unwichtig, aber ... Warum liegt sda2 hinter sda3?

Gibt es irgendwo sichtbare Schäden? Kratzer? Abgebrochene Bauteile? Aufgeblähte Kondensatoren? Geknickte oder beschädigte Kabel? Sitzen die Stecker richtig?
Am besten mal alles ausbauen/abziehen, was nicht unbedingt notwendig ist. Also nur mit CPU, 1x RAM und Power-Button starten (Grafik ist ja onboard). Sonst nichts anschließen. Naja, vielleicht noch den Speaker und ein paar LEDs. Aber sonst gar nichts. Auch nicht den Reset-Button.

reclist ist ein Programm, um den Inhalt eines VDR-Aufnahmeverzeichnisses aufzulisten. Per Mausklick kann direkt ein Video-Player gestartet werden (z.B. VLC).

[Blocked Image: http://www.student.informatik.tu-darmstadt.de/%7Eguentner/reclist-909.png]
reclist-909.jar

Voraussetzung ist ein installiertes Java Runtime Environment (JRE 6 oder höher). Dann einfach auf das *.jar doppelklicken. Nach dem ersten Start müssen unter Extras/Einstellungen noch die Programme und Verzeichnisse eingetragen werden.

Die wesentlichen Änderungen:

• Neue Aufnahmen können automatisch im Cache gespeichert werden. Dazu müssen zunächst die Titel der jeweiligen Serien in den Einstellungen eingetragen werden. Bei der nächsten Aktualisierung werden dann neue Aufnahmen automatisch zum Cache hinzugefügt.
• Bei Platzmangel werden Aufnahmen nicht mehr endgültig aus dem Cache entfernt, sondern nur vorübergehend, bis wieder genug Platz frei ist. Welche Aufnahmen "wichtig genug" sind und im Cache bleiben dürfen, hängt davon ab, wie alt sie sind und ob sie automatisch hinzugefügt wurden oder nicht.
• Dies ist die letzte Version, die noch mit JRE 6 läuft. Die nächste Version wird JRE 7 benötigen.

Kommentare entweder hier oder auch im Entwicklungs-Thread.

Quote from seahawk1986

Die Frage ist halt ob man sich einen Gefallen damit tut die Frames auszurechnen statt hauptsächlich einen String zu kopieren - da wäre man von den Angaben in der info-Datei bis auf die Frames nach dem Timestamp unabhängig

Dann teilt man eben die errechneten Frames nochmal durch fps und gibt Sekunden aus. Problem gelöst.

Ich habe sicherheitshalber nochmal direkt im VDR-Quelltext nachgeschaut (HMSFToIndex aus recording.c). Und zwar ist sowohl die Zeitangabe als auch der Frame optional. (Den Code aus meinem letzten Beitrag habe ich entsprechend geändert.) Also egal wofür man sich letztendlich entscheidet, irgendetwas muss man immer umrechnen.
Umzurechnen hat aber auch Vorteile. Will man z.B. wissen, ob eine Marke am Anfang ist, muss man lediglich testen, ob der Frame == 0 ist, und braucht keine regulären Ausdrücke dafür.

Quote from seahawk1986

(dass die FPS nicht in der info-Datei stehen war AFAIK nur bei der summary.vdr der Fall, die unterstützt der Parser für die Info-Dateien von vdrnfofs aber sowieso nicht).

Ich meine die info.vdr von den "alten" Aufnahmen im PS-Format. Da steht definitiv keine Frame-Rate drin.

Quote from seahawk1986

Wie wäre es so - oder gibt es was besseres um näher an den Zeitcode der i-Frames zu kommen?:

Braucht man den Zeitcode überhaupt? Im XBMC-Wiki steht nämlich, dass man Frames auch direkt angeben kann. Ich weiß aber nicht, ob die bei #0 oder #1 anfangen.

Quote from seahawk1986

Code

tc = a.group(0)
                        hms = tc[:-2]
                        ff = tc[-2:]

Ziemlich fragil, wenn du mich fragst. Ich würde eher den regulären Ausdruck um ein paar Gruppen erweitern. Also zum Beispiel:

MARKS_FORMAT = re.compile(r'^((\d+):(\d+):(\d+)\.?)?(\d*[1-9]\d*)?')
def mark_to_frame(mark, fps):
    m = MARKS_FORMAT.match(mark)
    if not m or not m.group():
        return None
    frame = int(m.group(5)) - 1 if m.group(5) else 0
    if m.group(1):
        hms = map(int, m.group(2, 3, 4))
        frame += (hms[0] * 3600 + hms[1] * 60 + hms[2]) * fps
    return frame

Bei der Frame-Rate musst du aufpassen, weil die bei alten Aufnahmen nicht in der info.vdr steht, sondern fest auf 25,0 gesetzt ist, wenn ich mich nicht irre.