All Activity

Habe jetzt die svcdebug.log aus der support.zip entfernt und separat gezippt. So müsste es gehen. svcdebug.zip support.zip

This is how the filtergraph looks like for an MKV file: Obviously the XySubFilter has no output pin that is connected to something, which means, it is using an MPC Video Renderer interface for passing subtitles to it, not a usual DirectShow output pin -> input pin connection. As far as it concerns MPC VR, this requires copy-back, as @Yaron Gur stated, presumably performed in MPC VR. Copy-back means, hardware-decoded pictures do not remain in the graphics card memory until they are displayed, but are passed back to a video decoder or renderer, so they can be changed before they are displayed, e.g. for overlaying subtitles. This forth and back and forth causes quite some traffic between system memory and the graphics card, though. Copy-back also has advantages. It enables hardware decoding with video renderers that otherwise are not able to handle DXVA2, even with the ancient Overlay Mixer. If it is performed by the video decoder, subtitles can be added in the usual way by subtitle filters without losing hardware decoding. That's why the LAV video decoder offers copy-back as option (as alternative to native DXVA2). For unknown reasons it additionally enables hardware-decoding of some H.264 internet streams here, that can't be decoded with native DXVA2, that yields nothing but a black screen in this case. That's why I'm using copy-back as standard setting. The CPU load is a bit higher, but I didn't encounter serious drawbacks up to now. Now, @Yaron Gur claims that it is also possible to add subtitles to video without copy-back, but directly in the graphics card memory, and that the XySubFilter is able to handle it, provided the video render exposes an interface for it. But MPC VR doesn't (only for the copy-back method). This constraint can be circumvented by using an additional "Subtitle Helper" bridge filter that contains code used by MPC BE for the same purpose. It was just meant as hint for us. That's how I understand it now after having looked deeper into this matter...

Hallo, habe seit heute Abend das Problem, dass ich keine Sender mehr empfange. Ich erhalte die Meldung "Sender nicht verfügubar vom Server". Wenn ich umschalte kommt auch kein Empfang und nach weiterem Umschalten werde ich plötzlich wieder zurückgeschaltet auf das Einstiegsprogramm mit dem Hinweis "Senderumschaltung durch Media Server" oder so ähnlich. Ich habe keine Einstellungen geändert. Kann mir nicht erklären was jetzt passiert sein kann. Die support.zip lege ich bei und danke schon jetzt für jede Hilfe. Liebe Grüße Jörg PS die support.zip hat 369 KB und lässt sich nicht anhägen. Was kann ich tun?

Siehe den Link in dem von dir zitierten Text. Unterstrichene Textteile im Internet sind meistens Links, auf die man klicken kann, um zu weiterführenden Informationen zu gelangen.

Am besten, du erzeugst auf dem Windows 11 Laptop eine support.zip und hängst sie hier als Datei an. Deiner leider recht kümmerlichen Problembeschreibung lässt sich kein Hinweis auf die Ursache entnehmen.

Auf dem neuen Win11-Laptop ist alles genauso installiert wie auf dem Win10-Laptop aber die Sender öffnen sich nicht und die Programme der Sender werden nicht angezeigt.

Hi Griga! Wie kann man diese neue Funktion nutzemn. Gibts da eine Anleitung. Im Senderlisteneditor finde ich dazu nichts. Vielen Dank, m2000

Thank you Griga, now it works with the updated test version. 🙂 Yes, this was only an issue with the MPC video renderer. With other renderers like EVR custom or madVR it did not happen. So I confirm that the video gets displayed now also with MPC after playback start of a video file.

