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

  • Code
    1. - The code for distributing recordings over several video directories is now
    2. deprecated and disabled by default.
    3. You can re-enable this feature by removing the comment sign ('//') from the beginning
    4. of the line
    5. //#define DEPRECATED_DISTRIBUTED_VIDEODIR // Code enclosed with this macro is ...
    6. in the file videodir.c. Note, though, that this can only be a temporary workaround.
    7. This feature will be completely removed in one of the next developer versions.

    :achdufresseOh nein, bitte nicht!
    Das zerlegt mir das ganze Setup, auch von meinem neuen Server.


    Code
    1. Distributing the video directory over several disks was a useful feature in times when disks were still relatively small, but it also caused serious problems in case one of the disks failed.

    Die Verteilung einer Aufnahme über mehrere Disks ist wirklich nicht oprimal.
    Wenn dass das Problem ist, würde ich das auch gerne übernehmen.
    Allerdings darf es nicht zu eilig sein, vor dem Winter werde ich das wohl nicht schaffen.



    Code
    1. Nowadays hard disks come in sizes measured in terabytes, and tools like "mhddfs" can be used to combine several disks to form one large volume. A recommended method for a relatively safe disk setup in a VDR system is to use two 1TB (or larger) disks and use them as a RAID-1 (mirrored). That way, if one disk fails, you can replace it without data loss.

    Mit der Verwendung einer SSD macht die alte Verteilung sehr viel Sinn!
    Video0 auf eine Partition der SSD, die muss nicht gross sein ein paar wenige GiB genügen.
    Video1 auf eine richtig Grosse HDD, mit einige TB.


    Sinn des Ganzen:
    Die ganzen Informationen liegen auf der SSD und nur Videos auf der HDD.
    Man kann also durch seine Aufnahmen blättern, ohne dass die HDD laufen muss. Und auch der Neuaufbau den Aufnahmen-Baumes geht rasend schnell, weil das alles auf der SSD liegt.
    Die Festplatte läuft dann erst an, wenn man die Wiedergabe einer Aufnahme wirklich startet.


    Dadurch wird maximal Strom gespart und der Lärm verringert. Dabei kommt man aber mit sehr wenigen Start-Stop-Zyklen aus, was die Festplatte schont.
    Ich habe das Setup so schon seit ein paar Jahren am laufen und es hat sich sehr bewährt.



    Ich will das hier auch nicht weiter zuspammen, sollte Diskussionsbedarf zudem Thema bestehen, bitte ein neues Thema öffne, oder mir Bescheid sagen, dann mach Ich das.

    Gruss
    SHF


  • Das yavdr-Team hat einen Patch "xprmtl-03_extra-video-directory.patch" entwickelt, mit dem man zusätzliche Videoverzeichnisse schreibgeschützt on-the-fly ins Aufnahmeverzeichnis einbinden kann. Wäre vielleicht auch ne Lösung.


    Gruß
    iNOB

  • Ich will das hier auch nicht weiter zuspammen, sollte Diskussionsbedarf zudem Thema bestehen, bitte ein neues Thema öffne, oder mir Bescheid sagen, dann mach Ich das.

    Ich denke das könnte sich lohnen, denn in das Problem werden vermutlich auch einige andere laufen.
    Das mit den besseren Zugriffszeiten beim Einlesen des Aufnahmenverzeichnis von der SSD glaube ich sofort.

    Die Festplatte läuft dann erst an, wenn man die Wiedergabe einer Aufnahme wirklich startet.

    Beim Start des Rechners laufen alle lokalen Platten immer an. Wenn man den VDR nicht für Live-TV nutzt sondern er entweder starten lässt um eine Aufnahme zu machen oder oder anzusehen braucht man die HDD ja sowieso.

    Das yavdr-Team hat einen Patch "xprmtl-03_extra-video-directory.patch" entwickelt, mit dem man zusätzliche Videoverzeichnisse schreibgeschützt on-the-fly ins Aufnahmeverzeichnis einbinden kann. Wäre vielleicht auch ne Lösung.

    Der Patch ist sehr hilfreich, wenn man mehrere Aufnahmeverzeichnisse als ein einziges abbilden möchte, aber das bisherige Verhalten erreicht man damit nicht. Schreibgeschützt ist sind die damit eingebundenen Aufnahmen nicht von sich aus (man kann sie also löschen, das Kopieren und Schneiden innerhalb des VDR ist ein anderes Problem, weil der VDR so wie ich das verstanden habe keinen absoluten Pfade für die Aufnahmen berücksichtigt).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Code
    1. - The code for distributing recordings over several video directories is now
    2. deprecated and disabled by default.
    3. You can re-enable this feature by removing the comment sign ('//') from the beginning
    4. of the line
    5. //#define DEPRECATED_DISTRIBUTED_VIDEODIR // Code enclosed with this macro is ...
    6. in the file videodir.c. Note, though, that this can only be a temporary workaround.
    7. This feature will be completely removed in one of the next developer versions.

    :achdufresseOh nein, bitte nicht!
    Das zerlegt mir das ganze Setup, auch von meinem neuen Server.


    Kompromissvorschlag: das jetzige cVideoDirectory wird zu einer virtuellen Basisklasse, deren Default-Implementierung ein einziges, großes Verzeichnis annimmt. Ein Plugin kann dann eine beliebige andere Verwaltung implementieren. Damit habe ich diese Komplexität aus dem VDR Core raus und wer will, kann sich sein eigenes Süppchen kochen ;-).


    Klaus

  • Super Idee! Ein paar Plugin-Schnittstellen an den richtigen Stellen ist der richtige Weg. Der vdr ist ansonsten ja nahezu "fertig". :)


    Lars.

  • mhddfs hatte ich nach der 1. Ankündigung von Klaus mal getestet, war einfach zu konfigurieren und ich war angetan davon. Nach einiger Zeit stellte sich aber herraus, dass es nicht sehr stabil lief und recht viel CPU verbrauchte, daher habe ich es wieder rausgeschmissen.


    vdr-User-# 755 to_h264 chk_r

  • Dann ist es doch gut, wenn das gewünschte Verhalten über Plugins umgesetzt werden kann.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Sinn des Ganzen:
    Die ganzen Informationen liegen auf der SSD und nur Videos auf der HDD.
    Man kann also durch seine Aufnahmen blättern, ohne dass die HDD laufen muss. Und auch der Neuaufbau den Aufnahmen-Baumes geht rasend schnell, weil das alles auf der SSD liegt.


    Dies verstehe ich nicht. Das Einlesen von SSD sollte viellecht ein paar ms schneller gehen als von HDD. Wir sprechen hier von ms.
    Dies sollte nur beim starten passieren oder nach einem touch .update.
    Ansonsten sollte der Aufnahmebaum komplette im Speicher sein.
    (Ich kann mich hier täuschen, aber so denke ich es funktioniert und ist meine Erfahrung.)


    Erst wenn die Aufnahme gestartet wird habe ich meist eine Pause von 30s - 1 Minute bis die Platte hochgefahren ist.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Ich denke das könnte sich lohnen, denn in das Problem werden vermutlich auch einige andere laufen.

    Nu is zu spät :gap.
    Wenn es etwa bei dem Umfang bleibt, denke ich, ist das noch ok so.
    Sollte es noch deutlich mehr werden, werde ich einen Mod um die Trennung bitte.


    Das mit den besseren Zugriffszeiten beim Einlesen des Aufnahmenverzeichnis von der SSD glaube ich sofort.

    Selbst bei meiner (noch) Produktiv-Krücke mit lediglich UDMA33 ist das schon drastisch.
    Ich rede da von mehr oder weniger sofort da gegenüber mehreren 10 Sekunden!


    Kompromissvorschlag: das jetzige cVideoDirectory wird zu einer virtuellen Basisklasse, deren Default-Implementierung ein einziges, großes Verzeichnis annimmt. Ein Plugin kann dann eine beliebige andere Verwaltung implementieren. Damit habe ich diese Komplexität aus dem VDR Core raus und wer will, kann sich sein eigenes Süppchen kochen ;-).

    Kompromiss?
    Ich würde da schon fast von der Ideallösung für alle Seiten sprechen :D . :tup


    Super Idee! Ein paar Plugin-Schnittstellen an den richtigen Stellen ist der richtige Weg. Der vdr ist ansonsten ja nahezu "fertig". :)

    Wenn man so mit "Mini-Plugins" die Flut der, inzwischen unsäglich vielen, Patches in den Griff bekommt würde ich das auch sehr begrüssen.


    Das soll jetzt aber bitte nicht als Forderung oder Drängen meinerseits aufgefasst werden. Eher als Angebot auch was von der "Drecksarbeit" abzunehmen.
    So ein zwei solche "Mini-Plugins", aktuell zu halten traue ich mir als Gelegenheits-Programmierer mit eher knappem Zeitbudget schon zu. Da würde ich mich auch gerne Einbringen.
    Bei grösseren Geschichten scheitert es bei mir meist am Wissen, bzw. eigentlich an der Zeit sich in das Thema ausreichend einzuarbeiten.


    Beim Herunterfahren komischerweise auch. Daher habe ich es bei mir wieder abgestellt. Die Platte läuft jetzt wieder durch.

    Bei mir laufen auch noch andere Dienste auf dem VDR-Rechner.
    Das Runterfahren der Platten spart bei mir daher 5-6 Stunden Plattenlaufzeit am Tag.
    Erzeugt dabei aber 3-4 zusätzliche Start-Stop-Zyklen. Die würden aber genauso auftreten, wenn nur der VDR auf dem Computer laufen würde, da er den dann ja ganz ausschalten würde.


    Der erste HDD-Satz ist übrigens nach rund 40000 Stunden Laufzeit getauscht worden, weil die mir zu klein wurden. Mit den Start-Stop-Zyklen gab es nie ein Problem. Inzwischen sind die Platten an die Verwandschaft verschenkt und laufen da noch immer einwandfrei.
    Sich wegen einer Hand voll zusätzlichen Start-Stop-Zyklen pro Tag eine Kopf zu machen halte ich daher für völlig übertrieben.
    Wenn man es übertreibt und die Platten schon nach einer Minute Inaktivität anhalten will ist das natürlich wieder was anderes...



    Erst wenn die Aufnahme gestartet wird habe ich meist eine Pause von 30s - 1 Minute bis die Platte hochgefahren ist.

    Stimmt schon. Spätestens, wenn man die Info anschaut läuft bei dir die Platte aber auch schon an.
    Ich kann mir auch die Info anschauen, ohne dass die Platte anläuft. Das klappt so sogar über das Netzwerk beim Zugriff via zB. Samba.


    Mir ist es damals auch ab und an beim navigieren durch die Aufnahmen-Struktur passiert. Kann aber sein, dass das bei einer aktuellen VDR-Version nicht mehr auftritt.


    mhddfs hatte ich nach der 1. Ankündigung von Klaus mal getestet, war einfach zu konfigurieren und ich war angetan davon. Nach einiger Zeit stellte sich aber herraus, dass es nicht sehr stabil lief und recht viel CPU verbrauchte, daher habe ich es wieder rausgeschmissen.

    Bei mir ist der Versuch das via union-fs aufzusetzen, aus ähnlichen Gründen nicht über das Bastelstadium hinaus gekommen.


    Die Lösung mit den Symlinks mag etwas "zusammen gezimmert" erscheinen, aber sofern man genug Inodes hat läuft das sehr zuverlässig und das schon über Jahre. Und darauf kommt es letztendlich ja an.

    Gruss
    SHF


  • Moin!


    Kompromissvorschlag: das jetzige cVideoDirectory wird zu einer virtuellen Basisklasse, deren Default-Implementierung ein einziges, großes Verzeichnis annimmt. Ein Plugin kann dann eine beliebige andere Verwaltung implementieren. Damit habe ich diese Komplexität aus dem VDR Core raus und wer will, kann sich sein eigenes Süppchen kochen ;-).


    Da noch eine Anmerkung zu:
    Ich bastel schon einige Zeit an einem Patch, der es ermöglicht, während der Laufzeit des vdrs ihm beliebige zusätzliche Verzeichnisse unterzujubeln, die Aufnahmen enthalten (geistert als "extra video directories patch" in yavdr herum, hab ihn gerade mal im dbus2vdr-git abgelegt, allerdings noch gegen vdr 2.0.2: https://github.com/flensrocker…travideodirectories.patch).


    Ziel war es, dass die Aufnahmen von verschiedenen vdrs im LAN per NFS "irgendwo hin" gemountet werden, und diese Verzeichnisse dann dynamisch im vdr eingebunden werden. Das cRecording-Objekt hat dann noch ein zusätzliches Feld mit dem zugehörigen Basis-Videoverzeichnis bekommen, damit alle Aufnahmen in einer gemeinsamen Liste angezeigt werden können, ohne pro vdr ein Unterverzeichnis haben zu müssen.


    Hintergrund: Wenn man seine Aufnahmen z.B. so organisiert, dass die Serien in einem entsprechenden Unterorder liegen, muss man nur in diesem Ordner nachsehen und hat dann alle Aufnahmen so im OSD, als ob sie in einem Verzeichnis liegen. Die dürfen sogar identische Namen und Zeitstempel haben, sie werden trotzdem nebeneinander dargestellt (was mit einem Overlay-FS ja evtl. zu Problemen führen kann). Und man muss dann eben auch nicht durch "vdr1/Serien", "vdr2/Serien" usw. blättern, wenn man eine bestimmte Serie/Folge o.ä. sucht.


    Wäre toll, wenn du so eine Möglichkeit an Funktionalität (eine Aufnahmeliste für alle Video-Directories) bei der Plugin-Schnittstelle berücksichtigen könntest.
    Ich wollte es nur mal aufschreiben, damit ich es nicht vergesse.


    Ach ja, Aufnahmen landen immer in dem Haupt-Video-Verzeichnis, also dem, dass per "--video" bzw. Make.config konfiguriert wurde. Das ermöglicht auch das Einbinden von read-only-Aufnahmeverzeichnissen, die z.B. auf einer DVD oder einer externen Platte liegen.


    Noch ein Anwendungsbeispiel: Das Anstöpseln einer externen Platte mit vdr-Aufnahmen wird per udev als solches erkannt (durch eine magische Regel, da wird sich irgendwas finden) und dann automatisch in den vdr eingebunden und eine Aktualisierung der Aufnahmeliste angestoßen. Und schon hat man Zugriff auf die Aufnahmen.
    Und das Abstöpseln löst das Verzeichnis wieder aus dem vdr und aktualisiert die Aufnahmeliste wieder.


    Wie ich die Aufnahmen auch noch irgendwie verteilt ablegen können soll, überlege ich mir noch. Auf alle Fälle wird man es jedem Video-Dir mitgeben können, ob es für Aufnahmen benutzt werden darf oder nicht.
    Das Verteilen von Aufnahmen auf mehrere Verzeichnisse war für mich zweitrangig, deshalb gibt's da noch nichts von meiner Seite aus. Abspielen war mir wichtiger.


    Das sind nur so grob meine Ideen zu verteilten Video-Verzeichnissen, ich freue mich schon darauf, das irgendwann als Plugin bauen zu dürfen. Mal sehen, ob mir schon ein Prototyp für eine API einfällt. Damit ich vorbereitet bin, wenn du dir eine ausgedacht hast. Erwarte das aber nicht so bald von mir, ich tu's auch nicht. :)


    Lars.

  • mini73
    So ganz habe ich noch nicht verstanden warum Du dafuer einen VDR Patch benoetigst.
    Unter Gen2VDR habe ich das so geloest, dass beim Anstoepseln einer Platte die Aufnahmen darauf dementsprechend ins VideoVerzeichnis des VDR verlinkt werden und VDR gesagt wird er soll neu einlesen.
    Das geht auch prima ohne VDR Patch :)

  • helau
    Werden alle Aufnahmen einzeln verlinkt oder einfach nur die Platte in ein Unterverzeichnis?
    Wenn mit Unterverzeichnis: genau das möchte ich nicht. Und alle Aufnahmen einzeln zu verlinken stelle ich mir aufwendig vor, insbesondere das Aufräumen, wenn man die Platte wieder abzieht.


    Und was passiert, wenn du lokal eine Aufnahme "Der Film" hast und auf der externen Platte auch? Wie sieht dann der Link aus?
    Bei mir werden die beiden Filme nebeneinander in der Aufnahmeliste dargestellt und man kann beide problemlos abspielen.


    Oder stelle dir vor, die Folgen einer Serie verteilen sich über mehrere Platten. Mit meiner Vorgehensweise landen sie alle im gleichen Ordner im OSD, so dass man nicht suchen muss.


    Ich hoffe, ich konnte es einigermaßen erklären.


    Ich sag ja auch nicht, das meine DIE Lösung ist, ich wollte nur erwähnen, wie ich mir das vorstelle. :)


    Lars.

  • mini73 : Ehrlich gesagt bin ich von dieser Idee nicht besonders begeistert. Ich bin ja immer bestrebt, Dinge lieber zu vereinfachen als sie zu verkomplizieren (daher auch der "Rauswurf" des verteilten Video-Directories). Ein solches "Mischen" von Platten würde nur wieder eine neue Komplexität schaffen. Da finde ich einen Ansatz wie von helau deutlich einfacher und besser.


    Klaus

  • Das von SHF beschriebene Szenario kenne ich schon auch.
    "Damals" war das Problem das irgendwie jedes Plugin und/oder Patch die Aufnahmen andauernd selbst eingelesen und neu berechnet hat, anstatt auf die Daten des VDR zuzugreifen.
    Müsste man nochmal checken wie der aktuelle Stand ist, beim "Zugriff vermeiden". Wenn(!!) wirklich noch nötig, kann man evtl die Verwaltungsdaten seperat halten ohne die elende Verlinkerei.


    Der besagte Patch von Lars hätte auch den netten Nebeneffekt NICHT die komplette Liste neu einzulesen wenn mal eine neue Aufnahme hinzukommt (von DVD/externer Platte/Netzwerk) - fände ich persönlich sehr angenehm. Davon abgesehen sollte inotify&Co inzwischen auch stabil genug sein um im VDR verwendet werden zu können.

  • Unter Gen2VDR habe ich das so geloest, dass beim Anstoepseln einer Platte die Aufnahmen darauf dementsprechend ins VideoVerzeichnis des VDR verlinkt werden und VDR gesagt wird er soll neu einlesen.


    Das ist auch unter yaVDR momentan so gelöst. Bei Lokalen Platten und reinem VDR-Betrieb finde ich das auch weniger störend (bis auf den Umstand, dass die Unterverzeichnisse es etwas unübersichtlich machen). Bei NFS-Freigaben muss man aber bei sich gegenseitig mountenden VDRs aufpassen, dass keine zirkulären Mounts entstehen (ist ein potentielles Problem mit dem Avahi-Mounter in yaVDR).


    Interessant wird es aber z.B. bei XBMC, weil man damit definierte Ordner (Filme, Serien) im Aufnahmeverzeichnis für die Scraper schaffen kann (bei Nutzung eines PVR-Addons) und dann alles direkt passend eingelesen werden kann, sobald der VDR es in seiner Aufnahmenliste hat. Wenn man den direkten Vergleich (für über Avahi angekündigte NFS-Freigaben) haben will, kann man mit dem avahi-linker spielen (der beherrscht beide Varianten Verlinken und Nutzung des Extra Video Directory Patch): https://github.com/seahawk1986/arch-avahi-linker

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • kls :
    Das hört sich alles viel schlimmer an, als es in Wirklichkeit ist. Und es ist bis jetzt ja auch nur eine erste Umsetzung einer Idee. Ob sie sich bewährt und wie/ob man sie später auch so umsetzen kann, wird sich zeigen.


    Lars.

  • Directories). Ein solches "Mischen" von Platten würde nur wieder eine neue Komplexität schaffen. Da finde ich einen Ansatz wie von helau deutlich einfacher und besser.


    Nur damit da kein falscher Eindruck entsteht. Wenn helaus Ansatz darin besteht, dass er die externe Platte in ein Unterverzeichnis im Video-Dir mountet, dann kann das yaVDR schon ewig und drei Tage. Das Selbe gilt übrigens auch für alle Video-Dirs aller yaVDRs im selben Netz, die sind vollkommen automatisch und ohne Patches für jeden VDR erreichbar.


    kls : ich verstehe deine Bedenken und begrüße deshalb deine Idee diesen Teil in ein Plugin auszulagern. Ich bin auch für geringe Komplexität, aber es gelingt mir nicht meiner Familie sinnvoll zu begründen, warum sie bei der Suche nach einem Film erstmal im Hauptverzeichnis scrollen soll und danach auch noch im Verzeichnis des Servers auf die Suche gehen muss. Mit dem Patch steht alles wunderbar untereinander und die Struktur von Filesystemen interessiert meine Kinder nicht sonderlich . Ich wünsche mir eben weniger Komplexität bei der Bedienung. Da das mein eigenes Problem ist und ich es nicht zu deinem machen will, begrüße ich sehr wenn man die Thematik in ein Plugin auslagern könnte.


    Upps, die Kollegen waren schneller als ich, ich wurde gestört.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Wenn eine neue API-Funktion, dann bitte so aufbauen, dass man Metadaten und Videodaten an getrennte Pfade "routen" kann. Ich hätte gerne meine Metadaten mit auf der SSD, die Videodaten (also alles was viel Platz braucht) dann aber doch lieber auf der großen Festplatte.


    Das wird Sache des Plugins sein, ob es überhaupt irgendwelche Video-Dateien auf die erste Platte schreibt oder nicht. Alles außer den *.ts-Dateien landet wie bisher auf der ersten Platte, da wird das Plugin gar nicht gefragt.


    Klaus