All Activity

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.

Hallo, doch die UDP Einstellung bietet er an Hier habe ich als Einstellung "automatisch gewählt" Meldung kommt trotzdem Grüße

...wobei mir gerade auffällt: Wenn der DVBViewer Octopus Net erkennt, bietet er die Protokoll-Einstellung gar nicht an, da er von vornherein weiß, dass TCP nicht unterstützt wird. An der Stelle befindet sich dann die Einstellung für CI. Ein eigener Versuch zeigt, dass diese vermutlich falsch als Protokoll-Einstellung TCP interpretiert wird, wenn dort was anderes als "Kein CI" steht. Das wäre dann ein Bug. Ich schaue es mir später noch mal genauer an.

Du hast unter Optionen -> Hardware in den Einstellungen für die RTSP Netwerkgeräte, die den DVBViewer mit Digital Devices Octopus Net verbinden, als Protokoll TCP eingestellt. Stelle es auf UDP zurück, dann hast du deine Ruhe...

Hallo, Beim Start des DVB Viewers bekomme ich für ein paar Sekunden folgenden Hinweis/Fehlermeldung angezeigt: Progamme laufen alle normal aber warum kommt dieser Hinweis? "TCP Datentransport vom Server nicht unterstützt" Hardware: Digital Devices Octopus Net mit CI wer kann helfen? Grüße

Die gibt es nicht. Das ist ein spezielles individuelles Problem in deinem System. Es gibt auch keinen magischen Button, auf den du nur klicken brauchst, und dann ist es weg. Du musst herausfinden, was die Ursache ist, indem du sie durch systematisches Probieren einkreist. Dazu habe ich bereits Hinweise gegeben. Dann variiere doch mal deine Versuche. Meine Güte, ist das so schwierig zu kapieren? Es mangelt immer noch an investigativem Ehrgeiz. Hilft es auch, wenn der DVBViewer keinen Sender abspielst, sondern gar nichts? Oder ein Video, z.B. eine Aufnahme? Oder eine MP3-Audiodatei? Oder ein anderes Programm, z.B. ein Browser, CPU-Last erzeugt? Ein Video abspielt? Schaue dir dabei im Taskmanager die CPU-Last an. Es hat bereits Fälle gegeben, in denen es bei sehr geringer CPU-Last Aussetzer gab, weil die CPU ständig in tiefe Schlafzustände wechselte und das System die Timinganforderungen von TV-Empfang bzw. Echtzeit-Betrieb nicht mehr erfüllte (was dann im BIOS geändert werden musste). Untersuchen würde ich auch, ob, wenn es im Client zu Aussetzern kommt, diese in einer gleichzeitigen Media Server-Aufnahme des selben Senders auch vorhanden sind. Aktiviere dazu in den Media Server Optionen (svcoptions.exe) -> Aufnahmen -> Log-Datei schreiben, damit du später dort nachschauen kannst. Im Aufnahme-Log, das den gleichen Pfad und Namen wie die Aufnahme hat, steht sowas drin.

Erst mal Danke für die Antwort. Ich habe schon viele Seiten durchforstet, aber noch keine Lösung die mir hilft! Eine Rücksetzen ist grundsätzlich möglich, da ich mit Acronis halbjährlich Systembackups ziehe. In dem Server findet sich eine DD Octupus mit 6 Tunern (3x2) und einem CI. Diese werden ordnungsgemäß im Gerätemanager angezeigt. Der TV Server ist so eingestellt, dass er durch Kodi über die Android TV boxen aufgeweckt werden kann und sich sonst schlafen legt, wenn nichts geschaut wird oder keine Aufnahmen laufen. Er steht im Serverschrank, hat keinen Monitor angeschlossen und wird per Remotedesktop gewartet. Die Einrichtung des DVB Viewers habe ich heute so vorgenommen, wie mich der DVBViewer incl. des Servers führt. Der DVBViewer Pro greift wohl auf die RTSP zu. Im DVBViewer Pro sehen die Servereinstellungen so aus: Die Frage mag für Euch dumm sein, aber ist es eventuell erheblich das die IP des Mediaservers 192.168.158.150 ist? Muss ich das ggf. anpassen? Wenn ich auf den Clients ARD HD oder ZDF HD schaue, funktioniert auf den Clients alles tadellos. Schaue ich private in SD, kommen nach etwa 3 Minuten zunächst Aussetzer, dann friert der Stream ein. Aktivere ich auf dem Server den DVBViewer und lasse dort nur einen privaten Sender laufen, funktionieren auch die privaten Sender in SD auf den TV Boxen tadellos. Wenn nun auf dem Server im DVBViewer Pro Sat 1 SD geschaut wird und auf einem Client gleichzeitig RTL geschaut wird, sieht der Status des Mediaservers wie folgt aus: Wenn es irgendwo eine Anleitung gibt, was ich ändern soll, würde mir das ja schon helfen!

