All Activity

Du hast eine PM. Die Media Server-Testversion sollte in Zukunft doppelte Timer für BR Süd verhindern, wird aber bereits vorhandene doppelte Timer nicht eliminieren. Das musst du manuell durch führen, indem du z.B. auf der Seite EPG-Suche dein quer-Preset auswählst, auf "Timer löschen" klickt und dann auf "Timer erzeugen".

Da kommt dann nach einiger Zeit ein Statuscode 403 forbidden beim Abrufen von Video/Audio-Segmenten, d.h. der Server liefert nicht mehr. Daraufhin greift die Option "Bei fehlendem Stream neu tunen nach..." des TS Stream-Gerätes (Standard 5 s, 0 = aus), und löst ein Retune aus, d.h. der DVBViewer bricht den Stream ab und verbindet sich neu mit dem Server, was dann wieder für ca. 30 Sekunden reicht, usw... Kurz gesagt liefert Youtube kein in einem Stream kombiniertes Video und Audio mehr, und wenn doch, dann nur begrenzte Zeit. Die Intention ist klar: Den Download von Videos erschweren. Deshalb bieten neuere Versionen von yt-dlp entsprechende URLs gar nicht mehr an, sondern liefern dem Plugin zwei URLs, eine für Video und eine für Audio. Für einen Download müsste man FFmpeg einsetzen, um sie zu einer Datei zu muxen. Im Prinzip können DVBViewer und DMS bei Live Streams im HLS-Format (M3U8) zwar mit separaten Video/Audio-Streams umgehen, brauchen dazu aber eine Master-Playliste, die den Zusammenhang herstellt. Deren URL war mit der älteren yt-dlp-Version und einem speziellen Kommandoparameter erhältlich (--print manifest_url), aber mit neueren geht das auch nicht mehr. Damit ist das Plugin erst mal praktisch nicht mehr brauchbar.

Ja, gerne würde ich die Testversion ausprobieren. Danke für deine Müheverwaltung 🙂

Stimmt, ist mir gar nicht aufgefallen, dass mit der aktuellen yt-dlp über URL öffnen nur Bild- aber keine Tonausgabe da war. Mit der Version vom 11. April 2026 und der 2026.06.09 gehts auch noch aber die Streams unterbrechen so alle 30sek. Das passiert mit der aktuellen nicht, wenn man über URL öffnen geht. Der Videostream läuft da durch, man hat nur kein Ton und aus der Senderliste heraus weder Bild noch Ton.

Gerade festgestellt. Mit meiner yt-dlp Version vom 11. April 2026 geht es, mit der aktuellen vom 14. November nicht mehr... offenbar hat sich der Output signifikant geändert. Jetzt muss ich erst mal schauen, was nun effektiv im Plugin ankommt.

So, noch mal auf frischer Tat ertappt (diesmal die quer-Sendung von 03.12.), und jetzt auch beliebig reproduzierbar, wodurch sich der Vorgang mit dem Debugger verfolgen ließ. Dazu braucht man ein Backup der svctimers.xml und der epg.dat, in der alle EPG-Daten gespeichert sind. Wenn sich ein Timer unerwünscht vervielfältigt, muss man den Media Server stoppen, die Dateien zurückkopieren, dann den Media Server starten, den EPG aktualisieren (wozu es reicht, BR Süd eine Weile im Webinterface wiederzugeben) und gleich danach die Auto-Timer-Erzeugung starten. Dann passiert es wieder. Die Ursache ist tatsächlich die geänderte Event ID der Sendung. Sowas sollte eigentlich nach den DVB-Spezifikationen nicht passieren, aber seitdem die Öffentlich-Rechtlichen die Finanzierung des IRT eingestellt haben, läuft bei ihnen technisch nicht mehr alles rund. Die Vervielfachung des Timers resultiert auf Umwegen daraus, dass nach der EPG-Aktualisierung die Sendung zunächst doppelt in der Datenbank des Media Servers vorhanden ist, einmal mit der alten und einmal mit der neuen Event ID. Zwar räumt der Media Server irgendwann aufgrund eines ständig im Hintergrund laufenden Cleanup die ältere Variante ab, aber dann ist die Auto-Timer-Erzeugung schon durchgelaufen. Inzwischen gibt es einen Fix, der dafür sorgt, dass der Media Server die ältere Variante der Sendung nicht mehr für Vergleiche heranzieht. Falls gewünscht, kann ich eine Testversion 3.3.3.1 als Anhang einer persönlichen Forum-Nachricht zur Verfügung stellen.

