Beiträge von kamel5

Zitat von bakaroo

ZFS bedingt FreeBSD.

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

Zitat von bakaroo

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

Zitat von bakaroo

Ä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.

Zitat von bakaroo

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.

Zitat von bakaroo

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

Zitat von bakaroo

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.

Zitat von bakaroo

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.

Zitat von bakaroo

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

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

Zitat von bakaroo

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.

Zitat von bakaroo

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:

Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: 1239 Fonts available:
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 0: AR PL UMing CN:Light
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 1: AR PL UMing HK:Light
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 2: AR PL UMing TW MBE:Light
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 3: AR PL UMing TW:Light
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 4: Abyssinica SIL:Regular
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 5: AharoniCLM:Bold
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 6: AharoniCLM:Bold Oblique
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 7: AharoniCLM:Oblique
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 8: AharoniCLM:Regular
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 9: Android Emoji:Regular
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 10: AnjaliOldLipi:Regular
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 11: Bitstream Charter:Bold
Nov 03 12:10:13 vdr[37701]: [37785] skindesigner: font 12: Bitstream Charter:Bold Italic
.
.
.

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:

ls -la /usr/share/fonts/VDROpenSans/
nsgesamt 2050
drwxr-xr-x   2 root root     20 22. Jul 2020   .
drwxr-xr-x 124 root root    134 13. Okt 12:44  ..
-rw-r--r--   1 root root  11323 10. Okt 2014  'Apache License.txt'
-rw-rw-r--   1 root root  24896  1. Feb 1999   DS-DIGIB.TTF
-rw-rw-r--   1 root root  24676  1. Feb 1999   DS-DIGII.TTF
-rw-rw-r--   1 root root  24448  1. Feb 1999   DS-DIGI.TTF
-rw-rw-r--   1 root root  25480  1. Feb 1999   DS-DIGIT.TTF
-rw-r--r--   1 root root 726752 22. Jul 2020   Lato-Bold.ttf
-rw-r--r--   1 root root 726328 22. Jul 2020   Lato-Regular.ttf
-rw-r--r--   1 root root     36 14. Mai 2018   .uuid
-rw-r--r--   1 root root 114584 10. Okt 2014   VDROpenSans-BoldItalic.ttf
-rw-r--r--   1 root root 125932 10. Okt 2014   VDROpenSans-Bold.ttf
-rw-r--r--   1 root root 114768 10. Okt 2014   VDROpenSans-ExtraBoldItalic.ttf
-rw-r--r--   1 root root 123960 10. Okt 2014   VDROpenSans-ExtraBold.ttf
-rw-r--r--   1 root root 114100 10. Okt 2014   VDROpenSans-Italic.ttf
-rw-r--r--   1 root root 114484 10. Okt 2014   VDROpenSans-LightItalic.ttf
-rw-r--r--   1 root root 123772 10. Okt 2014   VDROpenSans-Light.ttf
-rw-r--r--   1 root root 118664 10. Okt 2014   VDROpenSans-Regular.ttf
-rw-r--r--   1 root root 114192 10. Okt 2014   VDROpenSans-SemiboldItalic.ttf
-rw-r--r--   1 root root 122672 10. Okt 2014   VDROpenSans-Semibold.ttf

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

Zitat von ciax

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.

Zitat von ciax

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:

<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:

    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

Zitat von MegaV0lt

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

Zitat von 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

Zitat von MegaV0lt

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

Zitat von MegaV0lt

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...

Zitat von MegaV0lt

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

Zitat von MegaV0lt

Komm da nicht raus...

Der angehängte Patch sollte das Problem lösen, ich habe es aber selbst nicht getestet.

Außerdem gab es beim make einen Fehler. Du hattest da ein "int w = 0;" vergessen. das ist in dem Patch mit drin.

Ansonsten kannst Du da im skinflatplus nicht viel machen, da das in dem Falle alles LOCKs von außerhalb sind.

Grüße

kamel5

Zitat von MegaV0lt