Confirmed. It requires some video resizing (aspect ratio / window size change etc.) to make the video visible, because this entails a IBasicVideo.SetDestinationPosition call. MPC VR doesn't work without it. The issue does not depend on the presence of the xySubFilter. Most likely it was caused by optimisations to avoid unnecessary resize calls in 7.3.1.9 (can't repoduce it in previous releases like 7.3.1.0). Hard to detect, because it only happens under special circumstances, particularly when playing a video after a video with the same aspect ratio has been played before with aspect ratio setting = Auto, because in this case no resize call was triggered after building the filter graph. However the issue does not occur on first playback after DVBViewer start, not on TV, not after Rebuild Playback, not if the DVBViewer Filter (DVBSource) is used etc. I have re-uploaded a fixed version to the PM. Please download again and try...

Oh, das hatte ich zwar mal angehakt, in der Hoffnung daß es das tut was ich suche, aber dann wieder abgehakt. Jetzt habe ich es mir noch mal genauer angeschaut um festzustellen was es tut. Das beharkt sich dann in der Tat, zumindest an den entsprechenden Stellen. Schade 😢

Thank you 🙂 I can confirm that subtitles are now also displayed with xySubFilter combined with MPC video renderer. The only problem is that when I start a movie from the harddisk or Blu-Ray and the MPC video renderer is used, then playback of the movie starts and I can hear the sound but the screen remains black. If I rebuild the filter graph or open an OSD page where the small video window is present, then the video also gets displayed. This has nothing to do with this special test build, it starts from beta version 7.3.0.1 on. With version 7.2.4.2 that I was using for a long time, it still works correct. I attached log files for versions 7.2.4.2 / 7.3.0.1 / 7.3.1.10 The only thing that the older version 7.2.4.2 is doing on playback start and what is missing in the two newer log files is this (last five lines of the files): 29.10.25 00:36:38.596 TVideoRenderer SetTargetHandle 000803EC This is missing only for file playback, for DVB (some lines above) all three versions are calling this. DVBViewer_logs.zip

See PM.

If possible, yes please 🙂

Done. Do you want / need a test version?

This would be great 🙂

Yes. Shall this tweak also apply to MPC-VR in future?

In GraphStudioNext it works without any additional filter. Maybe, DVBViewer loads the xySubFilter only (tweak enabled), if it detects the presence of madVR (?)

Und was mache ich dann mit den maussensitiven Klickbereichen im Videofenster (Optionen -> OSD Maus)?

Ja, da ich den 64-bittigen auch den ab und an mal für 4K-Zwecke benutze, ist mir das auch schon angenehm aufgefallen. Bin ja TV-mäßig immer noch mit dem PC unterwegs, da muß man ab und an mal alternative Player benutzen wenn was ruckelt oder überhaupt nicht laufen will. DVBViewer ist aber immer noch meine Hauptanwendung für lineares Fernsehen oder auch zum Abspielen. Bei den Streamern ist es praktisch überall so mit der Pausierung der Wiedergabe, auch bei den ÖR. Da gewöhnt man sich schnell an sowas. Ist was für faule, man muß so halt nicht auf den Knopf zielen 😁

Hallo, @duddsig: Der MPC-HC hat die von Dir beim VLC nachgerüstete Funktionalität seriemäßig implementiert. Wenn man mit der linken Maustaste in das laufende Video klickt wird es entweder pausiert oder läuft weiter. Ich war ganz verwundert, daß es beim VLC nicht genauso läuft. Viele Grüße Webturtle

Das hat mit Sat>IP / RTSP rein gar nichts zu tun. Das wirkt auf die Multicast-Erkennungmechanismen. Gerade selbst probiert. Wenn ich dort die 192.168.xxx.xxx Adresse des Adapters auf dem Server-PC eintrage, findet ein Remote-DVBViewer den Server unter Optionen -> Hardware -> Einstellungen für ein assoziiertes RTSP-Netzwerkgerät nicht mehr. Sat>IP funktioniert trotzdem, weil das ja nur die Erkennung via UPnP betrifft, nicht die Anforderung und den Empfang von DVB/TV-Daten. Um den gleichen Effekt bei einem lokalen DVBViewer zu erreichen, muss ich jedoch 127.0.0.1 und 192.168.xxx.xxx eintragen. Der DVBViewer erkennt lokale Adressen und biegt sie grundsätzlich auf 127.0.0.1 um, auch wenn das Multicast NOTIFY über 192.168.xxx.xxx eintrifft.