Hallo Griga, alle Vorschläge umgesetzt und alle URL-Varianten durchprobiert. Es bleibt leider dabei. Nur über URL-öffnen startet der Stream. Ich schicke dir nochmal eine aktuelle support.zip.

Ob der Autor hier noch mal in Erscheinung tritt, steht in den Sternen. Du kannst als Alternative das Mobil-Webinterface des Media Servers probieren, indem du im Browser deines Mobilgerätes http://[IP-Adresse des Media Servers]:8089/ios eingibst (gilt auch für Android). Es erlaubt eine weitgehende Kontrolle und Zugriff auf nahezu aller Media Server Features, dazu verschiedene EPG-Ansichten, Live-TV, DVBViewer-Fernbedienung etc. Im Vollbildmodus ist es praktisch von einer App kaum zu unterscheiden.

Hallo! 🙂 Ich habe eine Feature-Anfrage: Kann der DVBViewer Controller so geändert werden, dass er anhand der EPG-Daten je Sender nicht nur zeigt, welche Sendung aktuell läuft, sondern auch, welche danach laufen wird (ähnlich wie im DVBViewer-Fenster, wenn ich da per Mauszeiger über die Sender fahre, werden auch die aktuelle und die nächste Sendung angezeigt)? Beispielsweise kurz vor "Prime Time" (20:15 Uhr) wäre das nützlich, um nicht erst den Beginn der Sendung abwarten zu müssen, den man dann ja verpasst, um zu wissen, was man sehen möchte. Ich hätte auch die selbst versucht, diese Änderung vorzunehmen, aber der Sourcecode der letzten Versionen des DVBViewer Controllers ist bei github nicht verfügbar. Falls mir der Sourcecode der letzten Version zur Verfügung gestellt wird, könnte ich auch selbst versuchen, die Änderung vorzunehmen. Vielen Dank und viele Grüße!

Heute konnte ich das Problem nachvollziehen. Nach einem EPG Update und einer erneuten Timererzeugung war der Eintrag "quer" am 26.11. doppelt vorhanden. Feststellen konnte ich, dass sich die Event ID geändert hatte und der ältere Timer-Eintrag dann vom Media Server aktualisiert wurde. Das gibt dann auch einen Eintrag im svcdebug.log: allerdings bei dir nicht, weil du das Logging offenbar abgestellt hast. Deshalb fehlt das svcdebug.log. Was ich jedoch nicht herausfinden konnte: Wieso diese Änderung zu einem Doppeleintrag führt. Nachdem ich die vorherige svctimers.xml (mit der alten Event ID) aus einem Backup wiederhergestellt hatte, geschah die Timer-Verdopplung bei der Auto-Timererzeugung nicht mehr. Um das nachzuvollziehen, braucht es womöglich auch ein Backup der epg.dat, um den Zustand vor dem EPG-Update wieder herstellen zu können Es geht also weiter...

Der DMS bekommt bei dir schlicht keine Daten, was aus den Retune-Versuchen im svcdebug.log ersichtlich ist. Ich hatte mit deiner URL (die mit user) zunächst auch keinen Erfolg, aber nachdem ich sie im Browser probiert habe, wo sie funktionierte, ging es merkwürdigerweise auch mit dem DMS, ebenso wie zuvor mit den Alternativen https://www.youtube.com/watch?v=umLWFz4izTM oder https://www.youtube.com/@SkyNews/live Vorschläge: Streiche den Parameter &xx=1, der mit der aktuellen Version des Plugins unnötig ist (siehe hier). Aktualisiere DVBViewer & DMS auf die Versionen 7.3.3 / 3.3.3, damit wir auf einem Level sind. Probiere alternative URLs. Probiere im DVBViewer mit einem passend konfigurierten TS Stream-Gerät ohne Weiterleitung an den DMS (z.B. indem du den Tweak "TS Stream über den lokalen Media Server empfangen" abschaltest), ob so das gleiche Problem auftritt. Das TS Stream-Gerät (kein RTSP-Gerät) muss dabei in der DVBViewer-Geräteliste höchste Priorität haben, also an oberster Stelle stehen!

