Posts by kamel5

    ZFS bedingt FreeBSD.

    Nicht unbedingt. Das kann man auch in normalen Linux-Distributionen nachinstallieren...

    Beim Essen habe ich ein wenig darüber gegrübelt.

    Das ist natürlich ein beträchtlicher Aufwand für dieses Ziel.


    Das was der VDR im Speicher von den Recordings vorhält, wird ja in einer Liste cList<cRecording> gespeichert. Vielleicht wäre es einfacher mal darüber nachzudenken, diese Liste beim Beenden des VDR lokal abzuspeichern und beim Starten wieder einzulesen und dann nur noch ein Update zu machen. Dann könnte der Rest so bleiben wie er ist.


    Grüße

    kamel5

    Ähm, nach meinen Verständnis lädt ein VDR-Client die Aufnahmeliste nicht vom vom VDR-Server (hier als Programm gemeint), sondern holt sie sich aus dem Verzeichnisbaum des angebotenen Share, quasi per opendir().

    Ich meinte, rein über nfs. Auf meinem Server läuft kein VDR.

    Daß ein VDR-Server den kompletten Verzeichnisbaum im Filesystem-Buffer hat, würde ich mal optimistisch als "Zufall" betrachten.

    Ich habe mich vor Jahren, genau aus diesem Grunde (hohe Anzahl von Aufnahmen auf dem Server auf HDD ist natürlich beim Einlesen langsam) für zfs als Filesystem entschieden. Dadurch kann ich als Dateisystem-Cache eine SSD verwenden. Aber auch nach einem Server-Neustart, da ist der SSD-Cache noch leer, dauert es bei dieser Menge nur ca. 1min.


    Was ich damit auch nur sagen will, bevor man am VDR selbst etwas ändert, sollte man sich sicher sein, alle anderen Möglichkeiten ausgeschöpft zu haben.

    Obwohl der zu messende Datendurchsatz (6,5 GB in unter zwei Minuten per cp von remote file zu local file) mehr als ausreichend ist, ist ein Verzeichnisscan in der Größe nicht wirklich was für Ungeduldige.

    Das ist ja z.B. nur die halbe Miete. Das Einlesen der Aufnahmen bedeutet Lesen vieler kleiner Dateien (random seek).

    Die Platten in meinem VDR sind z.B. älter als die Platten in meinem Server, da dauert das Einlesen gefühlt auch deutlich länger.


    Und klar, solche Probleme sind auch manchmal schwierig zu beheben.


    Grüße

    kamel5

    Diese Platten habe ich spasseshalber mal in eine Kiste gepackt, mit einer dieser VDRs gestartet, die anderen lokal in Unterverzeicnissen unter Video hinzugemountet sowie per nfs4 exportiert. Ergo: alles ganz normal.

    Heist das jetzt, wen Du die Platten direkt an einen von den VDR's anschließt, die sonst nicht richtig funktionieren oder langsam sind, geht es dann ohne Probleme. Das würde dann doch eher auf ein Konfigurationsproblem hinweisen.


    Apropos Ladedauer: bei mir dauert das einlesen vom Server (ca.11000 Aufnahmen) etwa 1min (nach einem Server Neustart). Wenn der Server Cache befüllt ist, weniger als die Hälfte der Zeit.

    Auch schaffen die VDRs es nicht, beim Einschalten sich eine vollständige Liste zu holen.

    Das Einlesen hat einen Timeout. Wenn die Daten vom Server nicht mehr kommen, wird lokal weiter gemacht. Ich nutze das z.B. um den VDR auch ohne aktivem Server zu starten.

    Sie benötigen mindestens 1x "Aufnahmeliste aktualisieren".

    Das deutet doch darauf hin, das der Server die Daten nicht schnell genug liefert.

    Und die beiden kleinen mit nur 2GB RAM stürzen dann gelegentlich mal ab.

    Was läuft den da noch so drauf? Wenn es nur der VDR ist, sollte das eigentlich reichen.

    Dazu müsste aber recordings.c so umgebaut werden, daß die Liste nicht per "full Directoryscan to Ram", sondern OnDemand in Scheiben geliefert werden.

    Man könnte da sicher einiges optimieren, die Frage ist allerdings, mit welchem Aufwand und ob es dann auch hilft.


    Grüße

    kamel5

    Hier:

    Setup and Layout of a XML Skin · Wiki · Karl Melscher / SkinDesigner · GitLab
    A VDR skinning engine that displays XML based Skins
    gitlab.com

    steht unter 1.3 etwas dazu.


    Du kannst alle Schriften benutzen, die im VDR-Setup->Einstellungen->OSD unter Schriftart auswählbar sind, auch wenn sie dort nicht eingestellt sind.

    Die Schriftarten, die der skindesigner kennt, lassen sich mit "svdrpsend plug skindesigner LSTF" anzeigen (im normalen syslog).

    Das sieht dann etwa so aus:

    Diese angezeigten Schriften kannst Du dann in der "globals.xml" unter "fonts" eintragen, wie z.B. bei estuary4vdr.


    Um zusätzliche Schriften zu nutzen, müssen sie im System installiert sein, bei mir z.B. unter "/usr/share/fonts". Ich habe die vom VDR benutzten Schriften da in einen Unterordner abgespeichert:

    Nach einem Neustart sollten sie dann auch vom skindesigner benutzbar sein.

    Kommen hier die fonts (ttf-Files) in einen Unterordner (zB. fonts wie bei estuary4vdr) unterhalb des Verzecihnisses, in dem auch die globals.xml des Skin zu finden ist. Und wie soll hie der "Aufbau" sein (für jeden Skin ein Subfolder?

    Nein, siehe oben. Die Fonts liegen dort nur in dem Unterordner, damit sie vom User installiert werden können.

    Wie soll der Name sein (frei wählbar in globals.xml - genau gemapped zum ttf-Dateinamen)? Im o.a. Beispiel verstehe ich nicht, was es bei der Schrift "digital" mit "DS-Digital:Normal" auf sich hat. Ich würde es gerne für Skin "blackhole" richtig machen - also für die benötigten Schriften "DS-Digital" und "Source San Pro".

    Der Name ist frei wählbar, muss dann aber in den entsprechenden xml-Dateien genau so benutzt werden.


    Beispiel im Abschnitt fonts:

    Code
    <font name="digital">DS-Digital:Normal</font>

    Vorn steht der Name (frei wählbar) für die spätere Benutzung: name="digital"

    Danach steht dann der zu benutzende Fontname (obige Liste rechter Teil): DS-Digital:Normal

    aus der Liste: "Nov 03 11:25:58 vdr[2833]: [5010] skindesigner: font 86: DS-Digital:Normal"


    Grüße

    kamel5

    OK, sehr schön.


    Jetzt könnte man auch noch dafür sorgen, das diese Anzeige bei Änderungen aktualisiert wird.

    Dazu könntest Du in Flush() noch folgendes eintragen:

    Code
        if (cVideoDiskUsage::HasChanged(VideoDiskUsageState))
            TopBarEnableDiskUsage();

    Damit wird geprüft, ob es eine Änderung des freien Speicherplatzes gibt und nur dann wird auch die Anzeige aktualisiert.


    Grüße

    kamel5

    Wenn ich die Zeile auskommentiere wird 100% frei angezeigt...

    OK, dann muss das der Skin doch mindestens einmalig aufrufen.

    Das in Flush() könnte aber auch zu spät sein...

    Wenn das in Flush() nichts bringt, kannst Du es auch in cFlatDisplayMenu::cFlatDisplayMenu() mit ans Ende einfügen, das sollte auch keine Problem machen.


    Grüße

    kamel5

    Wenn man sich damit beschäftigt... ;)


    Wenn ich das richtig verstehe, wird im skinflafplus der freie Plattenplatz eh nur einmalig bei Aufruf von SetTitle() angezeigt, d.h. diese Anzeige wird auch nicht aktualisiert, solange SetTitle() nicht erneut aufgerufen wird.

    Da das dann eh nur eine ungefähre Anzeige ist, würde ich das cVideoDiskUsage::HasChanged() doch eher ganz weglassen, da das Unterbringen in Flush() keine wirkliche Verbesserung bedeutet.


    Grüße

    kamel5

    Du brauchst das cVideoDiskUsage::HasChanged() eigentlich gar nicht,

    OK, noch genauer:

    Das cVideoDiskUsage::HasChanged() wird nur gebraucht, wenn die abgefragten Werte ganz aktuell sein sollen.

    Du kannst das cVideoDiskUsage::HasChanged() auch in Flush() unterbringen, da die Werte eh nur alle 5s vom VDR aktualisiert werden, sollte das keine zusätzliche Last bedeuten.


    Grüße

    kamel5

    Kann man nicht einfach cVideoDiskUsage::HasChanged() und cVideoDiskUsage::UsedPercent() (Macht das auch einen LOCK?) auslagern?

    cVideoDiskUsage::UsedPercent() und auch die restlichen cVideoDiskUsage::* haben keinen LOCK.


    Ich habe gerade in meinem skinlcarsng noch mal nachgesehen. Du brauchst das cVideoDiskUsage::HasChanged() eigentlich gar nicht, da das direkt vom VDR gehändelt wird.

    Komentiere doch einfach mal die Zeile mit dem cVideoDiskUsage::HasChanged() aus, und schaue was dann passiert.

    Den Patch kannst Du dann wieder entfernen.


    Grüße

    kamel5

    Leider erscheint nun die Anzeige für den freien Platz auf der Platte etwa zwei Sekunden verzögert.

    Das kann schon passieren. Um das zu verstehen, müsste man analysieren, wie der Programmablauf in skinflatplus ist, und ob da nicht noch an anderer Stelle z.B. ein Flush gemacht wird. Konsequenterweise sollte es erst dann ein Flush geben, wenn alles abgearbeitet ist...


    Ich verstehe auch nicht, warum TopBarEnableDiskUsage(); für die LOCK Warnungen schuld sein soll. In der Funktion gibt es doch gar keine LOCK-Makros. Di eFunktion wird auch noch ein paar mal in baserender.c aufgerufen.

    Das liegt daran, das von epg2vdr bereits LOCKs in cFlatDisplayMenu::SetTitle() vorhanden sind und dann in TopBarEnableDiskUsage() die Funktion cVideoDiskUsage::HasChanged() vom VDR in videodir.c aufgerufen wird, und dort wird dann ein LOCK_RECORDINGS_READ gemacht.

    Das kannst Du nur beheben, wenn Du TopBarEnableDiskUsage() aus SetTitle() heraus nimmst und z.B. in Flush() unterbringst.


    Im Endeffekt müsste man sich mal epg2vdr ansehen und versuchen, die LOCKs etwas anders zu gestalten...


    Grüße

    kamel5

    Kann man die LOCKs vom VDR abfragen?

    Ja. Beispiel: Timer

    Das löst aber, wie kfb77 schon schrieb, Dein Problem in diesem Falle nicht. Das würde nur funktionieren, wenn die LOCKs in nicht voneinander abhängigen Code-Teilen passieren würden.


    Man könnte sich natürlich fragen, warum man das bei 2 Read LOCKs überhaupt beachten sollte, das hat der VDR Entwickler so festgelegt... und Ausschließen, das es dadurch Nebeneffekte geben könnte, kann man auch nicht.


    Grüße

    kamel5

    Leider kein Erfolg

    Das stimmt so nicht ganz, den der erste "invalid lock sequence report" ist ja nun weg, und skinflatplus taucht in dem neuen Report nicht mehr auf.


    Der neue Report sagt ja auch nur, das es noch mehr Probleme gibt, und jetzt wird halt das nächste Problem angezeigt...

    Und so wie der aussieht, wäre live jetzt das nächste Plugin, das mal diesbezüglich angesehen werden müsste.


    Ich würde jetzt erst einmal live deaktivieren und schauen, ob es dann ohne neue Reports funktioniert.

    Man muss sich hier Schritt für Schritt vorarbeiten, bis der letzte Report verschwunden ist.


    Grüße

    kamel5

    Der Fehler kommt da auch.

    Ich habe den Lock sequence nur im Menüpunkt scraper2vdr-Programm.

    An meinem VDR läuft ein Script, das auf Locksequence prüft. Bin mir also sicher, dass es nur in Verbindung mir scraper2vdr kommt.

    Das kann dann auch nur da oder in Live behoben werden.

    Vielen Dank für die schöne Erklärung. Ich begreife das aber nicht. Umsetzen kann ich das auch nicht ;(

    OK, kein Problem. Ich habe mal kurz geschaut, den LOCK brauchst Du ja nur, um die max. Channelnummer (Channels.MaxNumber()) festzustellen, wegen der Zeichenbreite.

    Der einfachste Weg wäre hier, eine feste Breite anzunehmen, z.B. 4 Stellen:

    Möglich wären sicher auch noch viele andere Varianten, dann müsste man sich aber doch intensiver damit beschäftigen...


    Da der "invalid lock sequence report" immer nur beim ersten Auftreten entsteht, dieser Code aber noch in anderen Set* Funktionen benutzt wird, musst Du das dann auch an den anderen Stellen noch ändern.


    Grüße

    kamel5

    Aus dem ersten "begin invalid lock sequence report" kannst Du ableiten, das in cFlatDisplayMenu::SetItemEvent() ein

    "LOCK_CHANNELS_READ" gemacht wird. Da es aber dort vom VDR schon einen "LOCK_SHEDULES_READ" gibt, bekommst Du hier diese Meldung, weil dadurch die Reihenfolge der LOCKs nicht stimmt. Das kannst Du auch in dieser Funktion nicht auflösen.

    Die richtige Reihenfolge der LOCKs ist 1.Timers, 2. Channels, 3. Recordings, 4. DelRecordings und 5. Shedules.


    Ich habe mir angewöhnt keine LOCKs in den Set* Funktionen, die direkt vom VDR aufgerufen werden, zu benutzen.

    Was kannst Du also tun: das was den "LOCK_CHANNELS_READ" braucht, aus dieser Funktion auszulagern und dann über cFlatDisplayMenu::Flush() bereitzustellen, wie das mit "LOCK_TIMERS_READ" auch schon gemacht wird.

    cFlatDisplayMenu::Flush() enthält keine vom VDR ausgehenden LOCKs.


    Beim zweiten "begin invalid lock sequence report" scheint der Skin nicht involviert zu sein, da das direkt von Live zu kommen scheint. Hier wäre auch die Reihenfolge von "LOCK_SHEDULES_READ" und danach "LOCK_TIMERS_READ" falsch.


    Grüße

    kamel5

    Und das Service Interface gibt dann

    Code
    Ergänzen der Filmreihe Machete Filmreihe, wegen der Aufzeichnung Machete

    aus.

    OK, dann habe ich es doch falsch verstanden. Ich hatte jetzt angenommen, das das dann automatisch in AUX so eingetragen wird.

    Ich finde das etwas unglücklich, da dann ja jeder Skin eine Anpassung machen müsste. Gibt es denn einen Grund, das in einen extra Service zu verpacken. Oder wäre es nicht aus Kompatibilitätsgründen einfacher, das direkt in AUX einzutragen unter "reason", wie bisher, unter Umständen mit einer Konfigurierbarkeit im tvscraper setup.

    Ich verstehe, das das mehr Möglichkeiten eröffnet, ich befürchte aber auch, das es dann ewig dauert, bis es in die Skins eingezogen ist.


    Solange die alte Funktionalität erhalten bleibt, habe ich prinzipiell erst einmal nichts gegen neue Möglichkeiten. ;)


    Grüße

    kamel5

    Die Timer werden neu angelegt, und dabei die zusätzlichen Daten ins aux Feld geschrieben.

    Wenn ich das richtig verstehe, werden neue Timer automatisch mit den neuen Informationen im AUX-Feld vom tvscraper angelegt.


    Da meine Skins bei Aufnahmen den Inhalt des AUX-Feldes der Info-Datei auswerten und dann das, was dort steht, bisher unverändert anzeigen, sollten doch die neuen Informationen automatisch dann mit angezeigt werden...

    Ich würde das dann vorerst auch einmal so lassen.


    Für Timer gilt ja im Prinzip dann das Gleiche, wobei ich im Timer Edit Modus das AUX-Feld bisher nicht auswerte. Darüber könnte ich ja nochmal nachdenken.


    Spontan hätte ich im Moment keinen neuen Anwendungsfall in Petto...


    Grüße

    kamel5

    Konvertieren macht dann der Plex-Server?

    Ja, je nach Notwendigkeit.


    Für die TT6400 gibt es eine Konfigurationsdatei "VDR Plex Plugin.xml", die definiert, was die TT6400 kann. Sie muss in das Verzeichnis "/usr/lib/plexmediaserver/Resources/Profiles" kopiert werden. Nur das, was die Karte nicht kann, wird dann konvertiert.

    Damit das funktioniert, muss man dann noch im VDR-Plex-Plugin Setup "Benutze eigenes Transcoder Profil" auf "Ja" stellen.

    Die Konfigurationsdatei wurde mal vor Jahren, ich glaube hier im Forum, gepostet.

    Ich hänge sie aber auch gerne nochmal an.


    Grüße

    kamel5

    Welche Möglichkeiten gibt es heute eine Datei im {Video-Root] zu selektieren und passend (u.U. schnelles umcodieren on-the-fly) auf die S2-64000 auszugeben?

    Da ist mir nichts bekannt.


    Wie mache ich das:

    1. MKV's bis 1080p30 und Ton AC3 5.1 kann man durch schnelles Neuverpacken mit ffmpeg (z.B. mit dem Skript von jsffm) passend in das Videoverzeichnis einbinden.

    2. Man installiert sich den Plex-Server und das vdr-plex-Plugin und kann dann einfach die mkv in das passende Verzeichnis von Plex kopieren und dann über das Plex-Plugin im VDR direkt abspielen. Das ist meine bevorzugte Variante.


    Grüße

    kamel5