Beiträge von shofmann

Zitat von kls

Vielleicht würde es ja auch Sinn machen, die Zahl generell auf "defekte Frames" umzustellen, auch bei der original Aufnahme?

Ich fände das eh sinnvoller.

Jetzt fehlten nur noch ein paar Tasten, mit denen man Blöcke fehlerhafter Frames (das erste bzw. letzte I-Frame eines Blocks) gezielt ansteuern könnte – so wie Sprungmarken. Dann könnte man vor dem Schneiden noch schnell checken, ob sich die Fehler im Vor- bzw. Nachlauf oder in einer Werbeunterbrechung befinden.

Ja ja, ich weiß schon: die Sache mit dem kleinen Finger und dem ganzen Kerl...

Viele Grüße

Stefan

Das hatte ich gesehen und auch schon in diese Richtung überlegt. Allerdings wäre dann die Semantik von "O" nach dem Schneiden (fehlerhafte Frames) eine andere als vor dem Schneiden (fehlerhafte Rahmenbits, wie ich vermute)...

Danke jedenfalls

Stefan

Genau das mache ich derzeit, was aber ein wenig lästig ist und im Nachgang immer viel Handarbeit erfordert.

Hallo Klaus,

erst einmal vielen Dank für deine Überlegungen. Wenn sich die Fehler nicht beim Verarbeiten (Schneiden) des Datenstroms "en passant" ermitteln lassen, scheint dein Ansatz wohl am zielführendsten zu sein.

Noch ein paar ergänzende Gedanken: Schnittmarken können ja laut Handbuch ja immer nur an I-Frames gesetzt werden. Insofern bräuchte man also nur per I-Frame vermerken, wie viele Fehler in ihm selbst und den folgenden B-Frames aufgetreten sind. TS-Fehler müssten für den gedachten Zweck auch nur auf Granularität solcher Schnittblöcke protokolliert bzw. beim Schneiden akkumuliert werden. Blöcke ohne TS-Fehler bräuchte man dabei nicht protokollieren, wenn man fehlende Blöcke als fehlerfrei betrachtet.

Landet ein protokollierter Block (I-Frame mit seinen B-Frames) in der geschnittenen Aufzeichnung, wird die Zahl seiner TS-Fehler aufaddiert. Entfällt ein protokollierter Block, sind seine TS-Fehler ohne Belang. Ein nicht protokollierter Block ist per definitionem fehlerfrei.

Textbasiert kann eine Datei mit den TS-Fehlern per Block recht groß werden. Insofern wäre ein binäres Dateiformat wie bei index mit Tupeln von (struct tIndexTs block, uint64_t tsErrors) wohl günstiger. [uint64_t deshalb, damit man die Datei mit od -tx8 schön ausgeben lassen kann.]

Schick wäre das alles schon. Bezüglich der Frage, ob sich der Aufwand für dich lohnt, hoffe ich auf eine wohlwollende Einschätzung...

Viele Grüße

Stefan

Hallo Klaus,

wieder einmal vielen Dank für das VDR-Update. Noch eine Frage zu den TS-Fehlern: Wenn man eine Aufzeichnung schneidet, kann es ja durchaus passieren, dass die TS-Fehler im "abgeschnittenen" Teil lagen und in der geschnittenen Aufzeichnung nicht mehr enthalten sind. Trotzdem bleibt in den Infos die ursprüngliche Fehlerzahl stehen.

Siehst du eine Chance, die Zahl der TS-Fehler beim Schneiden neu zu ermitteln, sodass die geschnittene Aufzeichnung diesbezüglich "korrekt" ist?

Danke & Grüße

Stefan

Hi,

hier noch meine zwei Cents, wie man so schön sagt: Leider eignen sich nicht alle meine Eingänge gleich gut für HD-Aufnahmen, denn einige führen mit höherer Wahrscheinlichkeit zu TS-Fehlern. Insofern versuche ich, HD-Aufnahmen bevorzugt auf die "guten" Eingänge zu legen, was mit ein bisschen jonglieren meist gelingt.

