All Activity

Ich hab mal den DSL-Stecker an der Fritzbox gezogen. Es gab ein paar Anfangsschwierigkeiten. Ein Remote DVBViewer konnte zunächst den Media Server via UPnP nicht finden, aber nach etwas Hin und Her ging alles, und er hatte auch ohne Internet Vollzugriff auf den Server. Werde den Versuch bei Gelegenheit noch mal wiederholen. Jedenfalls scheint die Funktionsfähigkeit nicht zwingend von einem DNS Server im Internet abzuhängen. Vielleicht ein bisschen viel... den Rooter darfst du dem Netzwerk natürlich nicht entziehen (falls du das damit gemacht hast).

Der verlinkte Thread ist der richtige, das Tool von @Griga welches das neue Verhalten von Windows (NICHT vom DVBViewer) umgeht ist aber etwas weiter oben: https://www.dvbviewer.tv/forum/topic/83196-searching-directshow-components-it-takes-some-10-seconds/#findComment-539275

Denke ich auch. Danke für den Test. Ich werde überprüfen, woran das liegt. Bei tvheadend scheitert es an einer DNS-Anfrage bei Google (IP-Adresse 8.8.8.8).

Hab mal schnell einen Test gemacht und das Gateway am Media server Netzwerk geändert. Wollte jetzt nicht die FB ausschalten. Damit ging kein Stream mehr mehr zwischen Media Server und Remote DVBViewer. Erst als der Gateway wieder gepasst hat, lief es sofort los. Ansich sollte doch einfach der Stream von der IP geholt werden, da ist der Gateway an sich irrelevant - denk ich.

Hallo, könnte es dieser Fehler sein. Kommt aber eigentlich von einem Win-Update. Searching DirectShow Components - it takes some 10 seconds - General DVBViewer Pro/GE - DVBViewer community forum

Hallo, am besten beobachtest Du mal den Splash-Screen bei Starten, um festzustellen beim Start welcher Komponente es besonders lange dauert. Außerdem könnte ein Start im Debug-Modus und ein Posten der Support.zip hilfreich sein. Vgl. Support.zip Viele Grüße Webturtle

Habe heute ein Update aufgespielt das akutelle , seitdem lädt er beim starten sehr lange woran kann dies liegen? ging vorher ohne verzögerung ...... was wurde im update geändert?

BTW: Mitunter lässt sich ja aus dem größten Blödsinn etwas lernen. Hat schon mal jemand probiert, ob der DVBViewer Media Server ohne Internet-Verbindung ohne weiteres im lokalen Netz als Sat>IP-Server nutzbar ist?

Danke für deine Bemühungen um Klärung, aber warum und wie soll der DVBViewer ein spezielles von tvheadend auf einem Linux PC genutztes Verzeichnis unterstützen? Oder einen Protokoll-Notnagel aus der Vor-Sat>IP-Zeit? Der DVBViewer ist ohne weiteres in der Lage, tvheadend als Sat>IP Server zu nutzen, siehe z.B. hier, inzwischen auch im TCP Interleaved Transportmodus. Mehr braucht es IMO nicht. Das ganze ist ein schlechter Scherz. P.S. Dazu findet sich https://tvheadend.org/d/8734-satip-server-only-working-when-internet-is-connected mitsamt Lösung. Aber das ist ein Problem, das in tvheadend gelöst werden muss, keinesfalls im DVBViewer durch eine zusätzliche aufwändige Protokollimplementierung.

Die KI erläutert zu hts im Kontext mit TVheadend folgendes: Vielleicht findet ihr ja doch noch zusammen eine Arbeitsebene?

Irgendwas davon muss er gemeint haben... https://de.wikipedia.org/wiki/HTS

You are a self-supporting user. Very good! I like that This information is out-dated.

