[gelöst] vdr-plugin-iptv (Zabrimus) meldet SSL_get1_peer_certificate nach upgrade von openssl

Dr. Seltsam · August 2, 2026 at 7:05 PM

Nachdem ich beim iptv-Plugin von Zabrimus ein git pull gemacht hatte, wollte es nicht mehr kompilieren:

Quote

Sorry, OpenSSL versions prior to 3.0.0 are not supported

Das System lief noch unter Ubuntu 20.04 mit openssl 1.1.1 - also habe ich mir die Sourcen von openssl-3.0.21 geholt und mit ./Configure, make und make install installiert. ldconfig meldet keinen Fehler und auch ein 'make test' im openssl-3.0.21-Ordner bringt keine Fehler. Das iptv-Plugin meldet beim Kompilieren keine Fehler - muss also die neue Version benutzt haben (denn SSL_get1_peer_certificate gab es in der Version 1.1.1 noch nicht). Beim Starten kommt aber die Meldung

Quote

ERROR: /usr/local/lib/vdr/libvdr-iptv.so.13: undefined symbol: SSL_get1_peer_certificate

Irgendwas im Plugin greift also weiterhin auf die alte opnssl-Version zurück. Was kann ich tun?

Zabrimus · August 3, 2026 at 7:16 AM

Du scheinst einen Mischbetrieb mit openssl 1.1.1 und 3 zu haben.

Die Fehlermeldung "Sorry, OpenSSL versions prior to 3.0.0 are not supported" wird direkt beim compilieren von httplib ausgeworfen, das ich für den m3u Handler benutze. Die Header werden also benutzt. Irgendwie ist das doch seltsam, daß nicht auch der Linker über die fehlende Funktion meckert.

Code

#if defined(OPENSSL_IS_BORINGSSL) || defined(LIBRESSL_VERSION_NUMBER)
#if OPENSSL_VERSION_NUMBER < 0x1010107f
#error Please use OpenSSL or a current version of BoringSSL
#endif
#define SSL_get1_peer_certificate SSL_get_peer_certificate
#elif OPENSSL_VERSION_NUMBER < 0x30000000L
#error Sorry, OpenSSL versions prior to 3.0.0 are not supported
#endif

Was sagt denn ldd libvdr-iptv.so.12 oder welche API Version du auch immer hast. 13? 11?

Vielleicht hilft, wenn du vor dem Aufruf von vdr den LD_LIBRARY_PATH anpasst. Etwa so

LD_LIBRARY_PATH=<pfad zu den openssl 3 libs>:$LD_LIBRARY_PATH ./vdr

Dr. Seltsam · August 3, 2026 at 9:24 AM

Ich konnte es letztlich lösen, indem ich konsequent alle ssl*-Dateien in /etc/ssl/ auf die entsprechenden neuen Dateien in/usr/local/ssl mit Symlinks umgebogen habe. Ebenso die in /usr/lib/ssl/ und /usr/lib/aarch64-linux-gnu auf die entsprechenden neuen Dateien in /usr/local/lib.

Ich hätte eigentlich gedacht, dass binaries und libs unterhalb von /usr/local immer Vorrang haben, aber anscheinend war das in diesem Fall nicht so.

Dr. Seltsam · October 1, 2026 at 1:30 PM

Moin Zabrimus,

ein Problem habe ich jetzt noch: Wenn vdr auf einem iptv-Kanal startet, ist das Bild immer schwarz und im Log steht

Code

Oct 01 13:11:13 CoreELEC vdr[5001]: [5001] switching to channel 57 I-1-10301-10301 (Das Erste HD)
Oct 01 13:11:13 CoreELEC vdr[5001]: [5001] IPTV-ERROR: gethostbyname() failed: 232.0.20.! is not valid address: Vorgang nicht zulässig
Oct 01 13:11:13 CoreELEC vdr[5001]: [5001] [socket.cpp,202]: setsockopt(MCAST_JOIN_SOURCE_GROUP): Das Argument ist ungültig
Oct 01 13:11:13 CoreELEC vdr[5001]: [5001] IPTV-ERROR: gethostbyname() failed: 232.0.20.! is not valid address: Vorgang nicht zulässig
Oct 01 13:11:13 CoreELEC vdr[5001]: [5001] [socket.cpp,202]: setsockopt(MCAST_JOIN_SOURCE_GROUP): Das Argument ist ungültig