Update #2: Nachdem die Panasonic SAT>IP Clients nicht davon zu überzeugen waren die primäre IP-Adresse über RTSP zu erkennen, habe ich mich kurzum entschieden das Thema von der anderen Seite anzugehen und die Kommunikation pimär über die MediaServer IP-Adresse zu konfigurieren - somit ergab sich folgende Konfiguration mit der jetzt alle Geräte zufrieden sind: Konfiguration Media Server: Web/UPnP -> Webserver -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;172.31.255.5;172.31.255.50 Web/UPnP -> UPnP AV Server aktivieren -> JA Web/UPnP -> UPnP AV Server aktivieren -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;172.31.255.5;172.31.255.50 RTSP / SAT>IP Server aktivieren -> JA Konfiguration Firewall: Block | Port TCP 554 | Scope - Local IP address - 172.31.255.5 + 172.31.255.50 Allow | Port TCP 554 | Scope - Local IP address - 172.31.255.51 Bis jetzt hat diese Konfiguration multiple Reboots und Suchläufen auf den SAT>IP Clients überlebt. Jedoch ist mir nach wie vor nicht klar, wie ich den Multicast Traffic soweit einschränken könnte, das er nicht eher "zufällige" Interfaces aushandelt (wobei der Zufall derzeit eher auf die "höchste" IP schließen lässt). Grüße,

Kurzes Update, ich konnte eine Teil-Lösung für das Problem des "IP"-hüpfens finden - ist nun zwar nicht die feine Englische Art - aber mit ner lokalen Windows Firewall Regel und der passenden Konfiguration im Media Server funktioniert es nun: Interface: LAN IP-Adresse: 172.31.255.5, 172.31.255.50 (SkipAsSource=true), 172.31.255.51 (SkipAsSource=true) Lokaler WebService (Windows Admin Service) erreichbar unter: https://mediarechner.local (https://172.31.255.5:443) Custom WebService erreichbar unter: https://mediamonitor.local (https://172.31.255.50:443) Media Server WebService erreichbar unter: https://mediaserver.local (https://172.31.255.51:443) Konfiguration Media Server: Web/UPnP -> Webserver -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1;172.31.255.5;172.31.255.50 Web/UPnP -> UPnP AV Server aktivieren -> JA Web/UPnP -> UPnP AV Server aktivieren -> Netzwerk-Adapter IP(s) NICHT nutzen: 127.0.0.1 RTSP / SAT>IP Server aktivieren -> JA Konfiguration Firewall: Block | Port TCP 554 | Scope - Local IP address - 172.31.255.50 + 172.31.255.51 Mit dieser Konfiguration melden (fast) alle SAT>IP Clients bei der Suche die primäre IP Adresse (172.31.255.5) und es gibt auch kein hüpfen mehr zwischen den IP Adressen beim Ergebnis. Zusätzlich funktioniert alles wie gewohnt - mit dem Luxus mehrere WebService unter Port 443 auf einem System zu betreiben. Einzig allein die Panasonic SAT>IP Clients bleiben dabei, das 172.31.255.51 (anstelle von 172.31.255.5) der SAT>IP Server ist ... Grüße,

Das ist schade 😒 Ist das eventuell nachrüstbar? Unter Eingaben/Maus/Einstellungen/Vollbildwechsel würde sich ein 2. Kästchen mit jener Funktion meiner ungebremsten Beliebtheit erfreuen 🫣 Beim VLC ist es standardmäßig auch nicht vorhanden, da habe ich auch erst ein zusätzliches Plugin einbauen müssen.

Nein.