ja das sind aber nur noch wenige Fälle, hat sich schon stark verbessert aber hat weiterhin potential nach oben.
Ist mir jetzt glücklicherweise erst das zweite Mal passiert und auch erst seit dem tvm "Ausfall" Anfang Juli.
Spätestens 72h vor Ausstrahlung fliegen die Events aber wieder raus wenn das DVB EPG wieder übernimmt
Dann warte ich dieses Mal ab.
ja die Daten sind aktuell von mäßiger Qualität, denke aber das spielt sich wieder ein wenn die frischen Studenten bei E.W.E angelernt sind
Die frischen Studenten scheinen lernresistent zu sein. 
Warum das so ist steht in #1257.
Ich habe den Vorschlag von seahawk1986 getestet, war weniger zu lesen. 
Du kannst ja mal versuchsweise KEY_COFFE aus lircd2uinput rauspatchen:
Nach ersten Tests scheint der Patch das Problem zu beheben. 
Hallo Helmut,
alle Tasten, die in der irmplircd.map eingetragen sind, habe ich auch für den VDR in Benutzung.
Leider ist es auch nicht nur eine einzige Taste, auf die der Empfänger des VDR reagiert. Ich habe zusätzlich noch die TV Fernbedienung und eine weitere getestet und mein Eindruck ist, dass der neue Empfänger auf jeden "Fremd-"Tastendruck reagiert.
#> irw
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 1 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 1 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 1 KEY_COFFEE devinput
98 0 KEY_COFFEE devinput
98 1 KEY_COFFEE devinput
#> irw
98 0 KEY_COFFEE devinput
98 1 KEY_COFFEE devinput
# Add your key mappings here (or change the path for the keymap in /etc/default/irmplircd)
15000f044600 KEY_TV
15000f044900 KEY_CAMERA
15000f044a00 KEY_PROG4
15000f044700 KEY_MP3
15000f041e00 KEY_UP
15000f041f00 KEY_DOWN
15000f042300 KEY_ESC
15000f042200 KEY_OK
15000f040c00 KEY_POWER2
15000f042000 KEY_LEFT
15000f042100 KEY_RIGHT
15000f045b00 KEY_RED
15000f045c00 KEY_GREEN
15000f045d00 KEY_YELLOW
15000f045e00 KEY_BLUE
15000f040000 KEY_0
15000f040100 KEY_1
15000f040200 KEY_2
15000f040300 KEY_3
15000f040400 KEY_4
15000f040500 KEY_5
15000f040600 KEY_6
15000f040700 KEY_7
15000f040800 KEY_8
15000f040900 KEY_9
15000f040f00 KEY_INFO
15000f041600 KEY_PLAY
15000f041800 KEY_PAUSE
15000f041900 KEY_STOP
15000f041700 KEY_RECORD
15000f041400 KEY_FASTFORWARD
15000f041500 KEY_REWIND
15000f041a00 KEY_NEXT
15000f041b00 KEY_BACK
15000f041200 KEY_CHANNELUP
15000f041300 KEY_CHANNELDOWN
15000f041c00 KEY_GRAVE
15000f041000 KEY_VOLUMEUP
15000f041100 KEY_VOLUMEDOWN
15000f040e00 KEY_MUTE
15000f045a00 KEY_TEXT
15000f044800 KEY_PVR
15000f042600 KEY_EPG
15000f042500 KEY_TIME
15000f042400 KEY_MENU
15000f040a00 KEY_DELETE
15000f040b00 KEY_IMAGES
15000f044c00 KEY_VIDEOIch habe jetzt doch noch ein Thema mit dem neuen Empfänger. Er reagiert leider auch auf "Fremdsignale", wie Signale für meinen Verstärker. Wenn unter yaVDR das Frontend detached ist, wird es aktiviert, obwohl das Signal nicht für den VDR bestimmt ist.
#> irw
98 0 KEY_COFFEE devinput
Ich bin dem Rat von IRMP Empfänger reagiert auf andere FB gefolgt, was aber leider nicht funktioniert hat.
In meinem Fall sendete die fremde FB den KEY_COFFEE.
In yavdr ansible-focal kann man das lösen indem man in die /etc/yavdr-frontend/config.yml im Abschnitt lirc folgendes einfügt.
lirc:
socket: /run/lirc/lircd
keymap:
KEY_COFFEE:
action: noop
KEY_POWER2:
action: poweroff # set to "yavdr_compat_poweroff" to mimic the behaviour of older yaVDR versionHat jemand einen Tipp, wie ich der Ursache auf den Grund gehen kann?
Ich nutze den Thread mal, da ich mich in die Liga der RP 2040 Zero I.R. Empfänger Besitzer eingereiht habe und möchte die Gelegenheit nutzen mich für den reibungslosen Ablauf nach der Bestellung und die Unterstützung bei der Installation und Konfiguration zu bedanken, einfach Top.
An dem Service von Helmut kann sich der eine oder andere Online-Shop eine Scheibe abschneiden. Selbst mein Sonderwunsch - externer Tsop Empfänger ohne Beleuchtung - wurde umgesetzt.
Ich habe im Moment die üblichen doppelten Einträge und gehe davon aus, dass diese nach erfolgreichen Merge verschwinden werden.
Da sind wir nochmal mit einem blauen Auge davon gekommen. 
also am 27sten hab ich noch akualisierte Dateien mit Änderungen (nicht mit neuen Tagen) bekommen die auch verarbeitet wurden, von daher gehe ich davon aus, dass die Schnittstelle bei denen noch in Betrieb ist und sich das wieder einspielt
Danke fürs Prüfen. Drücken wir die Daumen, dass es ich wieder einspielt.
Mein Sender-EPG ist bisher auch nicht wirklich über Freitag hinaus eingesprungen.
Kann ich hier auch bestätigen, dass das tvm-EPG am 04.07.25 endet.
Auf der anderen Seite:
#> wget http://www.clickfinder.de/daten/onlineda…remium-167.cftv
--2025-06-29 18:35:02-- http://www.clickfinder.de/daten/onlineda…remium-167.cftv
Auflösen des Hostnamens http://www.clickfinder.de (http://www.clickfinder.de) … 195.39.234.82
Verbindungsaufbau zu http://www.clickfinder.de (http://www.clickfinder.de)|195.39.234.82|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 41719 (41K)
Wird in ‘tvdaten-premium-167.cftv’ gespeichert.
tvdaten-premium-167.cftv 100%[================================================================================>] 40,74K --.-KB/s in 0,06s
2025-06-29 18:35:02 (733 KB/s) - ‘tvdaten-premium-167.cftv’ gespeichert [41719/41719]
keine, die letzten 72h vor dem Sendetermin ist das DVB epg führend, wenn es dort korrekt aktualisiert ist kommt es innerhalb von 1-10 Minuten im VDR an und würde sogar das externe EPG rauskicken wenn da was anderes steht. Auch Timer würden entsprechend angepasst. Wenn der Sender kein Update schickt dann passiert auch nix: das Design geht davon aus, dass der Sender den besseren Zeitstrahl sendet, das Externe dagegen bessere Inhalte.
Danke für die Erläuterung. Im erwähnten Papstbeispiel im ZDF hat des EPG auf dem Fernseher die Programmänderung berücksichtigt.
Ja, die beiden Varianten verhalten sich gleich (=Mischen Sender-EPG mit TVM), so lange blacklisten auf aus/nein steht.
Habe ich überprüft, Blacklisten steht auf nein.
Vielleicht hilft es, wenn du im OST in den EPG-Einstellungen die Zeit für die EPG-Aktualisierung nach unten drehst?
Weniger als 1 Stunde für die EPG-Aktualisierung scheint sich nicht einstellen zu lassen:
Dann habe ich mit den aktuellen Einträgen eine gewisse Redundanz:
vdr:000:0 = C-1-1019-10301
tvm:1:1 = C-1-1019-10301 Es sollte aber den gleichen Zweck erfüllen, wie
tvm:1 = C-1-1019-10301Am letzten Wochenende gab es eine Sondersendung zum neuen Papst, welche im VDR EPG nicht angezeigt wurde.
Daher frage ich mich, welche Einstellungen noch vorgenommen werden sollten, damit aktuelle Programmänderungen berücksichtigt werden?
Die von mir erwähnte OSD-Einstellung meint "in der channelmap.conf nicht konfigurierte Sender werden ge-blacklisted" (also ausgeschlossen und bekommen kein EPG).
Ist bei mir ausgeschaltet.
Ich möchte noch mal auf das Merge Thema der DVB und externen Quellen zurückkommen, weil ich gerne aktuelle Programmänderungen schneller berücksichtigt haben möchte.
// <merge> Merge DVB and externel EPG for this channel
// { 0, 1, 2 } (default 1, the default for source 'vdr' is 0) tvm:1 = S19.2E-1-1019-10301 // Das Erste HD
Würde ein Eintrag wie dieser reichen, damit das epg vom Sender bei Programmänderungen berücksichtigt wird?
Im OSD der Plugin Einstellungen könnte „nicht gelistete Kanäle blacklisten“ eingeschaltet sein.
Muss ich mal prüfen, wobei die Standard Öffis alle in der channels.conf und channelmap.conf
eingetragen sind.
Hat vielleicht noch jemand die TVM id von DMAX ?
Versuche mal 52.
die erste vdr:000 kannst du auch entfernen,
Hatte ich mal eingefügt in der Hoffnung, dass aktuelle Programmänderungen schneller berücksichtigt werden.
gegen DVB EPG wird ja eh gemischt es sei denn du schließt es explizit aus
Ich kann mich nicht erinnern, einen Ausschluss bewusst gesetzt zu haben.
nein, da die vermutlich auf :2 enden, dass muss :1 sein oder einfach die :2 rauslöschen
Sah bei mir bisher so aus und die letzte Zeile habe ich entfernt:
vdr:000:0 = C-1-1019-10301
tvm:1:1 = C-1-1019-10301
tvsp:ARD:2 = C-1-1019-10301 Aufgefallen ist mir nur:
#> grep -n SQL-Error /var/log/syslog|tail -1
36058:2025-05-19T20:58:19.506217+02:00 ryan vdr: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Incorrect string value: '\xFChrt N...' for column `epg2vdr`.`reco
rdinglist`.`description` at row 1 (1366) 'Incorrect string value: '\xFChrt N...' for column `epg2vdr`.`recordinglist`.`description` at row 1' [insert into recordi
nglist set actor = ?, audio = ?, camera = ?, category = ?, channelid = ?, channelname = ?, country = ?, description = ?, director = ?, duration = ?, episodecompna
me = ?, episodecomppartname = ?, episodecompshortname = ?, episodelang = ?, eventid = ?, flags = ?, folder = ?, fsk = ?, genre = ?, guest = ?, imgid = ?, inssp =
?, inuse = ?, job = ?, lastifoupd = ?, longdescription = ?, md5path = ?, moderator = ?, music = ?, name = ?, numrating = ?, other = ?, owner = ?, path = ?, produc
er = ?, rating = ?, screenplay = ?, scrinfoepisodeid = ?, scrinfomovieid = ?, scrinfoseriesid = ?, scrmovieid = ?, scrnew = ?, scrseriesepisode = ?, scrseriesid =
?, scrsp = ?, shortreview = ?, shorttext = ?, starttime = ?, state = ?, tipp = ?, title = ?, topic = ?, txtrating = ?, updsp = ?, vdruuid = ?, year = ?;]
Die Fehlermeldung scheint es aber schon vorher gegeben zu haben.
Neubau von vdr-epg-daemon bietet sich bei nicht aktueller Version natürlich an.
Ich habe mal mit dem Auskommentieren gestartet.