Ja, und kann die dann den Ausstieg des VDR beim Thread-Ende verursachen?
Jetzt muß ich nur rausfinden, welches Plugin. Habe aber vorerst den snapshot von vor dem Upgrade wieder aktiviert. Der 2.7.7 hat das Problem noch nicht.
Mal sehen, ob es da noch Erkenntnisse gibt.
Danke!
Tritt das mit "plain vanilla" VDR auf oder ist ein Plugin oder Patch im Spiel?
Danke 
Die Plugins sind dieselben wie bei 2.7.7.
Der Absturz tritt etwa alle 2-3min auf und immer nach
Jan 23 15:45:19 hdvdr2 vdr: [6560] VNSI: Requesting clients to reload channel list
Jan 23 15:45:21 hdvdr2 vdr: [6513] channel 17 (One HD) event Fr. 23.01.2026 15:35-16:15 '' status 0->4
Jan 23 15:45:23 hdvdr2 vdr: codec/audio: drift( -442) 922us 442
Jan 23 15:45:24 hdvdr2 vdr: [6560] VNSI: Requesting clients to reload channel list
Jan 23 15:45:28 hdvdr2 vdr: [7481] cAddEventThread thread ended (pid=6502, tid=7481)
Jan 23 15:45:32 hdvdr2 vdr[6502]: *** stack smashing detected ***: terminated
Jan 23 15:45:33 hdvdr2 yavdr-frontend[4523]: INFO:pydbus2vdr:VDR Status: stopped
Immer nach Kanal-Aktualisierungen und cAddEventThread thread ended (
journalctl sagt mir jetzt, übrigens ohne vnsi und epgsearch-Plugins:
än 23 16:07:01 hdvdr2 vdr[23371]: [24328] cAddEventThread thread started (pid=23371, tid=24328, prio=high)
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] --- begin invalid lock sequence report
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] TID T C R DR S ST
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - R - - R - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - * - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - * - - U - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - U - - - - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - W - - - - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 24328 - W - - W - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 23374 - - - - U - - - - - U
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 24328 - R - - R - - - - - L
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] 24328 invalid lock sequence: 2 Channels
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] full backtrace:
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] /usr/bin/vdr cStateLock::Lock(cStateKey&, bool, int) calling ?? at ??:0
Jän 23 16:07:01 hdvdr2 vdr[23371]: [24328] /usr/bin/vdr cChannels::GetChannelsRead(cStateKey&, int) calling ?? at ??:0
Jän 23 16:07:01 hdvdr2 vdr[23371]: invalid lock sequence at Fr. 23.01. 16:07
Danach bei Ende des cAddEvent-Threads wieder
Jan 23 16:07:23 hdvdr2 vdr: [23382] channel 17 (One HD) event Fr. 23.01.2026 15:35-16:15 '' status 0->4
Jan 23 16:07:31 hdvdr2 vdr: [24328] cAddEventThread thread ended (pid=23371, tid=24328)
Jan 23 16:07:32 hdvdr2 vdr: codec/audio: drift( -160) 333us 160
Jan 23 16:07:39 hdvdr2 vdr[23371]: *** stack smashing detected ***: terminated
Uhm, wie debugge ich die Meldung "*** stack smashing detected ***: terminated" in vdr (führt zum regelmäßigen Neustart, jetzt mit der Version 2.7.8 erstmals aufgetaucht)?
Die müßten direkt unter /usr/lib/modules/5.4.0-204-generic/updates (Ordner dvb-core, frontends usw.) sein. Notfalls de- und neuinstallieren (sudo apt purge dddvb-0.9.38-0easyVDR1, sudo apt install dddvb-dkms-0.9.40a-0esyVDR5) und dann sicherheitshalber noch ein "depmod -a" machen.
0easyVDR1Anschließend sollte ein "modprobe ddbridge" funktionieren.
Achtung: das dkms-Paket funktioniert nicht, wenn es gleich automatisch nach einem Kernel-Update installiert wird. Es muß mit dem bereits laufenden Kernel nochmal installiert werden!
ich schalte das yaVDR System, dessen Fernbedienung Probleme macht, per Tastendruck auf einem Lichtschalter ein bzw. aus
Ups - d.h. ohne es vorher herunterzufahren?
Ja, moderne Dateisysteme halten einiges aus, aber dadurch werden keine Einstellungs- oder Kanaländerungen mehr gespeichert vom yaVDR, da die großteils nur im Speicher bleiben bis zum Runterfahren des vdr-Prozesses.
Die CAID wird bei automatischen Updates der channels.conf nicht angerührt, da die ja gerätespezifisch ist.
Die Conditional Access-ID definiert, ob der Kanal verschlüsselt ist und wie er dechiffriert wird. Auch mehrere IDs sind als kommagetrennte Liste möglich.
Die entsprechende Methode ist in der Datei ca.conf beschrieben.
Bei mir läuft markad "unabhängig" als Dienst. Ich lasse im "after recording"-Script erstmal nur eine Semaphor-Datei ins Aufnahmeverzeichnis stellen, der markad-service (macht auch h265) prüft regelmäßig das Vorhandensein solcher Dateien und stellt die Jobs in eine Warteschlange. Bei hoher "load" wird die Bearbeitung hinausgezögert.
"-t ext4" (auf das -t folgt der Filesystem-Typ).
Bitte vdr-plugin-iive-ng verwenden.
Restfulapi sollte es jedenfalls in seahawks repos geben:
# apt-cache policy vdr-plugin-restfulapi
vdr-plugin-restfulapi:
Installiert: 1:0.2.6.8-0yavdr0~focal
Installationskandidat: 1:0.2.6.8-0yavdr0~focal
Versionstabelle:
*** 1:0.2.6.8-0yavdr0~focal 500
500 http://ppa.launchpad.net/seahawk1986-ho…dr-2.7.7/ubuntu focal/main amd64 Packages
Wohl notwendig, die Source zu holen und für arm zu kompilieren.
Äquivalent wäre wohl svdrpapp, das braucht kein Plugin, muß aber wohl als APK installiert werden am Android-Device.
Danke mal
Leider dürfte es das nicht sein:
~# g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.3) 9.4.0
Na ich warte mal auf das kompilierte Plugin von Seahawk ...
Hi, ich habe das git von vdr-plugin-epgsearch verfolgt, kann aber 2.4.5 nicht mehr kompilieren:
In file included from blacklist.c:25:
epgsearchtools.h:156:42: error: ‘std::string encodeSpecialCharacters’ redeclared as different kind of entity
156 | std::string encodeSpecialCharacters(std::string_view s, bool nestedColon = false);
| ^~~~~~~~~~~
epgsearchtools.h:154:7: note: previous declaration ‘char* encodeSpecialCharacters(const char*, bool)’
154 | char* encodeSpecialCharacters(const char* s, bool nestedColon = false);
| ^~~~~~~~~~~~~~~~~~~~~~~
epgsearchtools.h:156:42: error: ‘string_view’ is not a member of ‘std’
156 | std::string encodeSpecialCharacters(std::string_view s, bool nestedColon = false);
| ^~~~~~~~~~~
epgsearchtools.h:156:42: note: ‘std::string_view’ is only available from C++17 onwards
epgsearchtools.h:156:57: error: expected primary-expression before ‘bool’
156 | std::string encodeSpecialCharacters(std::string_view s, bool nestedColon = false);
| ^~~~
epgsearchtools.h:157:42: error: ‘std::string decodeSpecialCharacters’ redeclared as different kind of entity
157 | std::string decodeSpecialCharacters(std::string_view s, bool nestedColon = false);
Verwende noch focal (mit esm und letztem LTS-Kernel.
Wo liegt hier der Fehler bei mir?
Oh, in der channelmap.conf von tvscraper stehen sowohl die SAT- als auch die DVB-C-Kanäle. Interessanterweise zeigt bei Loglevel=3 der tvscraper im Journal nur die C-Kanäle an:
tvscraper: scraping Channel ARD alpha HD C-1537-36-36003 TheTVDB company ID 77
aber nichts dergleichen von den SAT-Kanälen. In der EPG-Ansicht (vdradmin oder live) wird aber bei beiden Kanälen dasselbe angezeigt.
Aktuell habe ich einen defekten SAT-Tuner, und nur mehr einer der Doppeltuner arbeitet, deshalb auch verwende ich DVB-C für die Suchtimer, wo es geht.
Da habe ich ein Problem mit Kabel-TV-Sendern, die üblicherweise nur 1-3 Tage epg liefern: mal klappt Serie+Folge, oft aber auch nicht - bzw. hatte ich bisher manchmal den Effekt, daß urprünglich die Info vorhanden ist, kurz vor der Aufnahme aber verschwindet und somit die Aufnahme nicht im Serien-Ordner landet. Hoffe, das wird nun besser.
Kann auch sein, daß - da ich mit epgfixer die zugehörigen SAT-Kanäle wegen 1-2 Wochen epg-Vorlauf klone - dann, wenn das Kabel-EPG greift, doch überschrieben wird?
Moderne PC´s haben doch gar keine Batterie mehr, sondern nutzen NVRAM statt CMOS, oder?
Nun ja, aber nur dann, wenn sie keine Uhr und keine Möglichkeit des zeitgesteuerten Einschaltens haben. Trifft eher für Thinclients zu.
Nur eine blöööde Frage: wie sieht es mit der CMOS-Batterie aus?
Zum Testen vielleicht auch mal mit minimaler Peripherie, insbes. betr. USB-Geräte, das Wakeup probieren.
Auch "schwarzes Bild" könnte ein OSD (mit dem die Aufnahme ausgewählt wird) darstellen, sobald auf der FB das Menü aufgerufen wird?
Gerade, wenn nur 1 Tuner vorhanden ist, wäre das wichtig. Ich hatte da ein Script, das regelmäßig den TV pingt und nach dem Abschalten (Standby mittels FB) auch das softhddevice detached sowie nach dem Einschalten wieder attached.
Ich glaube, es geht auch weniger ums Stromsparen, sondern ums "Tuner-Sparen" 
Sprich, der Tuner ist dann für den VDR nicht mehr durch ein Live-Signal belegt und kann für eine Aufnahme oder EPG-Scan verwendet werden.
Allerdings braucht eine NVIDIA-Karte doch auch weniger Strom, wenn sie nicht gerade ein HD-Signal dekodieren und darstellen muß, das merkt man an der Temperatur oder der Lüfterdrehzahl.
Und, wenn dynamite läuft, kann auch ein nicht benötigter Tuner inkl. DVB-Stromversorgung "schlafen gehen".
Bei den vielen Fülldaten bringt ein recodieren in h.264 oft erstaunlich viel.
Nun, dafür sollte auch naludump reichen, das benötigt weniger Ressourcen und sollte auch auf ARMs gut laufen.
Naja, die Aufnahme war schon "HD" und in h264 komprimiert, da hätte nur Konvertierung zu h265/hevc was gebracht. Die wird aber nur nach Konfiguration durchgeführt.
