Beiträge von tag

Neue Testversion: reclist-902.jar

Ich habe den Cache nochmal überarbeitet. Geöffnete Aufnahmen werden jetzt nicht mehr so schnell aus dem Cache entfernt. Bei Platzmangel werden die Aufnahmen in folgender Reihenfolge gelöscht:

• Vor längerer Zeit automatisch hinzugefügte Aufnahmen
• Vor längerer Zeit manuell hinzugefügte Aufnahmen
• Kürzlich automatisch hinzugefügte Aufnahmen
• Kürzlich manuell hinzugefügte oder geöffnete Aufnahmen

Wie lange "kürzlich" ist, kann in den Einstellungen festgelegt werden.

Ist das besser so?

Hmm, ja ... Das Problem ist, dass Swing (was ich für die GUI verwende) fast überall HTML erlaubt. Das ist aber oft problematisch, z.B. wenn ich einfach nur Teile einer Textdatei anzeigen will, ohne befürchten zu müssen, dass mein Programm durchdreht, nur weil da plötzlich irgendwo HTML auftaucht. Also habe ich das kurzerhand komplett abgeschaltet. Nicht unbedingt schön, aber sehr effektiv!

Moment mal, mit dem Skript stimmt etwas nicht. Die Zeitangaben passen nicht zusammen.
In der EDL stehen, wenn ich das richtig sehe, Zeitstempel mit Sekundenbruchteilen.
In der marks.vdr stehen aber entweder direkt Frame-Nummern (beginnend bei "1") oder Zeitstempel mit Frame-Nummer nach dem Punkt (beginnend bei "0:00:00.1").
Ob sich XBMC aber ausgerechnet daran stört, bezweifle ich. Schlimmstenfalls sind die Sprungmarken halt etwas ungenau ...

Zunächst eine aktuelle Testversion für Experimentierfreudige: reclist-894.jar

Die wichtigste Änderung besteht darin, dass Aufnahmen bei Platzmangel nicht mehr komplett aus dem Cache entfernt werden. Die Videodateien werden zwar nach wie vor aus dem Cache gelöscht, aber die Aufnahme an sich bleibt im Cache. Sobald wieder genug Platz vorhanden ist, wird die Aufnahme wieder hinzugefügt.

Das führt mich zurück zu der Frage, wie entschieden werden soll, welche Aufnahmen im Cache bleiben dürfen und welche nicht. Ich habe jetzt die Regeln aus dem letzten Beitrag umgesetzt, bin aber noch nicht zufrieden damit. Ich habe alles eingebaut, was mir nützlich erschien, aber ob das auch wirklich praxistauglich ist, kann ich alleine schlecht beurteilen. Meinungen?

Eine weitere Änderung am Cache betrifft das automatische Hinzufügen von Aufnahmen. Im Moment gibt es dazu einfach nur ein Textfeld in den Einstellungen, in das man ein paar Verzeichnisnamen (keine kompletten Pfade!) eintragen kann. Neue Aufnahmen in diesen Verzeichnissen werden dann automatisch im Cache gespeichert. Das kann man natürlich beliebig kompliziert gestalten, z.B. mit Platzhaltern oder regulären Ausdrücken oder sonstwas. Was meint ihr dazu?

Im Vergleich zur letzten Version konnte ich übrigens das Durchsuchen der Videoverzeichnisse noch etwas beschleunigen. Die Berechnung der Aufnahmegröße habe ich aber vorerst noch weggelassen, weil das wiederum zu einer deutlichen Verzögerung geführt hätte. (Braucht ihr die Dateigröße eigentlich wirklich?)

Bevor ich es vergesse: Ich will demnächst auf Java 7 umsteigen. Ist noch jemand auf Java 6 angewiesen?

Um nochmal auf den Cache zurückzukommen: Ein Cache funktioniert ja dann am besten, wenn der Benutzer ihn möglichst nicht bemerkt. Er sollte also immer die richtigen Aufnahmen vorhalten.

Nur nach welchen Regeln sollen diese Aufnahmen ausgewählt werden?

