Ich dachte immer systemctl stop würde solange warten, bis der Prozess weg ist.
Ja das dachte ich auch und das soll wohl auch so sein. Aber beim testen habe ich es halt auch anders gesehen. Wobei ich mir nicht absolut sicher bin ob der vdr da beim runterfahren nicht einfach gecrasht ist und deswegen der stop nicht geklappt hat.
ich nutze standardmäßig die Variante mit detach/attach
DU solltest auf jeden Fall noch in der softhdodroid.conf das "-g 3840x2160" einfügen. Man kann damit auch für den vdr eine andere Auflösung als für den Kodi einstellen.
Jetzt habe ich auch den Fehler beim umschalten zwischen Kodi und VDR gefunden und gefixt.
Es gibt ja 2 varianten des umschaltens. Einmal mit detach und attach und einmal mit systemctl start oder stop vdropt. Die Variante mit start und stop funktioniert allerdings nichts sauber weil beim stop nicht immer auf das beenden vom vdr gewartet wird.
Warum das so ist kann ich nicht feststellen. Allerdings wenn der vdr noch läuft und der kodi schon hochfährt dann bekommt kodi das GUI nicht (weil der vdr das drm noch nicht freigegeben hat) und der Screen bleibt schwarz.
Deswegen empfehle ich die Variante mit detach/attach. Dazu ist in /storage/.profile die Zeile "SWITCH_VDR_SCRIPT=/usr/local/bin/switch_vdr_softhdodroid.sh" einzufügen.
Habe nun ein wenig mit der CE22-NO Version rumgespielt und dort das Multichannel Audio sowie das GrabOSD gefixt. Damit stürzt er bei live nicht mehr ab und die Audio Probleme sollten gefixt sein.
Das ganze ist aber immer nocht recht instabil und der vdr crasht bei jedem runterfahren. Beim umschalten zwischen Kodi und VDR ist mir das Problem mit dem fehlenden Video bisher nicht aufgefallen.
Da werde ich nun aber mal intensiver testen.
Vermutlich wird beim Detach des VDR bzw. softhdodroid noch nicht alles bzgl. des Displays released.
Dann müsste das Problem auch bei einer 1080er Auflösung auftreten.
Ich bin eh gerade dabei für CE22-no noch ein paar Änderungen einzubauen. Ich schaue mir das Problem mit dem 2160p dann mal an.
in softhdodroid.conf sind keine Parameter gesetzt.
Ok dann mach mal die Gegenprobe und setze ein "-g 3840x2160" in die softhdodroid.conf
Die Version CE-22 ist noch alpha und das zusammemspiel mit Kodi ist noch völlig ungetestet.
Hast du in der softhdodroid.conf den Paramter -g 3840x2160 eingetragen ? Wenn du schon in 3840x2160 bootest, dann lass den Parameter mal weg.
Ein einfacher Fix wäre also, den RunningStatus nur vor dem Löschen von VPS Timern zu prüfen.
Genau das macht mein patch.
Es hat nichts mit IPTV zu tun. Es ist ein Fehler im handling von Timern ohne VPS.
es ist möglicherweise sinnvoller das Kodi Addon "multimedia-tools" zu installieren
ja das ist deutlich einfacher. Das werde ich installieren.
Ich habe mich mal an einem Patch versucht. Damit funktioniert es bei mir. Aber ob das sauber ist muss kls sagen.
Ich habe auch ohne EPG getestet, aber der Fehler tritt auch mit EPG auf. Ich habe den Fehler gestern auch auf einem DVB-S2 Kanal mit EPG gesehen. Ich denke es gibt da noch einen Bug bei Timern ohne VPS.
Beim löschen (Test ob Expired) wird da auf einen RunningStatus getestet den der Timer nicht erreicht. Und deswegen Expired der Timer nie.
Mal schauen was Klaus dazu findet.
Der RunningStatus spielt aber doch nur bei VPS-Aufnahmen eine Rolle.
Der Timer ist ohne VPS und der Stream ist h264. Aber beim löschen eines Timers in cTimer::Expired wird auf event->RunningStatus() == SI::RunningStatusNotRunning abgefragt und dahin kommt der Status nicht. Er bleibt auf RunningStatusUndefined stehen.
Edit:
Diese Regel wurde laut meinem Codeeditor erst vor 5 Monaten eingebaut.
Kommen beim Compilieren der Plugins oder im Log irgendwelche "deprecated" Meldungen?
Nein das ist alles sauber.
Ich habe nun mal etwas debugged und so wie es aussieht bleibt der Runningstatus für diesen Timer immer auf 0 = RunningStatusUndefinded. Deswegen wird er dann nicht mehr gelöscht.
Die Aufnahme ist zwar perfekt aber der VDR sagt es seien 3000 Fehler drin. Wie werden diese Fehler denn nochmal berechnet. Könnte es sein das hier im Videostream evtl. Komponenten fehlen die hierfür herangezogen werden und deswegen der RunningStatus nie aktualisiert wird ?
Da hilft nur herauszufinden, welche Bedingung im VDR das Löschen verhindert.
Also wenn es bei dir funktioniert ist das schon extrem seltsam. Da werde ich dann wohl mal ein paar Debugs in den VDR einbauen müssen.
Naja man hat ja sonst nix zu tun 
Ist igendwas an dem Eintrag in der channels.conf speziell?
Zumindest sehe ich da nichts:
ORF3;IPTV:620:S=1|P=1|F=EXTT|U=dashstream.sh|A=3:I:0:256=27:257=@4:0:0:3:30:70:0Ich habe hier noch testweise 2.7.4 laufen. Hat sich da etwas im VDR geändert?
Ich habe 2.7.7 aber habe keine Ahnung ob Klaus da etwas geändert hat. Ich schau mal ins changelog
Edit: Im Log für die 2.7.7 steht:
- Reworked cTimer::Matches() Das könnte evtl. die Ursache sein. kls Liest du mit ?
Timer ist weg und Aufnahme ist da. Ich weiß nicht mehr, wo ich da suchen soll.
Ich hatte meinen Post noch etwas nachgearbeitet. Ich vermute nun das es tatsächlich der VDR ist der den Timer beim löschen nicht findet. Warum auch immer.
Ist das Problem vielleicht vom Protokoll abhängig? F=XXX?
hmmm... ich nutze da F=EXTT weil ich ja mit dash2ts teste.
Ich schau mal was im Log passiert und poste es dann.
Edit:
Hier das Log. Sieht eigentlich gut aus, aber der Timer bleibt bestehen. Zumindest ist die dash2ts Instanz gestoppt worden.
Dez 26 12:35:00 CoreELEC vdr[1170]: [1170] timer 1 (39 1229-1235 'ORF3') stop
Dez 26 12:35:00 CoreELEC vdr[1170]: [1170] removing /storage/videos/ORF3/2025-12-26.12.29.39-0.rec/.timer
Dez 26 12:35:00 CoreELEC vdr[1170]: [1170] executing '/storage/.config/vdropt/makesleep after "/storage/videos/ORF3/2025-12-26.12.29.39-0.rec"'
Dez 26 12:35:00 CoreELEC vdr[1170]: [1391] EPGSearch: recdone thread started (pid=1170, tid=1391, prio=high)
Dez 26 12:35:00 CoreELEC vdr[1170]: [1391] EPGSearch: recdone thread ended (pid=1170, tid=1391)
Dez 26 12:35:00 CoreELEC vdr[1170]: [1320] IPTV streamer thread ended (pid=1170, tid=1320)
Dez 26 12:35:00 CoreELEC vdr[1170]: [1319] device 6 receiver thread ended (pid=1170, tid=1319)Was hier fehlt ist dein:
Dec 26 12:05:00 corvette vdr: [2904891] deleting timer 1 (404 1200-1205 'ZDF HD')Ist das reproduzierbar für alle Kanäle?
Ja bei mir passiert das auf allen IPTV Kanälen. Wie gesagt die Aufnahme stoppt so wie es im Timer definiert ist. Nur wird dann der Timer nicht gelöscht und die Hooks nicht angesprungen. Könnte es sein das der VDR irgendwie das Device schliessen will und das nicht bestätigt wird vom IPTV plugin. Mich wundert es halt das es nur bei IPTV auftritt.