Soll das so sein oder ist das noch ein Bug.
Das ist wohl ein bekanntes Problem: [VDR 2.1.6] geändertes info-File wird nicht eingelesen
Vor Version 2.0.5 bzw. 2.1.3 wurde beim Update der Aufnahmeliste zuerst die gesamte Liste gelöscht und dann komplett neu eingelesen. Das hatte aber zu Abstürzen geführt, wenn die Aufnahmeliste upgedatet wurde während das "Recordings"-Menü offen war. Daher habe ich das so geändert, daß die Liste der Aufnahmen nicht mehr komplett gelöscht und wieder neu erstellt wird, sondern nur noch neu gefundene Aufnahmen hinzugefügt und nicht mehr vorhandene entfernt werden. Ein Nebeneffekt davon ist leider, daß nachträgliche Änderungen an 'info'-Dateien dabei nicht mehr erkannt werden.
Um das wieder so zu bekommen, wie es früher war, müsste wohl in cRecordings::ScanVideoDir() für den Fall, daß GetByName(buffer) true liefert (die Aufnahme ist also bereits in der Liste) eine neu zu schaffende Funktion cRecording::UpdateInfo() für diese Aufnahme aufgerufen werden. Dort sollte dann die 'info'-Datei neu eingelesen werden (evtl. nur, falls sich ihr Timestamp seit dem letzten Einlesen verändert hat). Hunderprozentig sicher wäre das aber auch nicht, da z.B. cRecordingInfo::Title() einen Pointer auf den entsprechenden String zurückliefert, und dieser String würde beim neuen Einlesen ja gelöscht und neu angelegt, was bei einem späteren Zugriff auf die alte Adresse zum Absturz führen könnte.
Momentan möchte ich daher an dieser Stelle eigentlich nichts mehr ändern.
Beim "normalen" Betrieb von VDR (also ohne externe Veränderungen an 'info'-Dateien) stellt das ja auch kein Problem dar ;-).
Klaus
...
Momentan möchte ich daher an dieser Stelle eigentlich nichts mehr ändern.
Beim "normalen" Betrieb von VDR (also ohne externe Veränderungen an 'info'-Dateien) stellt das ja auch kein Problem dar ;-).
OK, danke für die Info, es ist also erst mal so gewollt.
Die händischen Änderungen kommen bei mir jetzt auch nicht so häufig vor und dann kann ich durchaus einen VDR-Neustart machen.
Gruß
kamel5
Vor Version 2.0.5 bzw. 2.1.3 wurde beim Update der Aufnahmeliste zuerst die gesamte Liste gelöscht und dann komplett neu eingelesen. Das hatte aber zu Abstürzen geführt, wenn die Aufnahmeliste upgedatet wurde während das "Recordings"-Menü offen war....
Könnte man dem VDR nicht beibringen, das "Recordings"-Menü, einfach zu schließen, bevor er das Verzeichnis neu einliest?
Könnte man dem VDR nicht beibringen, das "Recordings"-Menü, einfach zu schließen, bevor er das Verzeichnis neu einliest?
Das ist aber ziemlich nervig, wenn du dich gerade in den Untiefen der Unterverzeichnisse befindest und das dann gerade passiert. Außerdem können ja noch andere Plugins zu dem Zeitpunkt auf die Aufnahmenliste zugreifen.
Wartet der VDR nicht sowieso schon mit dem Einlesen bis das Menü geschlossen ist?
Das es mit den Pointer auf Strings Probleme geben kann verstehe ich, auf diese Weise lässt sich da also nix machen.
Aber was passiert denn, wenn eine Aufnahme gelöscht wird?
Wäre es möglich, die Aufnahme aus der cList<cRecording> zu löschen und "neu" zu finden d.h. wie eine neue Aufnahme einzulesen?
Wartet der VDR nicht sowieso schon mit dem Einlesen bis das Menü geschlossen ist?
Wenn es über SVDRP oder dbus2vdr angestoßen wird auf jeden Fall nicht - und ich hänge da ziemlich dran, weil ich die anderen VDRs mit ihren Aufnahmen im Netzwerk direkt sehen können möchte, wenn mein avahi-linker sie findet, einbindet und die Aktualisierung anstößt 
Der vdr liest auch selbst nebenbei ein, währnd das Menü offen ist, das ist kein Problem, weil er selbst das richtige locking benutzt.
Lars
Muß man den Inhalt der Infodatei denn überhaupt im Speicher cachen?
Spricht etwas dagegen, sie bei Bedarf einzulesen?
CU
Oliver
Spricht etwas dagegen, sie bei Bedarf einzulesen?
Das dauer dann mit modernen Skins wie nOpacity oder skindesigner etwas länger, wenn man schnell durch das Aufnahmen-Menü scrollt (und man könnte den automatischen umount von autofs nicht mehr so gut nutzen).
Ok, falls im Aufnahmemenü auf Infos aus dieser Datei zugegriffen wird, dann geht es natürlich nicht.
Mir fällt nur auf, dass der Scanvorgang ziemlich lang dauert, wenn mein komplettes Archiv eingebunden ist. 99,9% der Recording-Infos braucht man nicht.
Eigentlich braucht man doch nur die Infos der Aufnahmen, die sich im aktuell angezeigten Verzeichnis befinden plus die der Aufnahme, die evtl. gerade abgespielt wird.
CU
Oliver
Mir fällt nur auf, dass der Scanvorgang ziemlich lang dauert, wenn mein komplettes Archiv eingebunden ist. 99,9% der Recording-Infos braucht man nicht.
Ich weiß nicht, wie groß dein Archiv ist - bei mir sind es normalerweise deutlich unter 1000 Aufnahmen auf den VDRs und die werden auch über NFS mit einem 100 MBit-Netzwerk recht flott eingelesen - Kodi skaliert IMHO besser mit seinen Datenbanken, wenn es darum geht die Archive im Blick zu behalten...
Alles in allem sind im Archiv ca 10000 Aufnahmen, und da kommt das bestehende Konzept an seine Grenzen. Aber - wie gesagt - diese Informationen im Speicher zu halten, ist eigentlich überflüssig. Konqueror o.ä. lädt ja auch nicht alle Verzeichnisse eines Filesystems, sondern nur das aktuelle Verzeichnis...
Und eine Datenbank brauche ich auch nicht, meine Datenbank ist das Dateisystem.
Der vdr verwaltet die Aufnahmen in einer Liste, nicht in einer Baumstruktur. Man kann die Anzeige der Verzeichnisse ja auch deaktivieren. Aber die info-Datei bei Bedarf neu einzulesen, sollte der vdr schon dürfen. Wenn Plugins sich Daten daraus merken wollen, dürfen sie sich eben nicht nur die Pointer merken, sondern müssen den Titel o.ä. kopieren. Meistens wollen sie ja nur eine handvoll Daten, z.B. Skins bei der Anzeige der Aufnahmen.
Wenn ein Plugin also Probleme hat, sollte das Plugin repariert werden, und nicht der vdr zu sehr da drum rum arbeiten. Gilt ja auch für fehlerhafte Treiber usw..
Ich glaube, der Skindesigner hat schon ein Modul, was die Aufnahmen in einem Baum organisiert, um schnell passende Infos zu einem Verzeichnis zu bekommen. Mich würde mal interessieren, wie das mit 10.000 Aufnahmen zurecht kommt.
Lars
Ich glaube, der Skindesigner hat schon ein Modul, was die Aufnahmen in einem Baum organisiert, um schnell passende Infos zu einem Verzeichnis zu bekommen. Mich würde mal interessieren, wie das mit 10.000 Aufnahmen zurecht kommt.
Vermutlich besser, aber da Core-VDR schon kaum damit klar kommt, werde ich bestimmt nicht noch einen drauf packen.
Ist auch egal: Mit einer Baumstruktur hat man das Problem dann halt bei 100000 Aufnahmen. Es ist einfach ungünstig, alle Aufnahmeninfos im Speicher zu halten.
CU
Oliver
Macht es denn Sinn, das komplette Archiv in stetigem Zugriff zu haben? Man könnte natürlich das Menü auch umschreiben (oder ein Plugin bauen), das quasi ein Dateibrowser ist, so dass eigentlich gar nichts eingelesen wird, sondern nur das Verzeichnis, das man sich gerade ansieht. Aber dann gibt es wieder die Denksekunden beim Anlaufen der Platten, wenn man das Menü öffnet.
Eine Lösung für alle Situationen wird's vermutlich nicht geben.
10.000 Aufnahmen finde ich schon echt umfangreich, aber 100.000 halte ich für übertrieben. Wer kann denn das alles gucken?
Über die letzten 20 Jahre (oder wie lange gibt es DVDs?) haben sich hier ca. 1000 Scheiben angesammelt, und so wenig gucken wir eigentlich gar nicht. Aber das, was im TV gesendet wird und wir wirklich sehen wollen, sehen wir dann eben und löschen es meist hinterher. Da gibt es nicht viel, was sich aufzuheben lohnt. Aber das entscheidet ja zum Glück jeder selbst.
Lars
Macht es denn Sinn, das komplette Archiv in stetigem Zugriff zu haben?
Das Archiv ist natürlich normalerweise nicht im Zugriff: Die Platten werden nur bei Bedarf gestartet, gemountet und schließlich per "touch .update" eingebunden. Sonst wäre VDR zu träge.
Das ist jedoch irrelevant: Ich wollte nur anmerken, dass der Scanner ein fundamentales Problem hat (bzw. das fundamentale Problem ist).
Als Workaround ist das Archiv in verschiedene Themengebiete aufgeteilt.
Zitat
Man könnte natürlich das Menü auch umschreiben (oder ein Plugin bauen), das quasi ein Dateibrowser ist, so dass eigentlich gar nichts eingelesen wird, sondern nur das Verzeichnis, das man sich gerade ansieht. Aber dann gibt es wieder die Denksekunden beim Anlaufen der Platten, wenn man das Menü öffnet.
Höchstens beim ersten Öffnen. Auch dies ließe sich vermeiden, wenn man einen Teil im Speicher gecached hat:
- einfach: nur das aktuelle Verzeichnis
- besser: das aktuelle Verzeichnis und eine Ebene darüber und darunter
Btw, falls sich die Platten schlafen legen, gibt es diese Denksekunde auch heute schon, wenn man eine Aufnahme abspielen möchte.
ZitatAber das, was im TV gesendet wird und wir wirklich sehen wollen, sehen wir dann eben und löschen es meist hinterher. Da gibt es nicht viel, was sich aufzuheben lohnt. Aber das entscheidet ja zum Glück jeder selbst.
Bei mir ist der weit größte Teil der aufgezeichneten Sendungen das Musikarchiv. Und dieses werde ich bestimmt nicht löschen, da die Sendungen nicht laufend wiedeholt werden. Der Rest ist mir nicht wichtig.
CU
Oliver
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