• Aufnahmen erst beim Anschauen hinzuzufügen geht nicht, weil die Dateien so wahnsinnig groß sind. Man müsste ständig warten, bis alles übertragen wurde.
• Die Aufnahme auf dem Server abzuspielen, während sie im Hintergrund übertragen wird, geht nicht, weil ich VLC nicht mittendrin vom Server auf den Cache "umschalten" kann.
• Die Aufnahme sofort im Cache abzuspielen, während sie im Hintergrund übertragen wird, hat den Nachteil, dass man z.B. nicht vorspulen kann, weil das Meiste ja noch fehlt.
• Bleibt also nur, die Aufnahme schon vor dem Abspielen zwischenzuspeichern. Notfalls per Knopfdruck (so wie jetzt).
• Das Programm könnte sich merken, welche Aufnahmen der Benutzer zuletzt angeschaut hat und daraus irgendwie ableiten, welche Serien vorgeladen werden sollen. Allerdings dürfte diese "Lernphase" eher nervig sein.
• Der Benutzer könnte über eine Art Filter einstellen, welche Aufnahmen automatisch im Cache landen sollen. Nach welchen Kriterien sollte gefiltert werden können? Genügt der Verzeichnisname?

Ich tendiere zur letzten Variante. Die scheint mir am zuverlässigsten zu sein. Da muss ich nämlich nicht raten.

Irgendwann ist der Cache ja auch mal voll. Dann stellt sich die Frage, welche Aufnahmen entfernt werden können, um Platz für neue zu schaffen.

• Im Moment wird einfach die älteste Aufnahme aus dem Cache gelöscht.
• Die Aufnahme, die gerade angeschaut wird, sollte natürlich nicht gelöscht werden. Nur wie stelle ich das fest? Ich könnte z.B. speichern, welche Aufnahme zuletzt geöffnet wurde. Allerdings kann man ja auch mehrere Aufnahmen in die VLC-Warteschlange eintragen. Dann wäre nur die jeweils zuletzt hinzugefügte Aufnahme vor dem Löschen geschützt.
• Umgekehrt können Aufnahmen, die der Benutzer schon bis zum Ende gesehen hat, früher gelöscht werden als solche, die der Benutzer noch nicht gesehen hat. In den meisten Fällen werden Aufnahmen wohl nur einmal geschaut und können dann aus dem Cache gelöscht werden. Auch hier wieder: Wie kann man das zuverlässig feststellen?
• Ich könnte auch einfach festlegen, dass Aufnahmen frühestens X Stunden nach dem Öffnen gelöscht werden dürfen (also eine Art "Verfallsdatum").
• Automatisch hinzugefügte Aufnahmen (siehe oben) sollten vor manuell hinzugefügten gelöscht werden.

Wäre noch abzuwägen, wie diese Regeln zusammenwirken sollen. Wenn z.B. eine bereits angeschaute, manuell hinzugefügte Aufnahme und eine noch nicht angeschaute, automatisch hinzugefügte Aufnahme zur Wahl stehen, welche sollte zuerst gelöscht werden?

schnoefftel
Mit Aufnahmegröße meinst du die Dateigröße? Habe ich mir notiert. Löschen kann man übrigens schon (siehe Menü).
Allerdings habe ich nicht vor, Aufnahmen zu verschieben oder umzubenennen. Wenn man das versehentlich macht, während die Aufnahme noch läuft, wird sie nämlich abgebrochen. Ich spreche da aus Erfahrung ...

Habib
Ich brauche mehr Informationen! Gibt's eine Fehlermeldung?

Letzteres. Wenn sich eine Aufnahme zu dem Zeitpunkt, an dem VLC gestartet wird, schon komplett im Cache befindet, wird sie auch von dort gelesen. Ansonsten wie gehabt vom Server.

Ich spiele allerdings mit dem Gedanken, dieses "Vorladen" irgendwie zu automatisieren. Zum Beispiel könnte man seine Lieblingsserien in einer Liste eintragen, so dass neue Folgen bei der nächsten Aktualisierung automatisch zum Cache hinzugefügt würden. Meinungen?

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

reclist-799.jar