Danke für die ausführliche Erklärung. Doch doch, da ist ein TS-Stream Device eingerichtet. Seitdem du das yt-dlp-server Plugin zur Verfügung gestellt hast. Daran wurde auch nix geändert. Und es lief ja auch mal, nur jetzt kriege ich ums Verrecken keine YT Streams mehr rein, evtl. auch andere Twitch oder so, bisher nicht probiert, nur noch über die Schiene "URL öffnen" Ich schicke dir mal eine Support.zip per DM.

Nein. Du musst das Timeout vom Viewer im Viewer erhöhen. Der Media Server benutzt bei mir ein manuell konfiguriertes TS Stream Device, um den Stream von YouTube oder sonst wem zu empfangen und dann als HTTP-Netzwerkstream an den DVBViewer weiterzuleiten. Und der DVBViewer ein weiteres TS Stream Device, um den Stream vom Media Server zu empfangen. Deine Logs in diesem Post besagen bislang, dass du es ebenso machst. Dein Screenshot zeigt jedoch was anderes, nämlich kein TS Stream-Gerät, sondern ein RTSP Netzwerk-Gerät, das nicht HTTP, sondern RTSP/Sat>IP-als Protokoll benutzt und für TS Stream als Empfangsart konfiguriert ist. Das ist eine andere Schiene, die jedoch auch dafür geeignet ist, im DVBViewer Streams über den Media Server zu empfangen. Nein. Der Media Server ist ein Media Server, der Netzwerk-Streams an Clients wie den DVBViewer ausliefert und gegebenfalls selbst ein TS Stream-Gerät benutzt, um einen Netzwerk-Stream zu empfangen. Für einen Live-Stream mit HTTP-Adresse aus der Senderliste verwendet der DVBViewer (und auch Media Server) normalerweise ein TS Stream-Gerät. Falls die Geräteliste kein für den TS Stream-Empfang geeignetes Gerät enthält oder alle bereits besetzt sind, wird ein TS Stream-Gerät automatisch im Hintergrund erzeugt, ohne dass es in der Geräteliste erscheint, und arbeitet dann mit den Standard-Einstellungen. Das Verhalten kann man für den DVBViewer in Tweaker.exe mittels "TS Stream-Geräte bei Bedarf automatisch erzeugen" abschalten (für den Media Server mittels DMSTweaker.bat). Dann muss die Geräteliste ein geeignetes Gerät enthalten, sonst gibt es eine entsprechende Fehlermeldung. Will man die Standard-Einstellungen eines TS Stream-Gerätes verändern, muss man es auf jeden Fall in die Geräteliste einfügen. Sonst kommt man ja nicht an die Einstellungen heran. Zusammengefasst läuft es so ab, wenn der DVBViewer (und ebenso der Media Server) einen HTTP Stream empfangen soll: Er schaut in seiner Geräteliste von oben nach unten (!) nach, ob es dort ein geeignetes freies Gerät für TS Stream gibt (das kann ein TS Stream-Gerät oder im DVBViewer auch ein für TS Stream als Empfangsart konfiguriertes RTSP-Gerät sein). Falls ja, benutzt er dies mit Vorrang. Falls es in der Geräteliste kein geeignetes freies Gerät gibt, erzeugt er automatisch ein TS-Stream-Gerät im Hintergrund. Falls er das nicht darf, gibt es einen Fehler, weil kein (freies) Gerät für den Empfang verfügbar ist. Angenommen, der DVBViewer benutzt ein TS Stream-Gerät und ist als Client eines lokalen Media Servers (auf dem selben PC!) konfiguriert. Dann wandelt er die URL automatisch in eine HTTP-Request an den Media Server, um den Stream via Media Server zu empfangen, vorausgesetzt, der Tweak "TS Stream über den lokalen Media Server empfangen" ist eingeschaltet ist (standardmäßig der Fall). Dies soll verhindern, dass doppelte Internet-Bandbreite benötigt wird, wenn der Media Server den Stream aufnimmt und der DVBViewer ihn gleichzeitig wiedergibt. Manche IPTV-Provider erlauben es auch nicht, dass ein Stream doppelt von der selben Client-IP-Adresse bezogen wird. Die Folge ist, dass der Media Server den YouTube-Stream oder sonstwas über eines seiner (!) TS Stream-Device empfängt und daraus seinerseits einen Netzwerk-Stream erzeugt, den dann der DVBViewer über ein eigenes TS-Stream-Gerät empfängt. Dabei wandelt der Media Server gegebenefalls das Streaming-Format. Was bei ihm als Live Stream im HLS-Format ankommt (M3U8), erreicht den DVBViewer (oder auch andere Clients) als einfachen DVB-Transportstrom. Die Wandlung ist auf jeden Fall erforderlich, da sich HLS nicht aufnehmen lässt, weil es aus -zig kleinen Dateifragmenten besteht. Da läuft etwas ganz anderes ab. "URL öffnen" bewirkt, dass der DVBViewer nicht die Schiene für Live-Wiedergabe benutzt, sondern für Datei-Wiedergabe. Hier wird nicht an den Media Server delegiert. Der DVBViewer will den Stream zunächst mit eigenen Mitteln (nativ) selbst empfangen und verarbeiten. Die Geräteliste und automatisch erzeugte TS-Stream-Geräte bleiben dabei außen vor, die sind nur für die Live-Schiene! Dabei scheitert der DVBViewer jedoch am zu geringen Timeout. Da es nicht geklappt hat, versucht er nachfolgend als Fallback, ob der LAV Source Filter damit zurechtkommt. Und der schafft es dann bei dir. Bei mir sieht es in den Media Server-Optionen so aus: und in den DVBViewer-Optionen so Ich vermute, du hast einfach in den Media Server-Optionen kein passend konfiguriertes TS Stream Device, so dass eins automatisch mit den Standardeinstellungen (und damit zu kleinem Timeout) erzeugt wird, da sich der Media Server wie gesagt in der Hinsicht ebenso wie der DVBViewer verhält. Anhand einer support.zip hätte ich sowas sofort feststellen können

