VDR Portal

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 ...

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?

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?

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?

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!

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:

1. Vor längerer Zeit automatisch hinzugefügte Aufnahmen
2. Vor längerer Zeit manuell hinzugefügte Aufnahmen
3. Kürzlich automatisch hinzugefügte Aufnahmen
4. Kürzlich manuell hinzugefügte oder geöffnete Aufnahmen
   

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

Ist das besser so?

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?

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.