Sachliche VDR-Zusammenfassung gesucht

Zitat von Ein Eike

Ich weiß auch gar ncht, ob sich ein guter (parametrisierbarer) Regelsatz für automatisches Löschen findet, aber die Suche danach schadet bestimmt nicht.

Das ist eben die Kunst es möglichst vielen Recht zu machen - denn wenn ich das richtig sehe gibt es ja mehrere Motive dafür Sendungen automatisch löschen zu lassen:

• Platte soll nicht voll werden, falls nicht nötig -> den freizulassenden Bereich bei dessen Unterschreitung der VDR beginnt Aufnahmen zu löschen kann man in der recording.c bestimmen: Vorschlag: "VDR-Quota" - Plattennutzung per Config einschränken
• Seriensuchtimer sollen keine unübersichtlichen Riesenverzeichnisse erzeugen -> Externer EPG + epgsearch (+ falls nötig Seriestimer-Addon) (für Sammler) und/oder automatisches Löschen durch epgsearch, wenn mehr als X gesehene Aufnahmen eines Suchtimers existieren bzw. eine bestimmte Zeit vergangen ist.
• "Platte putzen" -> Aufnahmen mit Erstellungsdatum, Lebensdauer, Priorität und prozentualer Abspielposition (aus der resume-Datei und Dauer und Framerate aus der info-Datei) listen und sortieren, alte zu entfernende Aufnahmen umbenennen (*.rec -> *.del), damit der VDR sie löschen kann. IMHO reicht dafür ein Skript (ggf. mit Cronjob), wenn der Wunsch nach Vollautomatisierung besteht. Natürlich gibt es dann noch Nutzer, die gerne vorher sehen möchten was gelöscht werden soll um "wichtige" Aufnahmen vor dem Löschen retten zu können - dann braucht es am ehesten ein Plugin...

Was gibt es noch an Szenarien?

Überblick über Aufnahmen nach verschiedenen Kriterien ist auch eine nette Idee. Kann oder sollte aber auf andere Art und Weise gelöst werden. Ich würde mir hier eine Aufnahmeanzeige nach Regelsätzen wünschen.
- Neue Filme/Aufnahmen diese Woche (Regelsatz: ungesehen, jünger als 7 Tage, Genre Film)
- nächste Woche auslaufende Filme
letzteres wäre dann das eben genannte Szenario. Anyway ich würde es garnicht so aufblasen.

Ein Skript muss von aussen gepflegt und rangeflickt werden. Ein Plugin wäre nicht sehr aufwändig und schöner.

Zitat

Bezüglich Multiuser, bei mir gibt regelmässig Löschkonferenzen Da wird halt in die Runde gefragt ob dies oder jenes gelöscht werden kann oder ob das noch jemand haben möchte.
Geht halt irgendwie nicht automatisch, dazu müsste beim Programieren schon die Info abgelegt werden wers Programiert hat. Und wenn User A und User B die selbe Aufzeichnung programiert haben dann wird die Aufnahme erst geöscht nachdem der zweite User auch gelöscht hat. Beim ersten dürfte sie nach dem löschen nur ausgeblendet werden.
Aber dazu bräuchte der VDR ne richtige Nutzerverwaltung. Bis dahin muss man halt miteinander reden

Genau das macht bereits der Multiuser-Support im remotetimers-Plugin. Falls Du keinen Zweit-VDR hast: Das Plugin beschwert sich bei jedem Menüaufruf wenn kein Server konfiguriert/erreichbar ist. Die Meldungen müsste ich deaktivierbar machen falls jemand nur am Multiuser- und nicht am Remote-Teil des Plugins interesse hat

Ein Problem dabei ist, dass sich da immer bestimmte Plugins in die Quere kommen und es schwer ist da eine konsistente Bedienung hinzubekommen...
z.B. ersetze ich das EPG-Menü normalerweise durch epgsearch (und ggf. das Aufnahmemenü durch extrecmenu). Das Aufnahmemenü von remotetimers sieht zumindest mit den Anthra-Skins recht merkwürdig aus und es braucht den Patch für LCARS (unterstützt das Plugin evtl. auf absehbare Zeit die Menü-Kategorien, die z.B. skinnopacity auswerten kann?).