Und 16 € 💰. Für den Empfang brauchst du das HbbTV-Add-On. Siehe dazu auch im DVBViewer -> Hilfe -> Erweiterungen bestellen/freischalten. Wenn es dir nur um die Sender geht (und nicht die Mediatheken im DVBViewer), kannst du es jedoch auch umsonst haben: DVBViewer -> TV/Radio -> Empfangseinstellungen/Suchlauf -> Als Empfangsart TS Stream wählen -> Senderliste laden -> Internet TV (ger) oder Internet Radio (ger). Das füllt deine Senderliste mit einer Unmenge Sender, die frei über das Internet empfangbar sind. Die via HbbTV empfangbaren sind alle dabei, und viele mehr.

Sry für Doppelpost, aber ich versteh es nicht. Über URL öffnen gehts, wenn ich ein separates TS-Stream Device anlege. Warum da im Log wieder Connection Timeout 10000 steht, ist mir schleierhaft, da das TS-Stream Device ein Timeout von 30000ms hat. Aber der aktuelle Sky NEws Live Stream wird abgespielt. http://localhost:5077/x.m3u8?url=https://www.youtube.com/user/SkyNews/live?xx=1 Pflege ich die gleiche URL in die Senderliste ein, kommt kein Bild, obwohl die Stream-Parameter im Fenster zu sehen sind. Ich möchte ja die LIVE Streams übern Media-Server auf externen Playern abspielen.

Ich finde nur Info zum GE, sorry. Also so: habe per DVBT-2-Sendersuchlauf ein paar Sender gefunden, die nur per Internet (Hbb) empfangbar sind. Während im Browser die Media-Oberfläche der Sender angezeigt wird und ein Klick auf das Sender-Logo der Stream angezeigt wird, erscheint beim Internetvideo lediglich eine ARD-Hinweisseite... Schätze ich bin nur ein paar Klicks von der Lösung entfernt, aber leider ein Dummie :)) support.zip

