[ANNOUNCE] VDR Version 2.6.6 freigegeben

Quote from MarkusE

heifisch ,

Hast Du getestet, ob diese Fehler auch in 2.6.5 auftritt? Falls der Fehler in 2.6.5 nicht auftritt: Welcher 2.6.6 Patch verursacht den Fehler?

Tritt der Fehler auch auf, wenn Du die Aufnahme mit

Code

svdrpsend MOVR

(also ohne live) verschiebst?

Zu Frage 1, muss ich erst wieder downgraden.

Zu Frage 2:

Ohne Live gibt es kein Segfault aber:

250-3275 17.04.17 06:37 0:10 %Big Buck Bunny
250 3276 17.04.17 06:37 0:10 %Big Buck Bunny test

vdr ~ # svdrpsend LSTR 3276
220 vdr SVDRP VideoDiskRecorder 2.6.6; Mon Jan 29 14:41:24 2024; UTF-8
215-C S13.0E-318-12300-17202 SRF zwei HD
215-E 829 1492403700 600 50 B
215-T Big Buck Bunny
215-S Blender Film Platzhalter
215-D Der mit der freien Grafik-Software Blender produzierte Kurzfilm «Big Buck Bunny» besticht durch detailliert ausgearbeitete animierte Oberflächen und eine witzige Story voller Situationskomik. Das füllige Kaninchen, das dem Film seinen Namen gibt, ist guten Mutes und eigentlich sanftmütig von Natur aus. Doch als ein Flughörnchen gemeinsam mit einem Eichhörnchen und einem Chinchilla auftauchen und seinen Frieden und die schöne Natur stören, beschliesst es, sich an den boshaften Nagetieren zu rächen.|Regie: Sacha Goedegebure|Produzent: Ton Roosendaal|Art Director: Andy Goralczyk|Niederlande 2008||Test|test
215-G 10
215-X 5 0B eng 16:9
215-X 4 44 deu Dolby 5.1
215-X 2 03 deu Stereo
215-X 2 03 deu Stereo
215-V 1492403400
215-F 50
215-P 50
215-L 99
215-O 0
215-@ <epgsearch><channel>24 - SRF zwei HD</channel><update>0</update><eventid>724</eventid><bstart>600</bstart><bstop>600</bstop></epgsearch>
215 End of recording information
221 vdr closing connection

vdr ~ # svdrpsend MOVR 3276 TEST
220 vdr SVDRP VideoDiskRecorder 2.6.6; Mon Jan 29 14:42:58 2024; UTF-8
554 Error while moving recording "%Big Buck Bunny test" to "TEST"!
221 vdr closing connection

Ein funktionierender MOVR sieht so aus:

vdr ~ # svdrpsend MOVR 3275 TEST2
220 vdr SVDRP VideoDiskRecorder 2.6.6; Mon Jan 29 14:49:03 2024; UTF-8
250 Recording "%Big Buck Bunny" moved to "TEST2"
221 vdr closing connection

heifisch ,

sind im syslog Meldungen wie:

Quote

live: rename failed from ...

Welche live version?

~ Markus

Quote from MarkusE

sind im syslog Meldungen wie:

live: rename failed from ...

Nein, solche Meldungen findet grep nicht.

Quote from MarkusE

Welche live version?

heifisch ,

Im git von live ist ein Update. Bitte testen.

~ Markus

Quote from MarkusE

Im git von live ist ein Update. Bitte testen.

Läuft.

Beim Verschieben kommt eine Fehlermeldung.

Beim Löschen wird der Eintrag aus der Liste entfernt.

Danke!

Quote from jojo61

Welche Fehlermeldung gibt es denn da ?

Ich musste jetzt erstmal zwischen einer Wagenladung von Warnings suchen aber der erste Fehler ist tatsächlich der, der in diesem Issue genannt wird:

https://github.com/jojo61/vdr-plugin-softhdcuvid/issues/72

Also an der Stelle kein Problem direkt mit VDR 2.6.6 sondern mit libplacebo.

Mit der letzten Version von softhdcuvid hat sich das Problem erübrigt. Jetzt ist im AUR wieder alles auf dem Stand von VDR 2.6.5.

Davon abgesehen das sich wohl irgendwie ein Fehler mit VNSI eingeschlichen hat.

