You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Wednesday, June 13th 2012, 6:50pm

reclist (Entwicklung)

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 ...
Give root password for maintenance (or type Control-D to continue): _

This post has been edited 2 times, last edit by "tag" (Apr 23rd 2013, 4:53pm)


2

Thursday, June 14th 2012, 9:06pm

Danke für die neue Version.

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.

Was genau passiert da? Ist das ein Echtzeit-Caching - also ich spiele im VLC-Player eine Aufnahme ab, er nutzt im Hintergrund die volle Netzwerkbandbreite und lädt sie lokal vor, bis sie komplett auf der Platte liegt und kann dann sofort ohne den VDR das ganze zu Ende sehen? Oder muss man die Aufnahmen vorladen, damit man sie dann schon mal lokal auf der Platte hat und erst dann abspielen kann?
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

3

Friday, June 15th 2012, 1:23am

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?
Give root password for maintenance (or type Control-D to continue): _

4

Monday, July 2nd 2012, 11:56pm

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?
Give root password for maintenance (or type Control-D to continue): _

5

Saturday, December 15th 2012, 9:13pm

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?
Give root password for maintenance (or type Control-D to continue): _

6

Saturday, December 15th 2012, 10:33pm

Geniale Beschriftung bei den Icons.... :P

:!: Hier nicht klicken!!



dreipo.cc

"Ubuntu" -- An african Word, meaning: "Gentoo is too hard for me".

my VDR


Gen2VDR V4.3PO

VDR: vdr-2.1.6
Mainboard: ASUS P8Z77-V LX2
CPU: i7-3770K
RAM: 16G
System HDD: OCZ-VERTEX4 SSD, 120 GB
Video HDD: WD Caviar Green, 3 TB
BD-ROM: Samsung SH-B123L
Gehäuse: Thermaltake DH202 Touch (VM90051N2Z)
DVB: DD Cine S2 V6.5 & DuofleX C/T
IR/FB: yaUSBIR v3 ; Harmony 885

7

Sunday, December 16th 2012, 6:34pm

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! ;)
Give root password for maintenance (or type Control-D to continue): _

8

Sunday, December 23rd 2012, 11:31pm

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?
Give root password for maintenance (or type Control-D to continue): _

9

Monday, December 24th 2012, 8:37am

[...] Ist das besser so?

Das Problem mit den Beschriftungen der Icons besteht nach wie vor.

:!: Hier nicht klicken!!



dreipo.cc

"Ubuntu" -- An african Word, meaning: "Gentoo is too hard for me".

my VDR


Gen2VDR V4.3PO

VDR: vdr-2.1.6
Mainboard: ASUS P8Z77-V LX2
CPU: i7-3770K
RAM: 16G
System HDD: OCZ-VERTEX4 SSD, 120 GB
Video HDD: WD Caviar Green, 3 TB
BD-ROM: Samsung SH-B123L
Gehäuse: Thermaltake DH202 Touch (VM90051N2Z)
DVB: DD Cine S2 V6.5 & DuofleX C/T
IR/FB: yaUSBIR v3 ; Harmony 885

10

Friday, February 8th 2013, 9:59pm

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?
Give root password for maintenance (or type Control-D to continue): _

11

Thursday, April 4th 2013, 2:49pm

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.
Give root password for maintenance (or type Control-D to continue): _