Unabhängig von irgendwelchen Log-Einträgen ist die Idee, Windows könne Anwendungen absichtlich bremsen, um die Voraussetzungen für Energiesparmaßnahmen zu schaffen, etwas schräg Sowas ist höchstens bei PCs mit "Modern Standby" bzw. AOAC denkbar (siehe hier), aber das sind dann i.a. Laptops. Der Normalfall ist, dass Windows oder sonstwer Komponenten zeitweise in Schlafzustände schickt, wenn die Last unter einen gewissen Schwellwert sinkt oder Pausen ab einer gewissen Länge auftreten. In dem hier behandelten Fall besteht offenbar ein Zusammenhang mit der Datenrate: Die Datenrate der ÖR HD Sender via Satellit ist ca. 5 mal höher als die eines privaten SD Senders. Das hat natürlich Folgen für die CPU-Last (wenn auch nur relativ geringe), aber auch die Last anderer Komponenten, insbesondere des Netztwerkadapters. Dass das Problem so plötzlich auftrat, könnte z.B. daran liegen, dass Windows Update einen neuen Treiber für was auch immer ins System gespült hat, der weitergehende Energiesparmaßnahmen ermöglicht, mit unerfreulichen Nebenwirkungen für den Echtzeit-Betrieb. Zeitlich würde es passen. Am 23.06. hat Walther geschrieben "Seit ein paar Tagen...". Das Windows Juni-Update ist am 09.06 erschienen und wurde dann wahrscheinlich wenige Tage später installiert. Ein sinnvoller Diagnose-Schritt wäre deshalb gewesen, es wieder zu deinstallieren bzw. den Systemzustand zu einem Zeitpunkt vor dem Auftauchen des Problems wiederherzustellen, anstatt DVBViewer/DMS-Logs zu posten, die in solchen Fällen i.a. null Aussagekraft haben. Ob irgendeine Komponente temporär in Schlafzustände wechselt, loggen DVBViewer und DMS nicht (nur wenn der gesamte PC einschläft), und Aussetzer nur bei Aufnahmen. Leider haben unerfahrene Anwender eine fatale Neigung, in ihrer Verzweiflung das Falsche zu tun...

😄 Genau deswegen hatte ich nicht ohne Grund oben ausdrücklich geschrieben: 😉

...Yes, it is totally possible to control the colors and lighting while running channels in DVBViewer. You can make these adjustments by following these steps: While watching a channel in the main window, right-click on the video image or go to the settings menu. Look for the Properties option or the control icon. A slider will appear allowing you to adjust: Brightness Contrast Saturation Hue Important note: This feature only works if your Video Renderer is set to Overlay Mixer or VMR 9. If you are using other display settings (like Custom), you may need to adjust your graphics card colors or use the decoder settings. Thanks. The problem has been solved.

Here are the results of more extensive investigations: Generally the Media Server and DVBViewer do not support timers with a duration of more than 23:59 hours, obviously resulting from the way they are input in the timer dialog and displayed: start date, start time as hh:mm, end time as hh:mm. Of course both know that in case of a start time greater than the end time, the recording is supposed to stop on the next day. So for a timer with a duration of 23:59 hours something like start time = 12:00, end time = 11:59 has to be entered. The attempt to create a timer for a 24:00 hours recording by entering start time = 12:00, end time = 12:00 yields a timer with a duration of 00:00, which is not executed. However, there are always clever users like you who try to circumvent such limitations, in this very case by using the Follow-Up Time input field for achieving a longer recording duration, thus pushing the Media Server beyond its specifications, so to speak, because this is not explicitely handled in the code. So It may or may not work. In your case, it accidentally works in 3.3.1, but not in 3.3.2 due to slight changes. The "bug" in the Media Server is, that it nonetheless allows such tricks, instead of disabling the Lead / Follow-Up time input fields and forcing a correct and safe solution like using two timers, one with start time 00:00, end time = 12:00, and another one with start time = 12:00, end time = 00:00. The lead / follow-up times are intended for timers created from EPG entries, but not for manually entered timers and not at all for manually entered recurring timers, because with a duration of 23:59 plus a lead / follow-up time they may overlap themselves. This even happens with one extra minute. BTW: A (recurring) timer from 12:10 to 12:09 plus 1 minute follow-up time (see here) neither works in 3.3.1 nor in 3.3.2, because both Media Server versions calculate a duration of 0 minutes due to start time = end time. They don't recognize anymore that the recording is supposed to stop on the next day. Start time = 00:00, end time = 23:59 plus 1 minute follow-up time yields a duration of 24 hours, though, due to the start time being less than the end time and no wrap-around to 00:00 being applied to the end time when the follow-up time is added. The problem in 3.3.2 is rather the calculation of the next recording date. When a recurring 24 hours recording e.g. starting on Monday 00:00 is ending, the Tuesday recording is already overdue, so the Media Server 3.3.2 schedules the next one for Wednesday. So how can this be handled in future? There are two possibilities: Design a more restrictive UI, that does not allow users anymore to enter timers for recordings with a duration of more than 23:59 hours. Continue to allow such input and try to handle it in the code as far as possible. However, the second solution may still yield results that are not intended by the user, either because there is an unforeseen collision with other handling in the Media Server, or because it is simply impossible to put it into effect, like recurring 48 hours recordings on each day with a single timer