Was ich mir noch vorstellen könnte, wäre eine "Gnadenzeit" nach dem Ansehen.

Du meinst nicht löschen wenn mtime der resume Datei jünger als x Tage ist ?

Bezgl Lifetime: Die meint Tage. Nach "98 Tage" sollte also "Nie" angezeigt werden ;). Ich weiss nicht ob das explizit konfiguriert werden muss. Die Prio hingegen ist ein synthetischer Wert. Hier könnte man zum Beispiel <51 nutzen für diese Aufnahmen, dann haben die Timer/Aufnahmen immer noch genug Raum sich zu prügeln. Serien u.ä. läuft bei mir immer mit 50 über die Suchtimer rein, während normale Aufnahmen (Filme) 99 haben.

Mit Brückenzeit meinte ich die Nachlaufzeit - weiss nicht ob die Aufnahme die mitbekommt - sehe jetzt aber kein Riesenproblem darin hier die im System gesetzte zu verwenden. Letztenendes ist es ja auch eher ein schwacher Indikator.

Was das unterm hintern weglöschen angeht: lass doch einfach sagen: mtime der resume muss älter als ein Tag sein. Ist mir doch egal wenn eine Aufnahme mit 7 bach 9 Tagen gelöscht wird.

Ich mag einfach keine Einstellungen die sich wegoptimieren lassen bei gleicher Funktion

Neu ist das Thema auch nicht: Priorität & Lebensdauer - grad drüber gestolpert.

Zitat

Ein Problem dabei ist, dass sich da immer bestimmte Plugins in die Quere kommen und es schwer ist da eine konsistente Bedienung hinzubekommen... z.B. ersetze ich das EPG-Menü normalerweise durch epgsearch (und ggf. das Aufnahmemenü durch extrecmenu).

Klar - Multiuser ist ein Konzept das sowohl EPG-Menü, Timer-Menü als auch Aufnahmen-Menü gleichermaßen betrifft. Remotetimers bringt eine Multiuser-Variante all dieser Menüs mit. Wer ein anderes Plugin als Menüersatz bevorzugt, steht damit im Regen oder müsste das Plugin entsprechend erweitern. Zumindest für den Remotetimers-Teil ist meines Wissens Unterstützung in yaepghd vorhanden.

Zitat

Das Aufnahmemenü von remotetimers sieht zumindest mit den Anthra-Skins recht merkwürdig aus

Das Aufnahmemenü von remotetimers entspricht optisch dem des Original-VDRs. Keine Ahnung was das Anthra-Skin macht. Kannst Du einen Screenshot machen?

Zitat

und es braucht den Patch für LCARS

Der Patch für LCARS sorgt lediglich dafür, dass bei Client-Server im VDR-Hauptmenü die Timer des Servers angezeigt werden. Im Prinzip das gleiche Problem in grün: Jeder Skin (und jedes Plugin) das bei Client-Server mitspielen will, muss leider auch entsprechend angepasst werden.

Zitat

(unterstützt das Plugin evtl. auf absehbare Zeit die Menü-Kategorien, die z.B. skinnopacity auswerten kann?).

Du meinst mit SetMenuCategory(...)? Die unterstützt das Plugin, allerdings wird beim Recordings-Menü mcPlugin und nicht mcRecording gesetzt. Remotetimers hat eine eigene "freie Plattenplatz"-Anzeige in der Titelzeile (nämlich pro Partition) und manche Skins fügen ihrerseits den freien Plattenplatz der Titelzeile hinzu. Um die verwirrende doppelte Anzeige zu vermeiden, hatte ich mich für mcPlugin entschieden. Wenn das Stress bereitet kann ich aber gerne auf mcRecording wechseln.

Falls Du hingegen auf die neuen Funktionen SetItemEvent(), SetItemTimer() und SetItemRecording() anspielst: Die sind ungeeignet, da dann der Skin etwas von Multiuser und Client-Server verstehen müsste.

Zitat von schmirl

Wenn das Stress bereitet kann ich aber gerne auf mcRecording wechseln.