[Blockierte Grafik: http://www.student.informatik.tu-darmstadt.de/~guentner/reclist-640.png]

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 Datei/Einstellungen noch die Programme und Verzeichnisse eingetragen werden.

Neu in dieser Version ist ein Aufnahme-Cache: Einzelne Aufnahmen können vorübergehend auf dem lokalen Rechner zwischengespeichert werden, so dass der VDR beim Abspielen nicht mehr ständig erreichbar sein muss und sogar ganz ausgeschaltet werden könnte. Wer diese Funktion nutzen möchte, muss erst in den Einstellungen ein (leeres) Verzeichnis angeben, in dem der Cache angelegt wird.

Kommentare entweder hier oder auch im Entwicklungs-Thread.

Dieser Thread soll die weitere Entwicklung von reclist begleiten. Hier kann über alles diskutiert werden, was die Entwicklung betrifft, aber für die meisten Benutzer eher uninteressant sein dürfte, wie z.B. Details neuer Funktionen oder Vorabversionen.

Aktuelle Version:
reclist rev. 994

Alte Versionen:
reclist rev. 909
reclist rev. 799
Zum alten Thread ...

Ich habe das gleiche Problem mit meinem reclist-Thread. Anscheinend wurde der geschlossen. Mag mir jemand erklären, warum?

Balduin
Öffne bitte eine Eingabeaufforderung und gib das ein:

java -jar c:\pfad\zu\reclist.jar

Kommen da irgendwelche verdächtigen Meldungen?

XSLT hätte immerhin den Vorteil, dass verschachtelte Elemente, Zeichenreferenzen, usw. vergleichsweise einfach zu handhaben sind. Mit grep (bzw. sed) macht das echt keinen Spaß.

Zitat von Keine_Ahnung

Funktioniert das nicht nur wenn die Webseiten fehlerfrei sind Da würde ich jetzt erstmal spontan nicht von ausgehen.

Eine Möglichkeit wäre, den Quelltext in XHTML zu konvertieren (-asxhtml bzw. output-xhtml: yes), bevor man XSLT darauf loslässt.

Das weiß ich doch auch. Ich rede aber über die Einstellung LOCAL_NET aus der vdradmind.conf.

Zitat von DaKilla

Unsinn. Mal was von TCP/IP gehört. 0.0.0.0 ist Broadcast/Multicast. Also alles.

Noch mal langsam zum Mitmeißeln:
LOCAL_NET = 0.0.0.0/32 bedeutet, dass der vdradmin prüft, ob alle 32 Bits der IP-Adresse des Absenders 0.0.0.0 sind. Das ist schon deshalb unmöglich, weil sich damit gar keine TCP-, geschweige denn eine HTTP-Verbindung aufbauen ließe. Wie sollten denn die Antwortpakete an 0.0.0.0 zurückgeschickt werden? Effektiv werden alle Benutzer ausgesperrt.
Deswegen entweder die richtige Netzadresse und Präfixlänge eintragen (z.B. 192.168.6.0/24) oder gleich 0.0.0.0/0 verwenden (dann ist die IP-Adresse egal).

Zitat von ALT255

6419 ist seit neuestem der Standard svdrp port.

Das war auch für mich neu. Danke.

Zitat von tom66

LOCAL_NET = 0.0.0.0/32

Da stimmt etwas nicht. /32 würde bedeuten, dass die IP-Adresse exakt 0.0.0.0 sein muss. Das geht aber gar nicht. Probier's mit /0.

Version 680 ist fertig. Es gibt diesmal nur ein paar kleine Korrekturen: Einige Filter funktionierten nicht mehr, wenn normale Videos in der Liste waren. Außerdem habe ich bei "normaler" Aktualisierung mit F5 Wake on LAN standardmäßig deaktiviert (man kann es aber in den Einstellungen wieder einschalten - oder eben die komplette Aktualisierung mit Strg+F5 benutzen).

Version 677 ist fertig. Versuchsweise werden jetzt auch "normale" Videos (z.B. *.avi) aufgelistet. Ich bin mir aber nicht sicher, ob ich das behalte.

Zitat von oberlon

digest.update(string.getBytes());

getBytes("UTF-8") funktioniert besser.

Zitat von marcuszurhorst

Meine erste Idee war, dass man wohl einfach nur die Varianten einschränken müsste, da hier auch ein 100 km² großes Feld abgesucht wird.

Im Prinzip richtig, aber bei Nord hast du etwas zu viel gekürzt. Außerdem gibt md5sum das Ergebnis mit zwei Leerzeichen aus. Und du musst darauf achten, das Skript als UTF-8 zu speichern. So müsstest du irgendwann auch ein Ergebnis erhalten.

Zitat von marcuszurhorst

Aber in den Logs steht auch drin, dass manche Leute es in C, wieder andere in Java oder auch PHP programmiert haben.
Und wenn ich dann lese, dass dort binnen Sekunden die Lösung da ist, dann bin ich echt baff. Hätte nie gedacht, dass der Faktor zwischen Skript und Code derart riesig ist.

Viel besser wird es mit einem Shell-Skript wohl nicht. Für jede MD5-Berechnung muss ein neuer Prozess gestartet werden, und das dauert eben. Ich habe auf meinem Rechner zum Testen md5sum in einer Endlosschleife immer wieder dieselbe Hash berechnen lassen und kam dabei gerade einmal auf 500 Hashes pro Sekunde. Dann habe ich das spaßeshalber in Python nachprogrammiert und hatte ruckzuck die Lösung.

Nachtrag: Vergiss das mit den Leerzeichen ... `echo` hat mich verwirrt.