> Aber man könnte auch das scrapen der geschnittenen Aufnahme durch den Hook starten.
Hört sich gut an, müsste funktionieren.
Klar kann man vieles machen, das Anzeigen von Scraper-Informationen bei geschnittenen Aufnahmen ist aber schon mal gegangen. Ein kurzer Test mit Version 1.2.12 zeigt, das es damit noch geht. Es scheint also einer der letzten commits nach V1.2.12 dafür verantwortlich zu sein, das es nicht mehr funktioniert.
Grüße
kamel5
Hallo,
es gibt eine neue Version 2.0.14:
- Update MainMenuHooks-patch for VDR >= 2.7.4
- Fix unmount hdd does not work (thx to Joe_D at vdr-portal.de)
- Added missing locks to SetMenuItem() function
Grüße
kamel5
Ja, wird es aber solange der Schnitt oder die Aufnahme noch läuft, da in dieser Zeit numFrames = -1 ist und erst am Ende des Schnitt bzw.Aufnahme der endgültige Wert gesetzt wird.
Stimmt, das konnte ich jetzt nachvollziehen.
Wenn man über das Ganze nachdenkt, wird es ja nur dadurch nicht richtig gemacht, weil bei "cRecordings::AddByName" das beim zweiten mal ignoriert wird. Im Endeffekt würde es ja reichen, dort einen "else" - Fall aufzumachen und das "UpdateByName" dort unterzubringen.
Im Anhang mal einen Patch dazu.
Grüßr
kamel5
So wie ich den Patch verstehe würde er nichts beim ersten Schneiden verändern, aber beim Überschreiben einer Aufnahme (zweiter Schnitt) die Fehler und Dauer erst am Ende aktualisieren. Da würde die Anzeige dann "plötzlich" umspringen, oder?
Ja.
Warum sollte man das beschränken und anders behandeln als beim Aufnehmen oder dem ersten Schnitt?
Das wird ja beim ersten Schnitt auch nicht anders behandelt. Wenn man das direkt hinter "cutter->Start();" einfügt, wird es ja auch nur einmalig am Anfang des Schnittes aufgerufen und da ist das endgültige "numFrames" noch nicht bekannt. Ich wüsste jetzt nicht, das es im Plain-VDR beim Cut zwischendurch aktualisiert wird. Ich kann es leider hier selbst momentan nicht testen.
Im Endeffekt scheint mir hier Deine Lösung aus #40 fast die bessere Wahl.
Grüße
kamel5
Neue Version 1.3.10 im git:
- Optimizations
- enable kInfo for detail view
- Don't switch to current channel (thx to rell at vdr-portal.de)
- Update Locking
- Update cRecManager::OnOffTimer()
- Update cRecManager::DeleteTimer()
- Update virtual and override
- Eliminate Warnung: Vergleich von Ganzzahlausdrücken
- Optimize cRecMenuItemTimelineHeader
Grüße
kamel5
wäre es nicht besser, das "Recordings->UpdateByName(FileNameDst());" für das cutting in "cRecordingsHandlerEntry::Active" nur dann aufzurufen, wenn kein Fehler aufgetreten ist? Also unter "// We're done:". Unter "// Now check if there is something to start:" wird es ja erst einmal nur gestartet.
Anbei mal ein entsprechender Patch.
Grüße
kamel5
Das müsste mit dem obigen Patch von kls auch korrigiert sein
OK, ich habe den Patch jetzt eingespielt und werde das mal eine Weile beobachten.
Grüße
kamel5
Beim Anzeigen der Recording Errors, die auch von cRecorder über die Info-Datei an die Liste der Aufnahmen übergeben werden, sollte die Genauigkeit aber reichen so dass dort kein Force notwendig ist.
Ich hatte in letzter Zeit, ich denke so ab Version 2.7.4, relativ oft den Fall, das Recording Errors während und nach einer Aufnahme nicht korrekt im Recordings Menü angezeigt wurden. Das ist mir beim Schneiden einer solchen Aufnahme aufgefallen, erst bei der geschnittenen Aufnahme wurden die Fehler dann korrekt angezeigt. Ich weiß allerdings nicht, ob das den gleichen Zusammenhang hat.
Grüße
kamle5
Nächstes Problem ist das status-Plugin, wenn man es mit den Build-Flags -Wall -Werror=overloaded-virtual kompiliert:
Du musst das "-Werror=overloaded-virtual" aus der Make.config im VDR-Verzeichnis entfernen.
Das hatte kls schon mal mal irgendwo geschrieben, das es sonst eine Fehlermeldung gibt.
Bei mir hat es danach kompiliert.
Grüße
kamel5
Zeitlupe nutze ich zwar nicht sehr oft, aber doch manchmal.
Ich konnte jetzt mal einen Test mit den verschiedenen Softwareständen machen:
Sowohl mit dem Patch von kls : "Fixed spurious fast frames when switching from "slow back" to "slow forward" als auch zusätzlich mit dem Patch von rell : "0001-refix.txt" habe ich kurze Sprünge nach vorn beim Übergang von "Pause" zu "Zeitlupe vorwärts", (am besten zu sehen im Abspann von Filmen, Sprung mehrere Zeilen vorwärts).
Der ursprüngliche Zustand, ohne diese beiden Patche, ergibt bei mir einen vollkommen smoothen Übergang von "Pause" zu "Zeitlupe vorwärts" (ohne Sprünge). Das erscheint mir aktuell immer noch die bessere Lösung zu sein, zumindest für mein Ausgabedevice (TT6400 + dvbhddevice).
Grüße
kamel5
Mein Fazit: GetVideoSize() kann komplett entfallen, nur GetOsdSize() ist von Bedeutung.
Dem muss ich widersprechen.
Ich nutze GetVideoSize() in den Skins sowohl bei Live-TV als auch bei älteren Aufnahmen um die Videoauflösung anzuzeigen. Alternativ müsste man alle Aufnahmen neu indexieren, um das dann aus der info-Datei zu nehmen. Bei Live-TV fällt mir da im Moment keine Alternative ein.
Grüße
kamel5
Nach Update von Fedora 40 auf Fedora 41 hat sich bei mir das Problem ergeben, das bei Nutzung der Sk*-Smartcard in Verbindung mit dem negativen ci-Modul und ci-Plugin keine Authentifizierung möglich ist.
Das liegt daran, das openssl in Fedora 41 sha1 nicht mehr als vertrauenswürdig einstuft. Für den oben genannten Anwendungsfall ist das aber notwendig.
Im Moment und bis auf absehbare Zeit (es soll mehrere Fedora-Versionen betreffen) lässt sich das durch folgenden Befehl:
update-crypto-policies --set FEDORA40 (habe ich bei mir gemacht)
oder folgende, habe ich aber nicht getestet:
update-crypto-policies --set DEFAULT:SHA1
runcp FEDORA40 command args
rückgängig machen. Danach funktionieren die entsprechenden Sender wieder.
Möglicherweise kann das in Zukunft auch andere Distributionen betreffen.
Grüße
kamel5
Vielleicht mag es kamel5 ja in einer ruhigen Minute mal nachziehen?
Ja, so bekommt man was übergeholfen.
Ich hatte damals nur für mich mal die api5 (weil ich eine Sat-Karte dafür habe) integriert und das dann halt öffentlich gemacht. Maintainer wollte ich dafür eigentlich nicht werden, ich habe so schon genug plugins in der Betreuung.
Wenn sich da also jemand angesprochen fühlt, das zu übernehmen...
Grüße
kamel5
Wenn ich in der ARD Mediathek bin und entweder Teletext oder die Audiothek aussuche, komme ich von da nicht mehr in die erste Übersicht. Der rote Button minimiert/maximiert nur die Ansicht der Audiothek oder Teletext. Eine andere Taste habe auch ich nicht gefunden, die das bewerkstelligt.
Wenn ich von der Übersichtsseite aus im Teletext oder in der Mediathek bzw. Audiothek bin, komme ich mit der 0 wieder zurück auf die Übersicht. Das wird bei mir auch kurz unten eingeblendet.
Grüße
kamel5
In der -01 Fassung meines Patches war ein Fehler drin, vielleich lag es daran?
Ich hatte schon den richtigen Patch -02.
Ich habe es gerade nochmal mit der Option -Werror=overloaded-virtual kompilieren lassen, und heute geht es ohne Fehler.
Wer weiß was das gestern war...
Grüße
kamel5
Das wundert mich aber. Ich hätte erwartet, dass das mit SetItemEvent2() noch nicht nötig wäre.
Vielleicht liegt das auch an meinem neueren Compiler: gcc-Version 14.2.1 20240912 (Red Hat 14.2.1-3)
Grüße
kamel5
aber deswegen solche Umbauten zu machen widerstrebt mir.
Kein Problem.
Ich habe aber nochmal eine grundsätzliche Frage zu den LOCK's:
Um den LOCK so kurz wie möglich zu halten, wird an manchen Stellen in Plugins z.B. folgendes gemacht:
const cSchedules *schedules;
{
LOCK_SCHEDULES_READ;
schedules = Schedules;
}
Wäre es dann hier auch richtiger den LOCK solange zu halten, wie man schedules benutzt, oder könnte man davon ausgehen, das das grundsätzlich funktioniert?
Grüße
kamel5
Prinzipiell scheint der Patch wie erhofft zu funktionieren. Ich werde das jetzt mal eine Weile beobachten.
Dazu müsste aber die Option Werror=overloaded-virtual aus dem Makefile entfernt werden.
Das musste ich jetzt allerdings auch schon entfernen.
Was mir beim Beschäftigen mit den Items noch aufgefallen ist:
Selbst wenn ein Skin den Item-Text selbst erzeugt, werden diese Texte trotzdem nochmal im Konstruktor "cMenu*Item::cMenu*Item()" erzeugt, das wäre eigentlich nicht nötig.
Für einen "MenuTimerItem" und einen "MenuChannelItem" ließe sich das recht einfach ändern, beim "MenuScheduleItem" könnte man es durch Aufteilen von cMenuScheduleItem::Update() realisieren. Beim "MenuRecordingItem" ist das leider nicht so einfach möglich, da der Text auch noch in "void cMenuRecordings::Set()" benutzt wird.
Ich habe mal einen Patch angehängt, aufbauend auf Deinen "vdr-2.7.4-setitemevent-timer-02.diff.txt", der das verdeutlicht und einen Lösungsvorschlag für die ersten 3 macht. Vielleicht magst Du Dir das noch mit ansehen.
Grüße
kamel5
Das LOCK_RECORDINGS_WRITE als letztes Statement ohne nachfolgende Anweisungen scheint mir ein wenig sinnlos zu sein. Müsste das nicht an den Anfang der Prozedur (also vor Zeile 3143)?
Die Stelle im Destruktor spielt keine Rolle. Als ich den Patch vor Jahren mal gemacht habe, wurde beim Verlassen des Undelete-Menüs die Ansicht manchmal nicht richtig aktualisiert. Dieser write-lock hatte das behoben. Ob das beim aktuellen VDR noch nötig ist, müsste man mal testen...
dass alle Codeänderungen mit #if(n)def USE_UNDELETE gekennzeichnet sind
Das ist für mich bewusst so gemacht. Dadurch kann man über die Make.config diesen Patch ein- und ausschalten. Bei den älteren Versionen vom Patch hatte ich das, glaube ich, rausgelöscht, diesmal aber wohl vergessen.
Grüße
kamel5
Ein zusätzliches tmRecording würde aber bedeuten, dass an allen Stellen, wo eTimerMatch verwendet wird, dies berücksichtigt werden müsste. cMenuScheduleItem::Update() macht z.B.
Stimmt auch wieder, das hatte ich gar nicht bedacht.
Was mich wieder zu meinem ursprünglichen Vorschlag mit dem zusätzlichen LOCK bringt. Wie schlimm wäre das denn, da der Lock ja nur für die kurze Zeit des Erzeugens des Items benötigt wird, sollte das doch keine größeren Auswirkungen haben.
Den Timer in SetItemEvent() zur Verfügung zu haben, wäre schon schön, dann könnte man in einem Skin ohne Klimmzüge die gleichen Dinge machen wie in cMenuScheduleItem::Update().
Seltsamerweise ist der Text nach Wie wäre es " unsichtbar (hab ihn erst nach überstreichen sehen können).
Ich hatte die Farbe auf weiß geändert, das war sicher ungünstig. Das mit den Farben ist wirklich eine komische Sache, bei jedem Einfügen wird es bunt. Ich glaube, ich habe jetzt aber den richtigen Menüpunkt zum entfernen der Farbe gefunden...
Grüße
kamel5