Momentan sieht es so aus (im Vergleich links Skinnopacity nativ - rechts remotetimers) - ich weiß dass SkinnOpacity da momentan einen Sonderfall darstellt, aber ich fände es schön, wenn es trotzdem damit funktionieren würde, denn die VDR-eigenen Menüs selbst werden ja richtig dargestellt:
Aufnahmen:
[Blockierte Grafik: https://dl.dropbox.com/u/960809/nOpacity/Aufnahmen.jpg] [Blockierte Grafik: https://dl.dropbox.com/u/960809/nOpacity/Aufnahmen_remotetimers.jpg]
EPG:
[Blockierte Grafik: https://dl.dropbox.com/u/960809/nOpacity/EPG_.jpg] [Blockierte Grafik: https://dl.dropbox.com/u/960809/nOpacity/EPG_remotetimers.jpg]

Das Timermenü wird von SkinnOpacity noch nicht angepasst, daher gibt es da momentan keinen wesentlichen Unterschied in der Darstellung:
[Blockierte Grafik: https://dl.dropbox.com/u/960809/nOpacity/timer_.jpg] [Blockierte Grafik: https://dl.dropbox.com/u/960809/nOpacity/Timer_remotetimers.jpg]

Der Fehler bei der Darstellung des Aufnahmeverzeichnisses liegt wie ich gerade gemerkt habe weder an text2skin noch am remotetimers Plugin, sondern an Anthra-1920-FSE und tritt wohl nur auf, weil das freigegebene Aufnahme-Verzeichnis vom Server den Namen VDR trägt und extrecmenu nicht verwendet wird (also auch mit der normalen Ansicht des Aufnahmeverzeichnis des VDR):
[Blockierte Grafik: https://dl.dropbox.com/u/960809/anthra/Anthra-1920-FSE-remotetimers-recordings.PNG]

Habe mir nopacity mal angeschaut. Wie vermutet arbeitet es mit den in VDR 1.7.33 eingeführten SetItem...() Funktionen. Dabei werden dem Skin die jeweiligen Objekte (cTimer, cEvent, cRecording, cChannel) übergeben und der Skin kann sich selbst überlegen, wie er diese in der Liste darstellen möchte. Für ein Plugin, das zusätzliche Informationen zu diesem Objekt in der Liste darstellen will, ist diese neue Schnittstelle in der jetzigen Form leider nicht geeignet.

Aus Sicht von remotetimers aber vielleicht nicht ganz so tragisch. Im Aufnahmen-Menü wird nichts zusätzliches angezeigt. Hier wird in der nächsten Version SetItemRecording() aufgerufen (Patch vorab siehe remotetimers und Sortieren der Aufnahmen. Im Timers-Menü zeigt remotetimers zusätzlich an, ob es sich um einen lokalen Timer oder um einen Timer auf dem Server handelt. Die meisten nehmen ohnehin nur auf dem Server auf, von daher ist diese Information in der Regel entbehrlich. In den EPG-Menüs zeigt Remotetimers an, ob zu der Sendung ein normaler Timer oder ein privater Timer (Multiuser) programmiert ist. Wer Multiuser nicht nutzt, hat ebenfalls kein Problem wenn diese Info fehlt. Werde dies im Plugin-Setup konfigurierbar machen. Im obigen verlinkten Patch bräuchtest Du nur die Kommentare rund um SetItemTimer und SetItemEvent löschen.

Zitat von schmirl

Falls Du hingegen auf die neuen Funktionen SetItemEvent(), SetItemTimer() und SetItemRecording() anspielst: Die sind ungeeignet, da dann der Skin etwas von Multiuser und Client-Server verstehen müsste.

Moin,

ich habe zwar kein Client-Server Setup und kenne und benutze remotetimers nicht, aber da muss ich erst mal prinzipiell widersprechen Der Skin stellt lediglich dar, was er bekommt. Der Unterschied ist, dass in der bisherigen "SetItems()" Methode die Texte / Spalten vom VDR bzw. vom jeweiligen Plugin vorgegeben werden, mit den neuen Methoden bekommt der Skin nur das Objekt (z.B. ein cEvent oder cRecording Objekt) und stellt anhand der Attribute dieses Objekts dar, was er für "richtig" hält. Welche Recordings in welcher Reihenfolge angezeigt werden, ist dem Skin egal, das liegt immer noch in der Hand des darunterliegenden Plugins.

Wird denn z.B. bei remotetimers noch zusätzlich etwas dargestellt, was nicht im cRecordings Objekt verfügbar ist? Der Besitzer z.B. oder irgendwelche anderen Sachen?

Meiner Ansicht nach krankt aber hier das ganze Konzept der tiefer in die VDR Systematik eingreifenden Plugins. Klaus vertritt die Meinung, dass Plugins keine Abhängigkeiten untereinander haben sollen. Plugin Autoren wollen aber die Kernfunktionalität des VDR verändern, weil sie es brauchen und können. Geht ein Skin auf die Anforderungen eines solchen Plugins ein, geht das nicht ohne Abhängigkeiten zwischen Plugin uns Skin, wenn das Plugin sein eigenes Süppchen kocht...

Des weiteren sind die meisten Plugins beschissen bzw. gar nicht dokumentiert, sodass z.B. Skinentwickler, sofern sie das Plugin nicht schon Jahre lang einsetzen und die entsprechenden Erfahrungen haben, erst mal aufwändig checken müssen, was das Plugin eigentlich genau wie macht. Ohne stundenlanges Quelltext lesen ist das schwierig...und wenn der Skinautor das Plugin selbst nicht braucht und einsetzt, ist die Motivation dafür natürlich nicht wirklich gegeben.

Insgesamt wird das ganze VDR - Plugins Konstrukt immer ein lose zusammenhängender Klumpatsch sein...einiges wird zusammen funktionieren, einiges nicht. Anfänger haben hier keine Chance durchzublicken. Aber in der jetzigen Konstellation sehe ich keine großen Chancen, das zu ändern, ausser Klaus würde die von Plugins angeflanschten Funktionalitäten in irgendeiner Art und Weise in den Core VDR mit reinnehmen (zumindest z.B. über virtuelle Funktionen, die im VDR leer sind und von Plugins über Vererbung überschrieben werden könnten).

Just my 2 cent...ciao Louis

Jetzt haben sich Schmirls und meine Antwort überschnitten...aber im Prinzip schreiben wir ja fast das selbe

Ciao Louis

Zitat von Ein Eike

Ach ja: Das Lösch-Plugin (oder Script oder wie auch immer) sollte im Log vermerken,
was es gelöscht hat und nach welchen Kriterien. Damit der Anwender im Zweifel
wenigstens weiß, warum seine Aufnahme verloren ist...

Das wird sicher lustig, die ganzen Postings zu sehen, die da kommen werden...
"Das Lösch-Plugin läuft Amok!"
"VDR hat willkürlich meine Aufnahmen gelöscht!" (weil man muß ja alle Plugins verwenden, auch wenn man gar nicht weiß, was die so treiben...).
"Zusätzlich zu den 10hoch7 Parametern des Lösch-Plugins brauche ich noch folgende 42 Optionen..."

Das wird ein Spaß

Klaus

bei 99 wird doch meine ich gar nicht gelöscht oder irre ich mich da ??

Zitat von schmirl

Im obigen verlinkten Patch bräuchtest Du nur die Kommentare rund um SetItemTimer und SetItemEvent löschen.

Das wäre dann Zeile 66ff und Zeile 117ff: http://pastebin.com/2CVB8QDv
Beim Bauen wirft er dann einen Fehler:

g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"remotetimers"' -I/usr/include/vdr/include remotetimers.c
g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"remotetimers"' -I/usr/include/vdr/include svdrp.c
g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"remotetimers"' -I/usr/include/vdr/include menu.c
menu.c:1023:105: Fehler: keine Elementfunktion »void PluginRemoteTimers::cMenuTimerItem::SetMenuItem(cSkinDisplayMenu*, int, bool, bool)« in Klasse »PluginRemoteTimers::cMenuTimerItem« deklariert
menu.c:1469:108: Fehler: keine Elementfunktion »void PluginRemoteTimers::cMenuScheduleItem::SetMenuItem(cSkinDisplayMenu*, int, bool, bool)« in Klasse »PluginRemoteTimers::cMenuScheduleItem« deklariert
make: *** [menu.o] Fehler 1

Zitat von Ein Eike

Hallo!

Bei Lifetime 99 löscht der VDR gar nicht, richtig.
Das könnte das Plugin ja anders halten - aber das wäre wohl keine gute Idee.

Das wäre nicht nur keine gute Idee, sondern eine ganz besonders blöde Idee!

Klaus