Eine Systemwiederherstellung auf einen Zeitpunkt vor dem Auftreten des Problems oder zumindest eine Deinstallation des letzten Windows Updates wäre sinnvoller gewesen. Die Chance ist jetzt wohl vorbei. Normale Log-Einträge, wenn der PC in "Energie sparen" (Standby) oder den Ruhemodus wechselt bzw. daraus wieder aufwacht, und der Media Server entsprechende Botschaften von Windows erhält. War im Forum schon öfters Thema.. @HaraldL: Läuft dein Server 24/7? Abwegig. Temporäre Fehler, die der Custom EVR meldet, wenn mit D3D irgendwas nicht klappt. Meistens unerheblich. Kann z.B. auftreten, wenn Windows bei laufendem DVBViewer den UAC-Screen anzeigt, weil es dann dafür sorgt, dass niemand auf dem Bildschirm dazwischenfunken kann, und D3D unterbindet. Hat mit dem hier angesprochenen Problem nichts zu tun. Hier fällt auf, dass beide nicht für die Zusammenarbeit mit dem Media Server konfiguriert sind, d.h. direkt auf die DD Tuner zugreifen, anstatt Streams über virtuelle RTSP Netzwerkgeräte vom Media Server zu beziehen und diesem damit die Tunerverwaltung zu überlassen, wie es eigentlich sein sollte. Es heißt auch, dass sie zusätzliche Tuner belegen, selbst wenn sie den selben Sender wie der Media Server bzw. einen von der selben Frequenz empfangen. Wenn sie nicht öfters in Verwendung sind, spielt das jedoch keine Rolle. Insgesamt mangelt es hier an investigativem Ehrgeiz und präzisen Angaben. Was heißt "laufen lassen"? Was machen der DVBViewer und TransEdit, wenn du sie "laufen lässt"? Einen Sender / eine Frequenz empfangen? Die selbe wie gerade der Media Server bzw. sein Client? Gilt das auch, wenn der DVBViewer z.B. eine Datei wiedergibt? Nur Audio wiedergibt? Nichts wiedergibt? Hilft es auch, andere Software laufen zu lassen, die eine gewisse CPU-Last erzeugt? Z.B. ein Browser? Wenn dieser ein Video abspielt? Ohne die Bedingungen einzukreisen, unter denen das Problem auftritt bzw. nicht auftritt, wird es hier wohl nicht weitergehen...

Danke! Aus Verzweifelung habe ich die Kiste heute neu aufgesetzt. Genau der gleiche Effekt. Ich bin verzweifelt.

Off Topic (pune not intended): Da steht bei mir sogar noch eine DVBViewer_Pro_setup_5.6.2.exe aus 2016 drin. Da sieht man mal, wie alt meine Windows Installation ist. Damals lief noch Windows 7 auf der Kiste, die mittlerweile einige Hardware- und Software-Updates erlebt hat – ohne komplette Neu-Installation (nur Inplace-Upgrades). Jetzt läuft – mehr oder weniger – zufriedenstellend Windows 11 drauf.

Useful for games, but unnecessary for DVBViewer.

https://uploadkb.com/do.php?img=48 This is the required program.. The frames appear in the corner of the viewer screen. Thanks for your cooperation.

@الهاوي : I will not open sceenshots anymore uploaded by you to dubious sites like r2.image-upload.app/, that are known to be used for malware distribution, or may be used for it. If you want me to see your screenshots, attach them here in the forum, like everybody else does. If you cannot do it, because there is not enough memory space for attachments left, delete old attachments that are not relevant anymore by following this link.

DVBViewer displays the nominal frames per second (FPS) of the received video stream in its status bar and on the DVBViewer Filter Property Page (see Settings -> Filters -> DVBSource). However, the actually displayed frame rate may differ, for example, because there are video decoders that are able to perform frame doubling. Or the frame rate is reduced by playback timing problems, that let the video renderer drop frames. The actually displays frame rate can usually be viewed on the video renderer property page (see Settings -> Filters -> click the Video Renderer menu item). So you don't need extra tools for displaying the frame rate.

I think the FPS monitoring program fpsmon-5520.exe https://uploadkb.com/do.php?img=47

Check out this link https://uploadkb.com/do.php?img=47 The first link, the image got blurry or its display time ran out