Was ist hts? Das hätte ich ebenfalls gerne genauer erklärt. Ich kann mich nicht erinnern, dass dies bei meinen Experimenten mit tvheadend sowohl als Sat>IP Server als auch als Client irgendeine Rolle spielte. Würde ich mir auch. Nämlich dass du, anstatt hier in drei Zeilen nebulöse Abkürzungen und Andeutungen hinzurotzen, verständlich und nachvollziehbar rüberbringst, was du meinst, mit Erläuterungen, Beispielen, Links usw. Ich sehe nicht ein, dass ich mir Arbeit und Mühe machen soll, deine Wünsche zu erfüllen, wenn du offensichtlich nicht dazu bereit bist, etwas zu investieren.

Ich mein hts is ja open source und es sollte ziemlich einfach sein das in dvbv zu integrieren. Also ich würds mir extrem wünschen das hts 1:1 inkl. dem tvh timeshifting, etc in DVBViewer funktioniert. Sat/IP geht leider in einem tvheadend ohne aktive Internetverbindung nicht

Meldung ist weg. Danke

Da hast du etwas supergründlich missverstanden. Die DVBViewer.exe in der DVBViewer_Test_7_3_2_1.zip ist weder ein Installer noch eine Setup-Datei. Die Anweisung in der PM lautet "In einer DVBViewer 7.3.2-Installation DVBViewer.exe austauschen." Ist dir der Begriff "austauschen" unbekannt? Du bist wirklich der Erste, der das nicht versteht. Es bedeutet, dass du die DVBViewer.exe extrahieren und in dein vorhandenes DVBViewer 7.3.2-Programmverzeichnis kopieren sollst, wo sie die bereits vorhandene 7.3.2.0 DVBViewer.exe ersetzt. Das ist alles. Was du erlebt hast, ist das, was passiert, wenn man eine DVBViewer.exe ohne ihre ganze Umgebung, die ein Installer einrichtet, startet.

Lässt sich nicht installieren. Habe Windows 11. Nach dem extrahieren habe ich eine Setup datei. Wenn ich diese ausführe startet die Installation allerdings nur in English und installiert in ein Testverzeichnis. Wenn ich den DVBViewer starte sind die Felder für Sendersuche alle ausgegraut. Schade.

Sorry ist schon gekommen habs übersehen. Werde ich gleich ausprobieren. Vielen Dank.

Hallo, PM ist leider nicht gekommen.

Is it possible to control the colors and lighting in the Viewer program?

Nein. Das ist das Problem: An der Stelle hast du CI #1 eingestellt, und das fehlinterpretiert der DVBViewer als TCP. Mit "Kein CI" wäre der Spuk vorbei. Du hast eine persönliche Forumnachricht (PM) mit einer Testversion im Anhang, in der das Problem (hoffentlich) gefixt ist.