Die betreffende channels,conf-Zeile lautet

Code

Das Erste HD;IPTV:410:S=1|P=0|F=UDP|U=87.141.215.251@232.0.20.35|A=10000:I:0:256=27:267=mis@3;257=deu@122:259;262=deu:1A:10301:1:10301:0

Wie Du siehst, ist die Adresse auch nicht 232.0.20.! sondern 232.0.20.35

Wenn ich mir den Code anschaue

Code

bool cIptvSocket::CheckAddress(const char *addrP, in_addr_t *inAddrP) {
    if (inAddrP) {
        // First try only the IP address
        *inAddrP = inet_addr(addrP);

        if (*inAddrP==htonl(INADDR_NONE)) {
            debug1("%s (%s, ) Cannot convert to address", __PRETTY_FUNCTION__, addrP);

            // It may be a host name, get the name
            struct hostent *host = gethostbyname(addrP);
            if (!host) {
                char tmp[64];
                error("gethostbyname() failed: %s is not valid address: %s", addrP,
                      strerror_r(h_errno, tmp, sizeof(tmp)));

                return false;
            }

            *inAddrP = inet_addr(*host->h_addr_list);
        }

        return true;
    }

    return false;
}

Display More

ist mir nicht klar, woher das Ausrufzeichen anstelle der 35 kommt.

Es reicht, einen Kanal vor und zurück zu schalten, dann ist der Fehler weg und kommt auch nicht wieder, solange vdr läuft. Es funktioniert auch, wenn vdr auf einem DVB-C-Kanal startet und ich dann auf einen iptv-Kanal umschalte. Der Fehler tritt nur auf, wenn der erste Kanal, auf dem vdr beim Starten schaltet, ein iptv-Kanal ist.

Dr. Seltsam · October 1, 2026 at 4:06 PM

ich glaube ich habe die Ursache gefunden:

Post

RE: [VDR 2.8.3] Schneller umschalten

Hallo zork ,

der Teil 1 des Patches hat leider eine unerwünschte Nebenwirkung beim iptv-Plugin.

Dr. Seltsam

October 1, 2026 at 4:05 PM

zork · October 2, 2026 at 7:47 PM

Dr. Seltsam , Deine Analyse paßt nicht, es ist ein alte Fehler im iptv-Plugin, den der Patch nur zufällig sichtbar macht.

In protocoludp.cpp zerlegt SetSource() die Adresse Quelle@Gruppe in ihrem eigenen Puffer und kopiert den Gruppenteil dann mit strcpyrealloc() in denselben Puffer zurück. Dabei wird der Puffer erst verkleinert, und glibc schreibt seine Verwaltungsdaten genau dorthin, wo noch die Gruppenadresse steht. So wird aus 232.0.20.35 ein 232.0.20.!, das ! ist ein Byte dieser Verwaltungsdaten. Ob das passiert, hängt nur davon ab, wie der Speicher gerade belegt ist. Deshalb trifft es meist nur das erste Umschalten nach dem Start, und Hin- und Herschalten behebt es. Der Patch verändert lediglich die Speicherbelegung beim Start.

Mit dem angehängten Patch fürs iptv-Plugin startet VDR hier wieder sauber auf einem IPTV-Kanal mit Quell-Multicast (wie bei der Telekom). Zabrimus , möchtest Du den Patch übernehmen?

Dr. Seltsam · October 2, 2026 at 7:59 PM

wow. Ich bin beeindruckt

Zabrimus · October 2, 2026 at 11:49 PM

Quote from zork

Mit dem angehängten Patch fürs iptv-Plugin startet VDR hier wieder sauber auf einem IPTV-Kanal mit Quell-Multicast (wie bei der Telekom). Zabrimus , möchtest Du den Patch übernehmen?

