Multiple Video-Verzeichnisse: freie Diskussion zu Konzepten, Patches, Lösungen und Wünschen

  • Moin!


    Das ist kein Bug, sondern ein Feature... :)


    Wenn immer alle Aufnahmen durch das Verschieben/Kopieren unter local landen würden, dann könnte man nie eine Aufnahme auf den Server oder externe Platte verschieben. Eigentlich müsste man

    Code
    SVDRP> MOVR 2825 local~Einsatz im Revier~Toto & Harry - Die Zwei vom Polizeirevier~2013.02.16-06:53-Sa-Test


    angeben, wenn man eine Aufnahme unter "local" umbenennen möchte.


    Mit

    Code
    SVDRP> MOVR 2825 server~Einsatz im Revier~Toto & Harry - Die Zwei vom Polizeirevier~2013.02.16-06:53-Sa-Test


    kann man dann eine Aufnahme auf den Server verschieben.


    Was seht ihr denn bei LSTR? Da müsste "local" doch Bestandteil des Namens sein, oder?


    Gleiches gilt für extrecmenu (das ich selbst nicht einsetze, es mittlerweile mit vdr 2.1.x für überflüssig halte und deshalb auch keine große Anstrengung in Kompatibilität stecke): Man muss den ganzen Pfad ab dem Video-Verzeichnis angeben, damit die Aufnahme da landet, wo sie hin soll.


    Mit skinnopacity hab ich eigentlich keine Probleme, kann aber noch mal schauen. Ich vermute, dass es dann eher ein Fehler oder Unsauberkeit im skin ist, weil es evtl. Annahmen über den Aufenthaltsort der info-Datei macht, die nicht immer stimmen. Aber bevor ich mit einem Finger auf jemanden zeige, werde ich das erst selbst prüfen. Gebt mir also ein paar Tage.


    Lars.

  • Moin,


    Mit skinnopacity hab ich eigentlich keine Probleme, kann aber noch mal schauen. Ich vermute, dass es dann eher ein Fehler oder Unsauberkeit im skin ist, weil es evtl. Annahmen über den Aufenthaltsort der info-Datei macht, die nicht immer stimmen. Aber bevor ich mit einem Finger auf jemanden zeige, werde ich das erst selbst prüfen. Gebt mir also ein paar Tage.


    ich habe zwar keine Ahnung, um was es hier genau geht, aber wenn man an die Info Datei einer Aufnahme nicht mehr per


    Code
    const cRecordingInfo *info = recording->Info();


    (wobei recording ein cRecording Obbjekt ist) an die Info Datei der Aufnahme rann kommt, dann läuft definitiv was schief ;) Was anderes mache ich übrigens in nOpacity nicht...


    Ciao Louis

  • Was seht ihr denn bei LSTR? Da müsste "local" doch Bestandteil des Namens sein, oder?


    nö... local seh ich nirgends. Zumindest wenn ich wie o.g. mounte.


    Gruß
    iNOB

  • Hi,


    leider nicht:


    Code
    root@VDR:~# svdrpsend LSTR
    220 VDR SVDRP VideoDiskRecorder 2.0.6; Mon Jun 30 10:24:35 2014; UTF-8
    250-1 15.06.14 14:55 3:15<U+E010> Sex and the City - Der Film~2014.06.15-15:05-So


    Ich suche mir per Script Aufnahmen auf meinem NAS mit LSTR und move die ID in Unterordner.
    Dabei wird momentan die Aufnahme immer nach lokal verschoben bzw. kopiert.

  • ich habe zwar keine Ahnung, um was es hier genau geht, aber wenn man an die Info Datei einer Aufnahme nicht mehr per

    Code
    const cRecordingInfo *info = recording->Info();


    (wobei recording ein cRecording Objekt ist) an die Info Datei der Aufnahme ran kommt, dann läuft definitiv was schief ;) Was anderes mache ich übrigens in nOpacity nicht...


    Das sollte wohl funktionieren, ich konnte mir auch nicht vorstellen, dass da was im Skin schief läuft. :)


    Lars.

  • nö... local seh ich nirgends. Zumindest wenn ich wie o.g. mounte.


    Ja, hast recht. Man sieht die Namen der Aufnahmen, wie sie im OSD benutzt werden.


    Lars.

  • Code
    ~$ svdrpsend help lstr
    220 hdvdr SVDRP VideoDiskRecorder 2.1.6; Mon Jun 30 10:53:30 2014; UTF-8
    214-LSTR [ <number> [ path ] ]
    214-    List recordings. Without option, all recordings are listed. Otherwise
    214-    the information for the given recording is listed. If a recording
    214-    number and the keyword 'path' is given, the actual file name of that
    214-    recording's directory is listed.
    214 End of HELP info


    Mit normalen LSTR wird nur der "Name" einer Aufnahme angezeigt, wenn ihr den Pfad haben wollt, dann müsst ihr den über

    Code
    LSTR <number> path


    ermitteln:

    Code
    $ svdrpsend lstr 417 path
    220 hdvdr SVDRP VideoDiskRecorder 2.1.6; Mon Jun 30 10:54:03 2014; UTF-8
    250 /srv/vdr/video.00/server(nfs)/How_I_Met_Your_Mother/117_-_S06E05_-_Der_Architekt_der_Vernich/2013-07-15.16.25.8-0.rec
    221 hdvdr closing connection


    Ist jetzt zumindest erst mal als Workaround gedacht. Ich muss erst mal überlegen, wie und ob ich da was am Patch ändere/ändern kann, damit es auch anders geht.
    Aber eigentlich finde ich es so, wie es gerade ist, eigentlich richtig.


    Oder ihr benutzt dbus2vdr, da bekommt ihr viele wertvolle Informationen zu einer Aufnahme mit einem Aufruf:

    Code
    $ vdr-dbus-send /Recordings recording.Get variant:int32:417



    Insbesondere, falls ihr Python o.ä. benutzt, bekommt ihr relativ einfach die ganzen Daten als Objekt zurück und könnt es auswerten, ohne grep o.ä. zu benutzen.
    Hier ist ein Beispiel, wie man den nächsten Timer abfragt:
    https://github.com/flensrocker…master/bin/dbus-client.py


    Lars.

  • Das scheint zu passen:

    Code
    svdrpsend lstr 417 path
    220 XVDR1 SVDRP VideoDiskRecorder 2.1.6; Mon Jun 30 14:12:17 2014; UTF-8
    250 /srv/vdr/video/local/%Alles_eine_Frage_der_Zeit/2014-06-15.20.15.70-0.rec


    Bin grad am Überlegen, wann Aufnahmen meinerseits verschoben werden. Meist nur aus zwei Gründen:
    1. Falls der Timer einen Untertitel enthält, legt der VDR einen neuen Ordner mit einem Unterordner(=Aufnahmeverzeichnis) an. Da muss ich den Unterordner wieder zurück ins Hauptverzeichnis verschieben.
    2. Falls ich Aufnahmen manuell nach Doku oder Musik verschieben muss (!=Serie).


    Ersteres mache ich mit einem selbstgebauten Script, welches sich leicht abändern läßt, damit es auch "/local" berücksichtigt. Letzters mache ich mit dem extrecmenu-Plugin, welches entsprechend gepatched werden müsste. Wobei ich auf extrecmenu ungern verzichten möchte, da ich damit meine Sortierreihenfolge (Verzeichnisse zuerst, absteigend nach Datum) geregelt bekomme. Die VDR eigenen Funktionen zum Verschieben sind mir zu umständlich, außerdem passt mir da die Sortierreihenfolge nicht.


    Gruß
    iNOB

  • Zumindest vdr 2.1.6 hat eine Einstellung "AlwaysSortFoldersFirst" in der setup.conf und mit der Null kann man die Sortierung pro Verzeichnis so einstellen, wie man es möchte. Ich weiß jetzt aber nicht, ob es da auch "absteigend" gibt.


    Werbung in eigener Sache: Schon mal das Plugin "recsearch" ausprobiert? Da kannst du eine Suchvorlage hinterlegen, die dir dann alle neuen Aufnahmen anzeigt bzw. die Aufnahmen der letzten x Tage... :)


    Lars.

  • Eine absteigende Sortierung (egal ob Datum/A-Z) gibt der 2.1.6er VDR leider nicht her. Ich möchte bei Druck auf die rote Taste das Aufzeichnungsverzeichnis angezeigt bekommen und ohne zu Scrollen bzw. einen weiteren Button zu drücken, sofort sehen was es Neues gibt. Wobei die Ordner (Serien, Doku, Musik...) oben stehen und die restlichen Aufnahmen nach Datum absteigend sortiert sind.


    Mit diesem Wunsch bin ich nicht der Einzige, aber das wäre jetzt zu mühsam, da weiter zu diskutieren. Mag ja sein, dass es Löschfanatiker mit Winzplatten gibt, die sich nicht vorstellen können, mehr als 2 Aufnahmen im Aufzeichnungsordner zu haben. Das sind die Gleichen, die auch den Papierkorb unter Windows leeren, bevor sie ihren Rechner runterfahren ;) Denen isses auch egal, wie rum sortiert wird. Ich gehöre sicher nicht zu dieser Fraktion.


    Gruß
    iNOB

  • Mich interessiert eigentlich auch am ehesten, was neu ist. Deshalb hab ich ja recsearch geschrieben. :)
    vdr 2.1.6 bietet Plugins die Möglichkeit, die Aufnahmeliste zu filtern. D.h. man muss nicht wie in extrecmenu das ganze Menü nachbauen, sondern kann einfach das vorhandene nutzen (inkl. reccmds usw.).


    https://github.com/flensrocker…search/blob/master/README
    Suchvorlage mit "zeige mir nur die neuen an" bzw. "zeige die Aufnahmen der letzten 7 Tage", Hotkey zuweisen und dann in den keymacros diese Suchvorlage auf eine User-Taste legen - fertig (oder den Hauptmenüeintrag benutzen).


    Für ältere Versionen bringt recsearch eine Kopie des vdr-Aufnahmemenüs mit.


    Lars.

  • Hi Lars,


    bevor ich hier immer rummecker, erstmal nochmal Danke für den hide-first-recording-level Patch.
    Der WAF der verteilten VDR Infrastruktur ist um 200% gestiegen ;)


    ich glaube das Live-Plugin mag nur noch nicht damit richtig umgehen.
    Wenn man eine Aufnahme umbenennt oder verschiebt, bekommt es nichts vom "local~" oder "xyz~" mit.
    Die Aufnahme landet im Root von /srv/vdr/video.00 und macht die Systemplatte voll :(



    VG
    Timo

  • Wenn man eine Aufnahme umbenennt oder verschiebt, bekommt es nichts vom "local~" oder "xyz~" mit.

    Das muss man bislang jeweils mit angeben, wo die hin soll.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Falls es der Patch in den vdr schaffen sollte, werde ich sicherlich auch noch was nachliefern für live, damit es diese Option auch beachtet.
    Ziel ist es auf alle Fälle, dass man immer den kompletten Pfad angeben muss, weil man sonst nicht zwischen den Platten hin und her kopieren kann.


    Lars.

  • Nur eine kleine Gedankenkhilfe für mich und andere ;)


    Ich nutze bspw. den VDR ausschliesslich über XBMC via VNSI.
    Mit dem HFRL-Patch wird das Timeshift Buffer File gewöhnlich im Recording Verzeichnis unter /srv/vdr/video.00 abgelegt.
    Da VNSI vom Patch nix weiß kann man mithilfe der folgenden Setup Config das Buffer File woanders ablegen:


    vnsiserver.TimeshiftBufferDir = /recording/local

  • Moin!


    Anbei ein aktualisierter Patch für vdr 2.2.0, der auch ein Problem beim Umsortieren der Anzeige behebt.


    Lars.

  • Moin!


    Ich hab den Patch noch mal überarbeitet. Mir gefiel nicht, dass über alle Videoverzeichnisse nach dem aktuellen Pfad gesucht wurde.


    Ich hab jetzt eine Klasse cRecordings::cFolderInfos eingebaut, die ich so ähnlich schon für den skindesigner erstellt habe. Damit lassen sich für beliebige Ordner in der Aufnahmestruktur diverse Infos auslesen, wie Anzahl der Aufnahmen, Datum der neuesten Aufnahme und jetzt eben auch die ersten Verzeichnisebenen, in denen der aktuell angezeigte Pfad liegt. Es wird dann (sofern vorhanden) die .sort-Datei in "local/" bevorzugt. Damit kann jeder vdr in einem zusammengeführten Verzeichnis seine eigene Sortierung ablegen, solange es eben auch mindestens einen Eintrag im lokalen Pfad gibt.


    Die folder-infos ließen sich auch noch für andere lustige Dinge benutzen...


    Lars.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!