In diesem Kontext vermisse ich seit VDRAdmin die Zeitleiste mit der Prognose, welche Aufnahme (ohne zwischenzeitlichem Kanalwechsel) welches Device verwendet.

Aus meiner Sicht wäre das somit auch ein cooles Feature...

Viele Grüße

Stefan

Hi Klaus und Markus,

auch ich hatte gestern nach dem Upgrade auf v2.6.8 unerklärliche Abstürze. Aufgefallen ist das beim Editieren der Suchtimer von EPG-Search, bei denen ich u.a. reguläre Ausdrücke mit mehreren Alternativen (Pipe-Zeichen, "|") nutze und bei deren Speicherung genau die von Markus zitierte Codestelle (Zeile 5) durchlaufen wird.

Weil der VDR laut Core-Dump aufgrund eines Längenfehlers von realloc innerhalb von vasprintf gecrasht ist:

#0  0x00007259bba969fc __pthread_kill_implementation (libc.so.6 + 0x969fc)
#1  0x00007259bba42476 __GI_raise (libc.so.6 + 0x42476)
#2  0x00007259bba28885 __GI_abort (libc.so.6 + 0x28885)
#3  0x00007259b78b3abb n/a (libGraphicsMagick-Q16.so.3 + 0xb3abb)
#4  0x00007259bba42520 __restore_rt (libc.so.6 + 0x42520)
#5  0x00007259bba969fc __pthread_kill_implementation (libc.so.6 + 0x969fc)
#6  0x00007259bba42476 __GI_raise (libc.so.6 + 0x42476)
#7  0x00007259bba287f3 __GI_abort (libc.so.6 + 0x287f3)
#8  0x00007259bba89676 __libc_message (libc.so.6 + 0x89676)
#9  0x00007259bbaa0cfc malloc_printerr (libc.so.6 + 0xa0cfc)
#10 0x00007259bbaa4c6c _int_realloc (libc.so.6 + 0xa4c6c)
#11 0x00007259bbaa5862 __GI___libc_realloc (libc.so.6 + 0xa5862)
#12 0x00007259bba88115 __vasprintf_internal (libc.so.6 + 0x88115)
#13 0x00007259b5938da3 vasprintf (libvdr-epgsearch.so.2.6.8 + 0x87da3)
#14 0x00007259b5924b53 _ZN10cSearchExt6ToTextEv (libvdr-epgsearch.so.2.6.8 + 0x73b53)

...habe ich zwar im Plugin gesucht, dort aber nicht gleich die entscheidende Codestelle gefunden. Zumal der Crash erst beim 14. regulären Ausdruck (davon dem 7. mit mehr als einem Pipe-Zeichen) aufgetreten ist.

Nach Einspielen des Patches läuft wieder alles wie gewohnt.

Danke euch und viele Grüße
Stefan

Ich versuche es mal einzugrenzen. Heute werde ich es aber wohl nicht mehr schaffen...

MarkusE, anbei erst einmal ein Extrakt aus dem syslog mit den jeweils letzten drei Einträgen vor dem Crash, der praktisch immer nach Einträgen von SkinNopacity erfolgt ist:

• VDR 2.6.6 crash.syslog.zip

Davor findet sich nichts Interessantes, nur jeweils ellenlange Abfolgen von Zugriffen des Skins auf diverse Logo-Dateien.

Nach euren letzten Posts scheint sich die Vermutung zu erhärten, dass die Crashes mit der String-Move-Erweiterung zusammenhängen könnten... bei mir eben innerhalb von Nopacity.

Hat schon mal jemand den dazugehörigen Commit probehalber revertiert, und hat das geholfen?

Danke & Grüße

Stefan

PS: Ich bin leider kein ausgesprochener C++-Guru und habe deshalb mal ein wenig gegoogelt. Wenn ich die folgende Aussage richtig verstanden habe:

Zitat

Rvalue references support the implementation of move semantics, which can significantly increase the performance of your applications. Move semantics enables you to write code that transfers resources (such as dynamically allocated memory) from one object to another. Move semantics works because it enables transfer of resources from temporary objects: ones that can't be referenced elsewhere in the program.