Multicast habe ich bisher komplett ignoriert. Das muss ja ein echt alter Fehler sein. Den Patch habe ich ins Repository übernommen.

cinfo · October 3, 2026 at 9:14 AM

Quote from zork

...
Mit dem angehängten Patch fürs iptv-Plugin startet VDR hier wieder sauber auf einem IPTV-Kanal mit Quell-Multicast (wie bei der Telekom). Zabrimus , möchtest Du den Patch übernehmen?

Schade das mit Magenta TV die Zeit für den VDR & Telekom vorbei ist

Quote

Keine frei zugänglichen Adresslisten mehr: Es existieren für MagentaTV 2.0 keine öffentlichen Multicast-Adresslisten mehr, die man in das vdr-plugin-iptv oder die channels.conf eintragen könnte.

also Bleibt nur die Lösung auf Zattoo/M3U oder waipu.tv auszuweichen

Quote

Freie IPTV-Listen (Zattoo/M3U oder waipu.tv): Für unverschlüsselte öffentlich-rechtliche Sender können Sie auf freie, legale Internet-Streaming-Listen (z. B. direkt aus den Mediatheken via HLS) ausweichen, sofern entsprechende VDR-Plugins (wie vdr-plugin-softhddevice mit libavformat) die Wiedergabe dynamischer Streams unterstützen.

da wäre der Gedanke von zork doch ein guter Ansatz

zork · October 3, 2026 at 9:40 AM

Quote from cinfo

Schade das mit Magenta TV die Zeit für den VDR & Telekom vorbei ist

OK, ich bin da nicht so in dem Thema. Kannst Du das erklären?

Wenn man eine Widevine Unterstützung in iptv hätte, müssten doch "theoretisch" sehr viele Streaming-Dienste gehen, oder?

Dr. Seltsam · October 3, 2026 at 11:11 AM

Ich habe seit Ewigkeiten in meinem "MagentaZuhause XL mit TV"-Anschluss das MagentaTV mit Multicast. Anscheinend ist das aber bei Neuverträgen bzw. Neu-Anschlüssen nicht mehr zu bekommen. Mir sind bisher aber auch keine Bestrebungen bekannt, bestehende Anschlüsse auf MagentaTV 2.0 umzustellen. Nutzen tue ich es dennoch kaum - im Prinzip ist es nur eine backup-Reserve, falls es mal Störungen im Kabelnetz gibt (was es in zunehmender Häufigkeit gibt).

Alle Anbieter sind nach dem Medienstaatsvertrag (ehemals Rundfunkstaatsvertrag) verpflichtet, die öffentlich-rechtlichen Sender frei und unverschlüsselt zu übertragen. Das gilt auch für Streamingangebote. Und dafür braucht man auch gar keinen TV-Tarif bei seinem Internetprovider. Mit den Adressen von hier sollte das bei jedem gehen, der einen Internetanschluss hat. Im vlc klappt das Öffnen der m3u8-Streams zumindest auf Anhieb.

Anscheinend soll auch das kommende DVB-I sowohl dash als auch HLS und Multicast nutzen. Was sich durch DVB-I verbessern bzw. vereinheitlichen soll, ist wohl die einheitliche Verwaltung von Kanallisten, Programmdaten und Metadaten. Insofern könnte es durchaus sinnvoll sein, die Unterstützung für die Protokolle im iptv-Plugin weiterzuentwickeln.

Was wivedine angeht bin ich nicht ganz im Bilde. Für die öffentlich-rechtlichen sollte das nicht notwendig sein. Nutzen das die Anbieter für Privatsender in HD? Was für ein wivedine-Level wird dann für HD-Empfang benötigt? Bzw. sind dazu Hardware-Lizenzen der empfangenen Box notwendig? Mein Kenntnisstand ist bisher, dass Amazon Prime, Netflix etc. nur mit offizieller App bzw. Hardware in HD-Qualität funktioniert. Unter Kodi daher nur 480 oder 576 Zeilen.

cinfo · October 3, 2026 at 12:21 PM

Hi,

die Deutsche Telekom stellt alle bestehende Anschlüsse schrittweise und in Wellen auf MagentaTV 2.0 um.