Achso okay, war mit nicht klar, dass man auch den Timeout vom Media-Server im Viewer erhöhen muss. Habe beides jetzt auf 30s. Aber ich bekomme kein Stream ans Laufen. Live od. VOD. Nix geht. Entweder Invalid Socket oder nen LAV Fehler. Kannst du mir bitte mal ein Stream posten der bei dir läuft, so komplett mit localhost:5077 wie ich den in der Senderliste einpflegen würde. edit: Ist das überhaupt eine richtige Anmerkung von mir? Also ist der Media-Server im Viewer gleichzeitig ein TS-Stream Device? Wo an welcher Stelle TS-Stream Devices und Timeout eingestellt werden soll, finde ich bisher für mich nicht schlüssig erklärt.

Laut Log hat das TS Stream Device im DVBViewer nur ein Connection Timeout von 5000 ms. Es dauert aber länger, bis der Media Server antwortet, weil der wartet ja auch... du musst das sowohl in den Einstellungen des TS Stream Device in den Media Server-Optionen -> Hardware als auch in den Einstellungen des TS Stream Device in den DVBViewer-Optionen -> Hardware deutlich erhöhen. Ich habe hier bei beiden 15.000 ms.

Hmm also im hinterlegten TS-Stream Device im Media Server hab ich Timeout von 30000ms drin. Das sollte doch genug sein und die Streams liefen ja auch mal alle. Aber ich sehe im jetzt im Log auch Timeouts. Verstehe nicht, warum der nicht die 30sek. beachtet.

Danke für die Hilfe. ich melde mich wieder. Will vorher win11 neu installieren.

Hier funktionieren Live Streams nach wie vor. Bitte längliche Logs nicht als Text posten, sondern als Datei anhängen oder zumindest in Spoiler-Tags setzen (siehe Korrektur oben), damit man nicht endlos scrollen muss, wenn man hier mitlesen will. Den Live Stream delegiert der DVBViewer bei dir an den DVBViewer Media Server, wie du an der URL sehen kannst (siehe dazu auch "TS Stream über den lokalen Media Server empfangen" in Tweaker.exe). Und der scheitert dann und meldet den Statuscode 404 zurück. Womöglich, weil das Verbindungs-Timeout des von ihm verwendeten TS Stream Device zu kurz ist. Für MP4-Videos ist der LAV Source Filter zuständig, aber der scheitert hier. Warum, ist im Log nicht zu sehen. Ein Video als HLS (M3U8), was der DVBViewer nativ behandelt, endet letztendlich mit dem Statuscode 403 Forbidden vom Server. Ich vermute, der LAV Source Filter bekommt das gleiche. Vielleicht braucht yt-dlp mal ein Update...

Hallo Griga, braucht das Plugin ein Update? Kriege kein YT Live-Stream mehr rein. Die yt-dlp.exe und deno.exe sind aktuell. bzw ein "statisches Video"

Auf Anhieb kann ich nichts erkennen, was das Problem erklärt, habe aber einen Verdacht. Deine Suchvorgabe "quer" habe ich übernommen, werde beobachten, ob ich in nächster Zeit auch doppelte Timereinträge erhalte, und der Ursache nachgehen.

Hier die searches.xml und svctimers.xml zur weiteren Diagnose. searches.xml svctimers.xml

Für eine Analyse wäre eventuell deine searches.xml sowie deine svctimers.xml mit unerwünscht vervielfältigten Timern aufschlussreich (siehe DVBViewer-Konfigurationsordner\config). Da stehen sämtliche Daten drin. Wenn du nicht möchtest, dass sie öffentlich wird, kannst du sie mir auch als Anhang einer persönlichen Forumnachricht senden, anstatt sie hier anzuhängen. Das Thema "unerwünschte doppelte Timer" wurde sehr ausführlich hier diskutiert (falls du dich da durchkämpfen willst). Es führte letzendlich zu einer veränderten Methode der automatischen Timererzeugung in Version 3.3.1.0, die jedoch erst durch einen Tweak scharfgeschaltet werden muss, da sie sich noch in der Bewährungsphase befindet. Siehe dazu in den Versionshinweisen den Abschnitt Ich hoffe, das hilft weiter...