...dürfen keine doppelten Bezüge auf das zu verschiebende Objekt bestehen. Kann das im Kontext des VDR und seiner Plugins denn sichergestellt werden, und könnte das für die Crashes ursächlich sein?

Oder bin ich mit meinem Gedanken auf einer völlig falschen Spur?

Zitat von jsffm

ich vermute es liegt an Deinem Start-Script.

Das Skript läuft seit Jahren unverändert ohne Probleme. Warum sollte es also gerade jetzt Probleme verursachen? Und mehr als den VDR starten kann es letztlich ja auch nicht.

Wenn das Programm beim zweiten Mal abstürzt, hätte ich eher eine andere Vermutung: Das Einlesen der Aufzeichnungen dauert beim ersten Mal recht lange, weil Linux alle Dateien von der Platte einlesen muss (erster Zugriff). Beim Neustart sind viele Daten aber im scon Cache und das Einlesen geht viel schneller. Eventuell also eine Race condition?

MarkusE: Was genau verstehst du unter dem "Backtrace" (syslog?) bzw. wie kann ich diesen gegebenenfalls erzeugen?

Danke und Grüße

Stefan

Vielen Dank an Klaus für die neue Version. Ganz enthusiastisch habe ich sie zusammen mit allen von mir genutzten Plugins gleich installiert. Wie immer habe ich vorher mit "make clean" den VDR und alle Plugins zurückgesetzt und anschließend alles sauber "von Scratch" aufgebaut.

Beim Einschalten bzw. Reboot des Rechners funktioniert alles wunderbar. Doch wenn ich einen VDR-Neustart ausführe (z.B. per "/etc/init.d/vdr restart"), hängt sich der VDR irgendwann beim Einlesen der Aufzeichnungen auf. Mit 2.6.5 passiert das – bei ansonsten gleicher Konfiguration und denselben Plugins – nicht.

Hat jemand ähnliche Beobachtungen gemacht bzw. eine Idee, woran das liegen könnte?

Vielen Dank und beste Grüße

Stefan

Zitat von kamel5

Patch 1:

Es scheint aber so zu sein, das das dvd-Plugin überhaupt keinen Titel ausgibt, dann bleibt die Fläche über dem Fortschrittsbalken leer.

Das stimmt. Für mich ist aber die Zeitleiste entscheidend.

Zitat von kamel5

Patch 2:

Hier ist zu beachten, das dadurch auch ein Bild im Landscape-Format angezeigt werden könnte.

Für mich passt das, denn meine "Poster" sind im Format 4:3.

Danke dir

Stefan

SkinNopacity zeigt in den Details einer Aufzeichnung auch ein anderes Image nur als das Poster des TV-Scrapers an:

• In der Listenansicht der Aufzeichnungen ist es das erste JPG-Image, das sich im Verzeichnis der Aufzeichnung befindet.
• Ruft man dort (oder direkt beim Abspielen) die Info auf, werden im Abschnitt "Bildergalerie" alle JPG-Images des Verzeichnisses angezeigt.

Deshalb hier noch ein Patch – der wie bei Punkt 1 – bei der Wiedergabe einer Aufzeichnung das erste Image im Verzeichnis auch im Progress-Bar anzeigt:

0001-Added-support-for-recording-image-to-replay-progress.zip

Viele Grüße

Stefan

kamel5,

mit dem Commit "Show poster in display replay" wird bei Wiedergabe einer DVD leider kein Progress-Bar mehr angezeigt. Das liegt daran, dass in diesem Fall SetRecording() und damit auch CreatePixmaps2() nicht aufgerufen wird, sodass die Pixmaps für diese Elemente nicht generiert und damit auch nicht angezeigt werden.

Hier ein Vorschlag einen Fix: 0001-Fixed-missing-progress-bar-for-DVD-replay.zip

Vielen Dank, viele Grüße und einen guten Rutsch!

Stefan

Hallo GBruno,

ich kenne dieses leidige Problem nur zu gut. Hier eine Lösung, die bei mir unter Ubuntu 20.04 mit Kernel 5.15 ohne Probleme funktioniert:

• TT S2-6400 - saa716x kompilieren unter 22.04