Post

RE: Compile Warnings in vnsiserver

Dann war's das wohl erstmal mit Kodi und VDR. Das einzige das ich bestätigen kann, ist, dass ich diese Warnings auch sehe.

(Code, 22 lines)

Und damit bin ich mit meinem Latein auch schon am Ende. Absolut Null Ahnung was der Compiler damit sagen will.

M-Reimer

January 30, 2024 at 4:54 PM

Vielleicht kann da ja jemand unterstützen.

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

Bei mir funktioniert der Restart auf zwei Rechnern problemlos, ich vermute es liegt an Deinem Start-Script.

Ich habe festgestellt, dass das Einlesen der Aufnahmen von NFS in 2.6.6 sogar besser klappt als vorher - kann Zufall sein, aber trotzdem.

> Ich habe festgestellt, dass das Einlesen der Aufnahmen von NFS in 2.6.6 sogar besser klappt als vorher

Ist auch mein Eindruck. Ich vermute, es liegt an

http://git.tvdr.de/?p=vdr.git;a=c…649db55ae705467

Ist aber bei mir schwer messbar, weil das Einlesen immer unterschiedlich lang dauert.

~ Markus

SHofmann ,

Kannst Du uns Infos liefern, die bei der Fehlersuche helfen?

crasht VDR? Dann bräuchten wir den Backtrace.

Oder reagiert VDR einfach nicht mehr?

~ Markus

Quote from 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

Irgendetwas stimmt mit 2.6.6 nicht.

Unterschiedliche Plugins crashen mit 2.6.6 mehr oder weniger unerklärlich.

Gerade eben ein backtrace von einem Plugin namens 'epg2vdr', das bei der Verarbeitung von strings crasht.

Dann die Probleme im vnsi-server Plugin.

Angeblich control und remote.

Irgendeine Änderung in 2.6.6 ist faul, glaube ich.

SHofmann ,

Kannst Du uns Infos liefern, die bei der Fehlersuche helfen? Syslog?

• crasht VDR (mit core dump)?
• reagiert VDR einfach nicht mehr?

~ Markus

P.S.: backtrace erzeugen ist leider sehr system/distri-Abhängig. Da kann ich keine allgemeine Anleitung geben

Ich stolpere in den backtraces (von anderen Usern) öfter über zwei Auffälligkeiten.

cOsdMenu::ProcessKey

und

class cString::<foobar>

Hat jemand mehr Input/Ideen?

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:

Quote

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?

> Feb 4 19:02:42 htpc runvdr: VDR crashed

In meiner syslog steht da z.B. "Feb 9 12:33:07 rpi4s systemd[1]: Started Process Core Dump (PID 1465162/UID 0).".

Ist vermutlich das gleiche, ich denke, es kommt zu einem core dump. Dann bräuchten wir den backtrace.

Und ja, in VDR 2.6.6. ist eine Performanceverbesserung. Wenn das in Plugins zu raceconditions/Fehlern führt, solltet ihr die Fehler in den Plugins fixen. Selbst wenn wir VDR wieder langsamer machen, solche Fehler kommen wieder: Anderer/besserer compiler, schnellerer Rechner, ...

Kannst Du herausfinden, an welchem Plugin es liegt?

Tritt der Fehler auch ohne nopacity auf?

~ Markus

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

Quote from MarkusE

> Feb 4 19:02:42 htpc runvdr: VDR crashed

In meiner syslog steht da z.B. "Feb 9 12:33:07 rpi4s systemd[1]: Started Process Core Dump (PID 1465162/UID 0).".

Ist vermutlich das gleiche, ich denke, es kommt zu einem core dump. Dann bräuchten wir den backtrace.

Und ja, in VDR 2.6.6. ist eine Performanceverbesserung. Wenn das in Plugins zu raceconditions/Fehlern führt, solltet ihr die Fehler in den Plugins fixen. Selbst wenn wir VDR wieder langsamer machen, solche Fehler kommen wieder: Anderer/besserer compiler, schnellerer Rechner, ...

Kannst Du herausfinden, an welchem Plugin es liegt?

Tritt der Fehler auch ohne nopacity auf?

~ Markus

Display More

meine zwei Backtraces sind ja im anderen Fred