Die gleiche Fragestellung hatte in der Zeit meiner Patch Sammlung auch ein paar mal.
Zum Beispiel macht die "mark new recording" Funktion keinen Sinn für User, die Aufnehmen, Anschauen und dann löschen. Für andere schon ...
Ev. müsste man das konfigurierbar machen.
So habe ich das damals auch gelöst.
Ich habe die Tntnet30 Änderungen mit Tntnet20 getestet und auch keine Probleme feststellen können. Somit auch von mir an MarkusE das GO für den merge.
Das habe ich bereits. Das meinte ich mit dem o.g. Post. OK, ist natürlich Tntnet 2.2 und nicht Tntnet 2.0, was in Ubuntu focal dabei ist.
Der Tntnet30 Branch läuft bei mir jetzt seit einer Woche auf meinem produktiven VDR mit Tntnet 2.2 ohne Probleme.
Die meisten Änderungen sind eh in Compiler Direktiven gekapselt und wirken nur, wenn man gegen die libs von Tntnet30 kompiliert..
Ich bin hier nur Gast Programmierer, die Entscheidung trifft der git Owner MarkusE
Ja, damit ist es mir auch nicht gelungen. Aber mein Verdacht war richtig, du kannst den Crash "mit Gewalt" erzeugen, indem du einen Timer aus der Programmübersicht erstellst und vor dem Speichern im Browser die letzte Stelle der URL löscht um eine ungültige Event ID zu erzeugen. Beim Speichern kommt dann genau dein Crash. Man sollte besser Pointer auf NULL überprüfen bevor man sie verwendet ...
Fix ist im Branch Tntnet30, Branch crash ist gelöscht.
Das wird eine schwierige Nummer ...
Ich vermute, der Crash hat gar nichts mit Tntnet30 zu tun.
Der Crash ist im VDR selbst, die Ursache ist vermutlich aber der o.g. NULL Pointer in edit_timer.ecpp:138.
Kann es sein, dass du beim Zurückblättern einen Timer editiert hast, dessen EPG Event bereits abgelaufen war ?
Installiere mal den Branch "crash" vom git und versuche den Crash nochmals hinzubekommen.
Falls mein Verdacht stimmt, dann müsste im syslog "live: edit_timer.ecpp eventid ... not valid" stehen.
Die Version 2.6.3 ist auf vdr-plugin-markad verfügbar.
Sie enthält kleinere Optimierungen und Fehlerkorrekturen.
Ich habe die Tntnet30 Änderungen mit Tntnet20 getestet und auch keine Probleme feststellen können. Somit auch von mir an MarkusE das GO für den merge.
Am Anfang als ich die neue Version installiert hatte, bekam ich einen Coredump
Der war einfach, Patch ist im Git.
Nachdem du mir so viel Übung beim Lesen von backtraces verschaffst hast, war das einfach:
Beliebiges Programm, dann click auf die EPG Info einer Sendung und schon ist der nächste Crash da.
Wenn ich unter "Was läuft?" bin und dann bei einem Programm auf "Stream this channel in browser" gehe, bekomme ich
die Meldung: Error "Der Server antwortet nicht"
... und der auch.
Beim Timer speichern bekomme ich "Seitenfehler: Fehler in den Timer Einstellungen"
Patch dazu ist jetzt im git.
Der Punkt
WARN tntnet.worker - http-Error: 500 character conversion failed
ist im git gefixed. Ich hatte eine Aufnahme von einem anderen vdr im Aufnahmeverzeichnis, wo das vdr info File iso-8859-1 codiert war. Tntnet20 zeigt dann seltsame Zeichen statt der Umlaute an, Tntnet30 zeigt gar keine Aufnahme mehr an.
Ich habe mal einen full backtrace davon angehängt, weis nicht ob es dir hilft.
Ja, hat geholfen. Das Problem liegt an diesem commit. Da habe ich mal auf die Schnelle nur den Header der zusätzlich benötigten Funktion eingebaut damit Live kompiliert, aber noch nicht einen Inhalt. Somit bekommt die Funktion "Timer speichern" die Channel-Id des Timer nicht. In Tntnet20 ging das mit internen Funktionen. Jetzt muss ich erst mal verstehen, was Tntnet30 hier haben will.
Ja, kann ich reproduzieren, da gib es auch einen Crash.
Aber so weit bin ich noch nicht, ich kämpfe gerade immer noch mit der Aufnahme Liste, bei einer meiner Aufnahme bekomme ich:
Schön wäre es, wenn man einen Hinweis bekommen würde, wo im Code das schief geht ...
Lass uns die offenen Punkte hier sammeln, ich versuche die nach und nach abzuarbeiten.
Nachdem ich nun die Suche nach dem Fehler schon fast aufgegeben hatte und den Hilfe Post abgesetzt hatte, bin ich durch Zufall über die Lösung gestolpert.
"Eine kleine Änderung, selten genutzt", naja, das hat mich Tage Suche gekostet.
Erster Test war auch erfolgreich, mit "path[]" statt "path" wird nun auch der Vector übergeben. Somit kann es weiter gehen.
Ich habe mich mal daran versucht, Live mit Tntnet30 zum Laufen zu bringen, leider nicht erfolgreich.
MarkusE hat mich freundlicherweise auf sein git berechtigt, damit wir nicht wieder mehrere gits haben. Mein Versuch liegt in seinem git im Branch Tntnet30.
Aktueller Status: es kompiliert, aber crashed beim Aufruf der Aufnahme Liste.
Ich konnte den Fehler eingrenzen, dass bei diesem rekursivem Aufruf der Vector mit dem Parameter "path" nicht funktioniert. Einfache Parameter wie "level" oder "filter" kommen an, der Vector "path" kommt aber immer leer an. Damit gibt das eine Endlos Schleife, bis zum Crash.
Ab da komme ich nicht weiter. MarkusE : schaust du dir das mal an, ob du da was finden kannst. Ich vermute fast, das ist ein Bug in Tntnet30.
Die Version 2.6.2 ist auf vdr-plugin-markad verfügbar.
Sie enthält im wesentlichen Optimierungen und Fehlerkorrekturen der in 2.6.0 eingeführten neuen Funktionen.
Das EPG schreibt doch nur der VDR? Und der düfte doch das vorher prüfen.
Ja, so sollte das sein. Aber manchmal geht halt auch was schief, vielleicht war da mal ein Crash während des Speicherns von Einträgen.
Ich würde bei gestoppten VDR die Zeile raus löschen und dann abwarten, ob das Problem wieder kommt.
was steht denn in /var/cache/vdr/epg.data in Zeile 1011134 ?
Hier ging es nur mit After=network.target
Dass das was verbessert, verstehe ich nicht, da network.target vor network-online.target kommt. Die Wege von systemd sind manchmal seltsam ...
Quote
network.targethas very little meaning during start-up. It only indicates that the network management stack is up after it has been reached. Whether any network interfaces are already configured when it is reached is undefined. Its primary purpose is for ordering things properly at shutdown: since the shutdown ordering of units in systemd is the reverse of the startup ordering, any unit that is order After=network.target can be sure that it is stopped before the network is shut down if the system is powered off. This allows services to cleanly terminate connections before going down, instead of abruptly losing connectivity for ongoing connections, leaving them in an undefined state. Note thatnetwork.targetis a passive unit: you cannot start it directly and it is not pulled in by any services that want to make use of the network. Instead, it is pulled in by the network management service itself. Services using the network should hence simply place an After=network.target dependency in their unit files, and avoid any Wants=network.target or even Requires=network.target.network-online.targetis a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network is set up. It is an active target, meaning that is may be pulled in by the services requiring the network to be up, but is not pulled in by the network management service itself. By default all remote mounts defined in/etc/fstabpull this service in, in order to make sure the network is up before it is attempted to connect to a network share. Note that normally, if no service requires it, and if no remote mount point is configured this target is not pulled into the boot, thus avoiding any delays during boot should the network not be available. It is strongly recommended not to pull in this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), its primary purpose is network client software that cannot operate without network.
eine rc.local wo man einfach ein mount -a; touch .update hinterlegen könnte, hat sich auch noch nicht gefunden.
Die gibt es zwar nicht, die kann man aber anlegen und wird dann auch von systemd ausgeführt. Das ist aber nicht "recommended".
Diese systemd mount Unit läuft bei mir:
Der Name muss der Unit muss der Ausgabe von
entsprechen.