Aus den Rückmeldungen im Thread steht zu vermuten, dass das Ganze auch mit XUbuntu funktionieren sollte. Ich drücke jedenfalls die Daumen...

Viele Grüße

Stefan

Hallo zusammen,

hatte die letzten Tage keine Zeit, die Diskussion zu verfolgen. Ich schaue mir das aber in einer ruhigen Minute nochmal an.

Danke jedenfalls fürs Forschen und den Lösungsansatz.

Viele Grüße

Stefan

PS: Ich habe trotz der Änderung die Fehlermeldung beim letzten Upgrade am Wochenende erneut im Log gefunden. Die Suche geht also weiter...

Noch ein Nachtrag: Nach dem gestrigen Upgrade auf Kernel 5.15.0-58 ließ sich der vom DKMS gebaute und installierte Treiber nicht mehr laden. Im syslog fand sich eine lange Liste mit Fehlermeldungen wie dieser:

• saa716x_core: disagrees about version of symbol pci_enable_device
• saa716x_core: Unknown symbol pci_enable_device (err -22)

Geholfen hat letztlich, in /usr/src/saa716x-1.0.0 die "historischen" Quellen (saa716x-5.15.zip

und deren expandierten Baum unter saa716x-5.15) zu löschen und den Treiber an DKMS vorbei manuell zu bauen:

• ./make.sh --dest /lib/modules/$( uname -r )/updates/dkms

Dabei die Frage „Clean all before building (y/N)?“ mit „y“ beantworten. Danach werden die Quellen vor dem Bauen erneut heruntergeladen und die von DKMS installierten durch die neu gebauten Treiber ersetzt.

Nicht ganz unschuldig an diesem Verhalten ist sicherlich auch, dass ich wegen meines etwas langsameren Internet-Zugangs auf das ständige Herunterladen der Quellen im DKMS-Batchbetrieb verzichte (Option --clean, Zeile 97 in make.sh). Für wen das kein Problem ist, möge bei sich bitte das Kommentarzeichen dort entfernen.

Viele Grüße

Stefan

Danke für die Rückmeldung. Deiner Signatur zufolge hast du mit Kernel 6.1 gebaut. Ich war mir nicht ganz sicher, ob das Skript nicht noch irgendwelche Kernel-spezifischen Patches (statt oder in Ergänzung zu dem beigefügten saa716x.diff) gebraucht hätte.

Vielleicht kann wtor das einordnen.

Viele Grüße

Stefan

Ich habe mal die entscheidenden Schritte, die mit Root-Rechten auszuführen sind, aus der Bash History rekonstruiert:

• apt-get install dkms

Damit wird das eventuell schon automatisch installierte zu einem manuell installierten Paket und fällt somit nicht vielleicht irgendwann einmal einem apt autoremove zum Opfer.

• cd /usr/src
• unzip dkms-saa716x.zip
  • Update mit dem Hinweis von kamel5 weiter unten: dkms-saa716x (2).zip
  • Patch zum Bauen mit allen verfügbaren CPU-Cores: make-with-threads.zip

• dkms add -m saa716x -v 1.0.0

Jetzt noch die Module erstmalig manuell bauen:

• dkms build -m saa716x -v 1.0.0

Danach sollten die Module bei jedem Kernel-Update automatisch mitgebaut werden.

Ich hoffe, dass ich nichts Entscheidendes vergessen habe. Bitte probiert es aus und meldet euch, wenn es knirschen sollte.

Viele Spaß damit und viele Grüße

Stefan

Hallo auch von mir.

Ich hatte das Skript ebenfalls schon vor ein paar Wochen erprobt, die gebauten Kernel-Module getestet und – weil mich das manuelle Bauen schon seit langem genervt hat – in DKMS integriert. Seitdem kann ich wieder den aktuellen Edge-Kernel 5.15 für Ubuntu 20.04 nutzen und muss nicht bei 5.11 versauern. Probleme habe ich bislang keine beobachtet.

Sorry, dass ich nicht schon früher Feedback gegeben habe, baermuda hat mich wieder daran erinnert.

Danke und viele Grüße

Stefan