Quote

Die alte TV-Plattform hat fast zwei Jahrzehnte auf dem Buckel. Seit Februar 2024 gibt es den Nachfolger. Seitdem stellt die Telekom um. In Wellen. Schritt für Schritt. Ohne festen Termin. Intern nennt die Telekom das MagentaTV 2.0.
Die Unicast-Streams von MagentaTV 2.0 sind für fast alle privaten Sender und die Pay-TV-Kanäle mit Widevine DRM verschlüsselt.
Wechsel der Software (Kodi): Für das Mediencenter Kodi existiert ein inoffizielles, von der Community gepflegtes Addon namens pvr.magenta-git. Dieses nutzt das Web-Backend von MagentaTV (web2.magentatv.de). Da Kodi über integrierte Widevine-Decoder (über Inputstream Adaptive) verfügt, lassen sich dort die Streams von MagentaTV 2.0 abspielen. Viele VDR-Nutzer verwenden Kodi als Frontend und binden den VDR nur noch für klassisches DVB-S2/C-Fernsehen als Backend ein.
MagentaTV 2.0 vollständig über Kodi empfangen
Um sämtliche gebuchten Sender von MagentaTV 2.0 (inklusive RTL HD, ProSieben HD und Pay-TV) flüssig mit EPG und Timeshift zu nutzen, bindest du das inoffizielle PVR-Addon ein. Dieses simuliert ein offizielles Endgerät und nutzt Widevine DRM zur Entschlüsselung im Hintergrund.

Klassische Festplatten-Receiver (wie der Media Receiver 401 oder 601) sind nicht mit MagentaTV 2.0 kompatibel und funktionieren danach nicht mehr. Bei Bedarf wird neue Hardware (wie die MagentaTV One) bereitgestellt.
Verlust von Aufnahmen: Lokal auf alten Receivern gespeicherte Sendungen können nicht auf die neue Cloud-Plattform übertragen werden und gehen bei der Umstellung verloren.

Mein Erfahrung nach ist das bei alle Kunden der T-COM, wo z.B. ein GF-Anschluß und MagentaTV im Spiel ist, auch immer die Version 2.0 zum Einsatz kommt.

Quote

MagentaTV 2.0 basiert rein auf Unicast-Streaming (OTT) und nutzt im Gegensatz zur alten 1.0-Plattform keine Multicast-Signale mehr. Die Streams werden wie bei Netflix oder Waipu.tv als dynamische HTTP-Streams (HLS/DASH) direkt an die Endgeräte ausgeliefert.

Wer raus finden möchte wann man an der Reihe ist kann das über sein genutzten Receiver oder Tarif im Netz in Erfahrung bringen.

Quote

Wenn man eine Widevine Unterstützung in iptv hätte, müssten doch "theoretisch" sehr viele Streaming-Dienste gehen, oder?

das denke ich auch.

jojo61 · October 3, 2026 at 12:41 PM

Quote from zork

Wenn man eine Widevine Unterstützung in iptv hätte, müssten doch "theoretisch" sehr viele Streaming-Dienste gehen, oder?

Die gibt es doch bereits mit dash2ts. Da ist widevine unterstützung drin und es läuft prima mit zattoo. Ich würde ja auch noch waipu testen wenn ich einen account hätte. Aber es müsste eigentlich funktionieren.

Bei Zattoo ist MTV mit widevine geschützt, läuft aber mit dash2ts.

cinfo · October 4, 2026 at 9:15 AM

Es bleiben wohl 3 Anwendungsbereiche: waipu, Zattoo, MagentaTV 2.0 (https://github.com/nirvana-7777/pvr.magenta)

[gelöst] vdr-plugin-iptv (Zabrimus) meldet SSL_get1_peer_certificate nach upgrade von openssl

Dr. Seltsam August 3, 2026 at 9:25 AM

RE: [VDR 2.8.3] Schneller umschalten

Participate now!

Dr. Seltsam August 3, 2026 at 9:25 AM

RE: [VDR 2.8.3] Schneller umschalten

Participate now!

Dr. Seltsam August 3, 2026 at 9:25 AM