doch das hilft
Na dann:
vdr-link-serien.sh rufe ich händisch auf
vdr-link-filme.sh über die reccmds.conf
Wie oben schon geschrieben, alles ohne Gewähr.
Grüße
kamel5
doch das hilft
Na dann:
vdr-link-serien.sh rufe ich händisch auf
vdr-link-filme.sh über die reccmds.conf
Wie oben schon geschrieben, alles ohne Gewähr.
Grüße
kamel5
Mir ist insbesondere unklar wie Du die EPG Information ins Plex bekommst
Gar nicht. Plex sucht sich selbstständig alle Informationen aus dem Netz, wenn man einen aussagekräftigen Dateinamen verwendet.
einfach vdr-transcode nutzen - kann man alles sauber automatisieren und in Verzeichnisse ablegen die der Plex-Server lesen soll/kann
Es gibt sicher mehrere Möglichkeiten... vdr-transcode habe ich mir diesbezüglich bisher nicht angesehen, weil ich keine Konvertierung brauche, sondern nur einen passenden Dateinamen für den Link.
kannst Du Dein Skript zur Verfügung stellen?
Meine Scripte sind absolut auf meine Verzeichnisstruktur und meine Bedürfnisse angepasst. Da gibt es auch keine Fehlerbehandlung. Bei dem Script für Staffeln wird z.B. vorausgesetzt, das in der Aufnahmen info Datei die Zeile mit dem "D" z.B. so beginnt: "D 4. Staffel, Folge 14:". Ich weis nicht, ob Dir das hilft.
Grüße
kamel5
Ich nutze zwar mittlerweile Plex nicht mehr, sondern jetzt Jellyfin, die Probleme sind da aber die gleichen.
IMHO gibt es 2 Möglichkeiten - entweder mit den recording hook "after", Links für Plex erzeugen oder einen uralten VDR Plex Scraper aus dem Netz zu verwenden. Beides erzeugt nur rudimentäre Links für Plex.
Eine andere Möglichkeit ist mir bisher auch nicht untergekommen. Der "VDR Plex Scraper" funktioniert bei mir auch nicht wirklich, so das ich das bei Filmen händisch mit einem Eintrag in der "reccmds.conf" und für mich passendem bash-script, das dann den entsprechenden Link anlegt, nach dem Schneiden mache. Für Serien habe ich ein extra Script, das dann über die gesamte Serie läuft.
EPG, Fanart, Serienfolgen etc. werden nicht bzw. nicht vernünftig übernommen/dargestellt
Das funktioniert bei mir eigentlich ganz gut, bei einzelnen Sachen muss ich aber auch händisch nacharbeiten.
Wichtig aus meiner Sicht ist, das man keine geteilten ts-Dateien hat, sonst klappt das nicht. Für Plex braucht man ja auch nur diese ts-Datei, alles Andere wird ignoriert. Außerdem muss man die Links entsprechend aussagekräftig benennen. Bei Serien muss unbedingt im Link Serie und Episode enthalten sein, z.B. "Stargate:_Atlantis_S01E01.ts" . Außerdem muss man im plexserver für Filme und Serien verschiedene Scraper auswählen.
Insgesamt bin ich aktuell mit meiner Lösung ganz zufrieden.
Grüße
kamel5
Hallo,
im Anhang mal eine aktuelle Version des Undelete-Patches. Dieser sollte auch mit älteren VDR-Versionen funktionieren.
- Fehlerbereinigung
- Im Setup werden die "UNDELETE"-Optionen nur noch angezeigt, wenn es eine "reccmds.conf" gibt.
Da sich eine Variable geändert hat, ggfls. bitte die Einstellungen im Setup überprüfen.
Grüße
kamel5
Hat das irgendwas damit zu tun, ob beim Start des vdr eine geloeschte Aufnahme vorhanden ist? Oder fehlt da irgendwo eine Initialisierung?
Das Einzige, was ich mir da vorstellen kann, das der VDR mit dem Einlesen der Aufnahmen noch nicht fertig war. Das Feststellen, ob es gelöschte Aufnahmen gibt, wird über eine Core-VDR Funktion realisiert. Ich kann aber auch nicht sagen, ob gelöschte Aufnahmen einen Neustart überleben, das habe ich noch nicht getestet. Die Initialisierung sollte auch i.O. sein, habe ich gerade nochmal überprüft.
Im Anschluss stelle ich dann einen aktuellen Gesamtpatch bereit, der zusätzlich noch eine Anpassung am Setup enthält, die "Undelete"-Optionen werden nur noch angezeigt, wenn es auch eine "reccmds.conf" gibt, ansonsten macht das ja keinen Sinn.
Grüße
kamel5
Stelle ich den Timeout auf Null, dann kommt nie UNDELETE auf dem Knopf.
Das ist wirklich seltsam. Ich habe das gerade bei mir nochmal getestet. Wenn ich keine "reccmds.conf" habe, dann wird sofort nach dem Löschen einer Aufzeichnung die rote Taste mit "UNDELETE" belegt, sowohl bei einer Aufzeichnung, als auch bei einem Verzeichnis. Und die Einstellungen im Setup haben keinen Einfluss darauf. --> Fall 1.
Ich überlege mir jetzt nochmal, wie ich das mit den Optionen im Setup mache, und mache dann wieder einen Gesamtpatch.
Vielleicht passt es ja dann ...
Grüße
kamel5
aber ich wollte das wenigstens noch kurz testen
Danke, mach Dir aber keinen Streß deswegen.
Aber meine urspruengliche Frage, wie das mit dem Timeout gedacht ist
Jetzt, wo Du das nochmal ansprichst, musste ich doch noch mal in meinen Erinnerungen graben, den Patch habe ich ja schon vor Jahren gemacht.
Der ursprüngliche Ansatz war:
Fall 1 (ohne "reccmds.conf": (so wie bei Dir)
Die rote Taste ist ja bei Aufnahmen mit "Wiedergabe" und bei Verzeichnissen mit "Öffnen" belegt. Wenn es jetzt eine gelöschte Aufnahme gibt, wird die rote Taste, egal ob bei einer Aufzeichnung oder einem Ordner, "immer" (unabhängig von einem Timeout") mit "UNDELETE" belegt. Die ursprüngliche Funktion gibt es dann nicht mehr, da die auch über "OK" realisierbar ist.
Fall 2 (mit "reccmds.conf":
Die rote Taste ist bei Verzeichnissen mit "Öffnen" und bei Aufzeichnungen mit "Befehle" belegt (eine Belegung mit "Wiedergabe" gibt es dann nicht). Wenn es jetzt eine gelöschte Aufnahme gibt, wird die rote Taste bei Verzeichnissen immer mit "UNDELETE", und bei Aufzeichnungen, abhängig von den Einstellungen im Setup entweder immer oder "Timeout"-abhängig mit "UNDELETE", bzw. vor oder nach dem "Timeout" mit "Befehle" belegt. Deshalb stand da im Setup auch "Wird zuerst angezeigt (UNDELETE oder Befehle)".
Stelle ich den Timeout auf Null, dann kommt nie UNDELETE auf dem Knopf.
Das sollte nicht so sein. Ich teste das bei mir noch mal.
dann steht immer UNDELETE da, wenn es geloeschte Aufnahmen gibt. Die Einstellung 'UNDELETE zuerst' hat keinen Einfluss. Einen Timeout mit irgendwelchen Aenderungen sehe ich nicht.
Das wäre so richtig, siehe Fall 1.
Nur die Einstellung ist verwirrend.
Das stimmt. Vielleicht sollte ich diese Optionen im Setup gar nicht erst anbieten, wenn es keine "reccmds.conf" gibt.
Grüße
kamel5
Das gefällt mir gar nicht, da dann im Menü erst nach dem ersten Flush() etwas angezeigt wird.
Das war ja auch nur ein Beispiel bezogen auf Deinen oben geposteten Code. Du kannst natürlich auch jede beliebige andere Lösung realisieren, die zu dem gewünschten Ergebnis führt.
Abgesehen davon haben die Locks in SetTitle() keine Probleme gemacht.
Dann musst Du da auch nichts machen...
Nur der Lock in SetRecording() wird jetzt hin und wieder im Log gemeldet
Da gilt das Gleiche, wie oben schon geschrieben. Dann musst Du eine andere Stelle für den Lock finden.
Grüße
kamel5
ich habe Dir mal einen zusätzlichen Patch angehängt, der die aktuellen Probleme beheben sollte, sowohl das mit dem Timeout, als auch das mit den Übersetzungen. Ich habe auch die Beschriftung im Setup-Menü nochmal angepasst, vielleicht ist es so eindeutiger.
Wenn das bei Dir klappt, würde ich dann einen neuen Gesamtpatch machen.
Die Strings bei der Einstellung der Button-Belegung fehlen auch, es wird Muell angezeigt. Da stimmt irgendwas mit den Pointern nicht, vielleicht mit der Uebersetzung.
Das habe ich auch noch nicht 100%ig verstanden, wenn man das so im Setup macht:
const char *buttonFirst[2];
buttonFirst[0] = tr("Button$UNDELETE");
buttonFirst[1] = tr("Key$Commands");
Add(new cMenuEditStraItem(tr("Setup.OSD$Displayed first (UNDELETE or Commands)"), &data.ButtonFirst, 2, buttonFirst));
dann gibt es die Probleme mit dem Müll.
Wenn man die Zeile:
const char *buttonFirst[2];
in den Header verlegt, funktioniert es. Naja, ich habe das jetzt zu einer Ja/Nein Frage gemacht.
Grüße
kamel5
Habe den Aufruf jetzt zusätzlich in cFlatDisplayMenu::cFlatDisplayMenu()
Ist halt nicht so optimal. Dann hast Du ja die Locks mindestens 2mal.
Nur über Flush() geht das in jedem Fall auch...
Grüße
kamel5
Das ist leider suboptimal, weil beim Aufruf des Menüs 'Timer' erst (0/0) angezeigt wird...
Das ist klar. Ich habe ja auch geschrieben: "alles". Du darfst dann in SetTitle() gar nichts ausgeben, in SetTitle() soll nur der "Title" zwischengespeichert werden, alles Andere muss dann über Flush() gemacht werden.
kamel5
Mir ist nicht klar, wie ich die Locks in den Flush() bekommen soll.
Klar, das ist manchmal nicht einfach...
Im Endeffekt hilft da nur, die ganzen "invalid lock sequence" nacheinander abzuarbeiten.
Es heißt ja auch nicht, das es nie funktioniert mit den Locks. Wenn die richtige Reihenfolge vorliegt, dann kann es durchaus funktionieren. LOCK_RECORDINGS_READ kann man z.B. in SetTitle() benutzen.
In Deinem konkreten Fall könntest Du alles, was jetzt in SetTitle() stattfindet, in eine separate Funktion auslagern, die dann in Flush() aufgerufen wird. In SetTitle() speicherst Du nur den Title in einer außerhalb gültigen Variable, die Du dann auch in der neuen Funktion zum Zusammensetzen benutzt.
Grüße
kamel5
Warum klappt das nicht? Kann man bestehende Locks nicht abfragen und dann warten bit der Lock frei ist?
Im Prinzip könnte man warten, bis der Lock beendet ist, das klappt aber in diesem Fall nicht, weil der LOCK nicht in dieser Funktion beendet wird, sondern im Core-VDR.
Grundsätzlich sollte man Locks in den vom VDR bereitgestellten Set*() Funktionen vermeiden. Wenn Du einen Lock brauchst, kannst Du den nur über die Flush() Funktion gefahrlos realisieren. In Flush() gibt es keine Core-VDR Locks.
Grüße
kamel5
Bei mir mit "Wiedergabe".
Anscheinend fehlt irgendwas zum Teil "Befehle".
Dann hast Du wahrscheinlich keine "reccmds.conf" im VDR-config-Verzeichnis angelegt, dann wird nicht "Befehle" sondern "Wiedergabe" oder "Öffnen" angezeigt. In der "reccmds.conf" kann man Aufnahmen bezogene Befehle eintragen, im VDR-MANUAL müsste das beschrieben sein.
Ob Verzeichnis oder Aufnahme ist egal, der rote Button aendert sich da bei mir nicht. Konfiguriere ich "Red Button UNDELETE timeout(s)" auf "aus", dann steht beim Verzeichnis "Öffnen". Und es wird auch das Verzeichnis geoeffnet (und nicht die Uebersicht mit geloeschten Aufnahmen), wenn ich den roten Knopf auf einem Verzeichnis druecke und eigentlich auf dem Button "UNDELETE" steht.
Das habe ich gerade mal probiert und da scheint es tatsächlich noch einen Bug zu geben.
Stell mal bitte vorerst ein Timeout ein, der kann durchaus größer sein, dann sollte auch "UNDELETE" angezeigt zu werden.
Wenn ich hier in den Einstellungen etwas aendere, dann stuerzt der vdr gelegentlich(?) ab.
Das hatte ich eigentlich noch nie.
Kann sich das OSD einfach so zeitgesteuert aendern, ohne dass der Benutzer irgendwas drueckt oder das Skin-Plugin da irgendwas mit einem eigenen Thread macht?
Ja, das geht. Der Mainmenu-Thread ruft solange ein Menü offen ist, sekündlich die Funktion "ProcessKey()" auf. Wenn man dort etwas unterbringt, dann funktioniert das wie zeitgesteuert. Das sind dann zwar nur ca. Zeiten in sec, für so einen Fall reicht das aber.
Das ganze hat übrigens nichts mit dem Skin zu tun, der zeigt es dann nur an.
Ich habe noch ein paar 'Standard-Patches' und Anpassungen fuer die hdff
Deine zusätzlichen Patches sollten keinen Einfluss auf "UNDELETE" haben.
Ich schaue mir das in der nächsten Woche nochmal an, da fehlt sicherlich nicht viel...
Grüße
kamel5
Wie ist das mit dem Timeout in den Einstellungen gedacht? Ich kann keinen Unterschied feststellen, egal ob ich 1 oder 10 einstelle. Hat das irgendwas mit dem Skin zu tun, oder irgendwelchen Einstellungen dort?
Der Button "UNDELETE" wird nur angezeigt, wenn es tatsächlich eine gelöschte Aufnahme gibt, sonst ist der rote Button mit "Befehle" belegt, auch wenn der Kursor auf einem Verzeichnis steht.
Unter Einstellungen->OSD kann man, für den Fall, das eine gelöschte Aufnahme existiert (die gibt es ja nur für eine begrenzte Zeit), einstellen, ob zuerst "UNDELETE" oder "Befehle" angezeigt wird. Nach dem Timeout sollte dann das jeweils Andere angezeigt werden.
Beispiel:
"Timeout" = 3 und "Wird zuerst angezeigt" = Befehle und es gibt eine gelöschte Aufnahme:
Wird jetzt das Aufzeichnungsmenü aufgerufen und der Kursor befindet sich auf einer Aufzeichnung, ist der rote Button mit "Befehle" belegt. Nach 3sec. wird dann automatisch, wenn man zwischendurch keine andere Funktion benutzt, der Button mit "UNDELETE" belegt.
Das Timeout legt fest, wie lange es dauert, bis der Button die Funktion ändert.
Der Skin hat keinen Einfluß auf diese Funktion.
Sollte das so nicht klappen, müsste ich mir den Patch nochmal ansehen.
Grüße
kamel5
Ton von TT6400 geht nur als Dolby, Stereo geht nicht, bzw. ist extrem leise.
Manchmal sieht man ja den Wald vor Bäumen nicht. Du weißt schon: die Lautstärke des Stereo-Tones kann man bei der TT6400 am VDR mit der Fernbedienung regeln, den Dolby-Ton nicht. Vielleicht ist ja die Lautstärke nur etwas leise eingestellt...
Grüße
kamel5
Damit ist ein Encoding-Problem bei allen Vorkommen von "Jörg" reingerutscht.
Ja, in den Kommentaren von common.h und theme.h. Sorry, war wohl das falsche Encoding der Datei...
Sollte aber keine Auswirkungen haben.
Grüße
kamel5
Wo finde ich in Fedora Fehlermeldungen (syslog/journalctl)?
"journalctl --unit vdr -f" für laufende Log-Ausgaben.
"journalctl --unit vdr -b" für Log-Ausgaben seit dem letzten Boot.
Grüße
kamel5
Anbei mein Vorschlag für den Patch, ich habe die 2. Methode OsdItem2 genannt. Man kann die natürlich auch OsdItemWithDetails nennen.
Es gibt auch Plugins, die "cStatus::MsgOsdItem()" direkt aufrufen.
Wenn Du in "status.h" noch das änderst:
- static void MsgOsdItem(const char *Text, int Index, bool Selectable);
+ static void MsgOsdItem(const char *Text, int Index, bool Selectable = false);
kompiliert bei mir alles.
Grüße
kamel5