Kann man die LOCKs vom VDR abfragen?

Ja. Beispiel: Timer

  static const cTimers *GetTimersRead(cStateKey &StateKey, int TimeoutMs = 0);
      ///< Gets the list of timers for read access. If TimeoutMs is given,
      ///< it will wait that long to get a read lock before giving up.
      ///< Otherwise it will wait indefinitely. If no read lock can be
      ///< obtained within the given timeout, NULL will be returned.
      ///< The list is locked and a pointer to it is returned if the state
      ///< of the list is different than the state of the given StateKey.
      ///< If both states are equal, the list of timers has not been modified
      ///< since the last call with the same StateKey, and NULL will be
      ///< returned (and the list is not locked). After the returned list of
      ///< timers is no longer needed, the StateKey's Remove() function must
      ///< be called to release the list. The time between calling
      ///< cTimers::GetTimersRead() and StateKey.Remove() should be as short
      ///< as possible. After calling StateKey.Remove() the list returned from
      ///< this call must not be accessed any more. If you need to access the
      ///< timers again later, a new call to GetTimersRead() must be made.
      ///< A typical code sequence would look like this:
      ///< cStateKey StateKey; 
      ///< if (const cTimers *Timers = cTimers::GetTimersRead(StateKey)) {
      ///<    // access the timers
      ///<    StateKey.Remove();
      ///<    }
  static cTimers *GetTimersWrite(cStateKey &StateKey, int TimeoutMs = 0);
      ///< Gets the list of timers for write access. If TimeoutMs is given,
      ///< it will wait that long to get a write lock before giving up.
      ///< Otherwise it will wait indefinitely. If no write lock can be
      ///< obtained within the given timeout, NULL will be returned.
      ///< If a write lock can be obtained, the list of timers will be
      ///< returned, regardless of the state values of the timers or the 
      ///< given StateKey. After the returned list of timers is no longer
      ///< needed, the StateKey's Remove() function must be called to release
      ///< the list. The time between calling cTimers::GetTimersWrite() and
      ///< StateKey.Remove() should be as short as possible. After calling
      ///< StateKey.Remove() the list returned from this call must not be
      ///< accessed any more. If you need to access the timers again later,
      ///< a new call to GetTimersWrite() must be made. The call
      ///< to StateKey.Remove() will increment the state of the list of
      ///< timers and will copy the new state value to the StateKey. You can
      ///< suppress this by using 'false' as the parameter to the call, in
      ///< which case the state values are left untouched.
      ///< A typical code sequence would look like this:
      ///< cStateKey StateKey;
      ///< if (cTimers *Timers = cTimers::GetTimersWrite(StateKey)) {
      ///<    // access the timers
      ///<    StateKey.Remove();
      ///<    }

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

Zitat von MegaV0lt

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

Zitat von MegaV0lt

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.

Zitat von MegaV0lt

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:

--- a/displaymenu.c
+++ b/displaymenu.c
@@ -1498,14 +1498,14 @@ bool cFlatDisplayMenu::SetItemEvent(const cEvent *Event, int Index, bool Current
     if (Channel) {
         if (Current)
             ItemEventLastChannelName = Channel->Name();
-
+/*
 #if VDRVERSNUM >= 20301
         LOCK_CHANNELS_READ;
         cString ws = cString::sprintf("%d", Channels->MaxNumber());
 #else
         cString ws = cString::sprintf("%d", Channels.MaxNumber());
-#endif
-        w = font->Width(ws);
+#endif*/
+        w = font->Width("8888");
         if (!Channel->GroupSep()) {
             buffer = cString::sprintf("%d", Channel->Number());
             int Width = font->Width(buffer);

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

Zitat von MarkusE

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

Zitat von MarkusE

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

Zitat von SHF

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

Zitat von wla

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

Zitat von MegaV0lt

aber es erscheint der englische Text.

Hast Du den auch die *.po Dateien mit Übersetzungen befüllt.

Grüße

kamel5