JunePaik Posted February 5 Posted February 5 (edited) Hallo, mir ist es jetzt schon häufiger aufgefallen, dass, in meinem Fall, ein interner Task-Timer (autom. Timer erzeugen) den Energiesparmodus verhindert. Das passiert allerdings nicht immer. Manchmal steht der Timer schon Tage vorher in den /requests. Auf der Kiste läuft faktisch nur der DVBViewer (Media-Server) in der jeweils aktuellen Version und die müsste eigentlich jede Nacht in den Standby gehen. Anbei mal ein paar Screenshots zur Verdeutlichung, gelb eingekreist im Windows Ereignis-Log die Zeiten ohne Energiesparmodus: Jemand 'ne Idee? Edited February 8 by Griga Titel geändert Quote
Griga Posted February 5 Posted February 5 vor 1 Stunde schrieb JunePaik: Manchmal steht der Timer schon Tage vorher in den /requests. Da steht der Media Server, nicht der Timer. Woraus schließt du, dass der Timer die Ursache ist? Es gibt verschiedene Gründe, aus denen der Media Server den Energiesparmodus blockiert. Laufende oder kurz bevorstehende Aufnahmen, Zugriffe auf das Webinterface von anderen PCs/Geräten (siehe dazu auch Media Server-Optionen -> Web/UPnP), Clients, die mit einem Stream versorgt werden... Wenn du genaueres wissen willst, musst du im svcdebug.log (siehe DVBViewer-Konfigurationsordner) nach bestimmten Einträgen suchen: AddReference besagt, dass eine Instanz innerhalb des Media Servers den Energiesparmodus verhindern möchte. Dies erhöht einen internen Zähler um 1. Wenn er sich von 0 auf 1 ändert, folgt ein SetStandbyBlock Eintrag. Damit wird Windows mitgeteilt, dass der Media Server ein laufendes System braucht. ReleaseReference besagt, dass eine Instanz, die eine Verhinderung des Energiesparmodus beantragt hatte, dies nicht mehr benötigt. Es vermindert den internen Zähler um 1. Wenn er auf 0 sinkt, folgt ein ReleaseStandbyBlock-Eintrag. Damit teilt der Media Server Windows mit, dass kein laufendes System mehr nötig ist. Der jeweilige Zählerstand und die Instanz sind den Log-Einträgen zu entnehmen. "WebMain" bezieht sich auf das Webinterface, "TVCR" auf den Recorder oder allgemeiner die Timer-Ausführung. Weiterhin gibt's da noch "TStreamClient", "UPnP Webserver", "MediaStreamServer", "RTSP Client" usw. Eine böse Falle ist in Windows leider der Abwesenheitsmodus (Away Mode). Wenn der Anwender (nur der!) einen PC manuell in den Energiesparmodus versetzen will, dieser aber zur Zeit verhindert ist, geht der PC in den Abwesenheitsmodus, sofern in den erweiterten Energieoptionen zugelassen. Display, Grafikkarte, Soundchip und vielleicht noch einiges mehr werden schlafen geschickt, so dass es so aussieht, als ob der PC eingeschlafen wäre (wegen der "User Experience", hat MS argumentiert). Aber das System läuft weiter. Das blödsinnige an der Sache: Im Abwesenheitsmodus kann eine Anwendung oder ein Service keinen "echten" Energiesparmodus mehr auslösen. Wenn im DMS z.B. eine Aufnahme mit "Energie sparen" als abschließender Aktion endet, passiert einfach nichts. Windows meint, es wäre ja schon eine Art Energiesparmodus aktiv, und hält es nicht für nötig, in der Hinsicht weiteres zu unternehmen. Das einzige, was diesen Spuk beendet, ist eine Aktion des Anwenders (z.B. ein Tastendruck), mit der er seine Anwesenheit kundtut. Dann wacht der PC aus dem Abwesenheitsmodus auf, und der "echte" Energiesparmodus wird wieder möglich. Wer damit nichts zu tun haben will, kann den Abwesenheitsmodus in den erweiterten Windows-Energieoptionen deaktivieren. 1 Quote
JunePaik Posted February 5 Author Posted February 5 (edited) vor 2 Stunden schrieb Griga: Da steht der Media Server, nicht der Timer. Woraus schließt du, dass der Timer die Ursache ist? Es gibt verschiedene Gründe, aus denen der Media Server den Energiesparmodus blockiert. Laufende oder kurz bevorstehende Aufnahmen, Zugriffe auf das Webinterface von anderen PCs/Geräten (siehe dazu auch Media Server-Optionen -> Web/UPnP), Clients, die mit einem Stream versorgt werden... Weil ich mir keinen anderen/ext. Zugriff erklären kann. 5 devices greifen auf den Mediaserver zu und genau jetzt hat keines eine Verbindung: Im Heimnetz eine Dreambox (runtergefahren) und ein Apple-TV (Standby) greifen direkt die TS-Streams ab, 'ne ältere Panasonic-Glotze (im Standby) über deren DLNA-Client, Tablet per DVBViewerController (App forced closed) sowie von außerhalb ausschließlich über Wireguard (nicht aufgebaut) ein Smartphone ebenfalls per DVBViewerController. Da aktuell keine Aufnahme ansteht/läuft, der Media-Server immer noch in den /requests drin steht, muss ich mich mal in den Logs einlesen, was da passiert. Wenn es nicht der Timer ist, könnte es eines der devices sein, dass sich nicht "sauber" abmeldet und der Media-Server somit kein ReleaseStandbyBlock abfeuert? Diesen away-mode hab ich mal deaktiviert und beobachte das auch. Obwohl ich diese Windows 10 Kiste sonst gar nix manuell in irgendwas versetze und nur per Remoteverbindung drauf bin. edit: mal den svcdebug.log überflogen, vom 01.02. bis 04.02. alles ok, wie man auch oben im Windows-Log sieht, Kiste geht nachts in Standby, wird am 04.02. um ca. 17:20 aus dem Standby geholt (Dreambox fährt hoch, schickt WOL raus), ich sehe AddReference (1)/ ReleaseReference (0), dann steigt da aber irgendwas aus und der interne Zähler kommt nicht mehr auf null. Hab dir den Part mal in die Anlage geschoben. Im Webinterface unter Status->Clients steht nix. Interner Zähler trotzdem auf 1. log.txt Edited February 5 by JunePaik Quote
Griga Posted February 6 Posted February 6 In deinem Heimnetz scheint es mindestens ein hyperaktives UPnP-fähiges Gerät bzw. einen Client zu geben, der den Media Server beschäftigt hält: 05.02.25 23:41:25.381 TServiceMain AddReference upnp webserver: 2 05.02.25 23:41:55.651 TServiceMain ReleaseReference upnp webserver: 1 und so weiter. In den Media Server-Optionen (SvcOptions.exe) -> Web/UPnP kannst du wie bereits gesagt verhindern, dass dies den PC wach hält (UPnP AV Server aktivieren -> PC-Energiesparmodus durch Anwender/andere Programme... verhindern -> ausschalten). Oder den ganzen UPnP-Server abschalten, falls du ihn nicht brauchst. Es scheint aber auch am 04.02.25 20:12:41 eine Unregelmäßigkeit in Form einer Zugriffsverletzung in der vom DMS verwendeten Netzwerkbibliothek gegeben zu haben. Wenn man sich die Referenzzählung drumherum anschaut Spoiler 04.02.25 20:11:23.656 TServiceMain AddReference TStreamClient: 1 04.02.25 20:12:08.145 TServiceMain AddReference upnp webserver: 2 04.02.25 20:12:26.732 TServiceMain AddReference WebMain: 3 04.02.25 20:12:38.422 TServiceMain ReleaseReference upnp webserver: 2 04.02.25 20:12:41.187 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00554688 in Modul 'DVBVservice.exe'. Lesen von Adresse 025805A1 04.02.25 20:12:41.249 TServiceMain AddReference TStreamClient: 3 04.02.25 20:12:45.090 TServiceMain ReleaseReference TStreamClient: 2 04.02.25 20:12:45.091 TServiceMain AddReference TStreamClient: 3 04.02.25 20:13:06.388 TServiceMain ReleaseReference WebMain: 2 04.02.25 20:13:12.019 TServiceMain ReleaseReference TStreamClient: 1 04.02.25 20:13:32.604 TServiceMain AddReference upnp webserver: 2 04.02.25 20:14:02.797 TServiceMain ReleaseReference upnp webserver: 1 gibt es dort 3 mal AddReference TStreamClient, aber nur zweimal ReleaseReference. Die Bilanz stimmt also nicht. Das werde ich bei nächster Gelegenheit mal überprüfen... Hast Du Windows 10 oder 11? Die verhalten sich hinsichtlich /requests verschieden und werden vom DMS auch verschieden behandelt. 1 Quote
JunePaik Posted February 6 Author Posted February 6 (edited) Windows 10 Das hyperaktive UPnP-fähige Gerät ist der Panasonic TV, Ethernet Kabel raus, Hyperaktivität vorbei. Im Menu der Glotze gibt es auch nix, um dieses Verhalten zu ändern. Hab dann die Option des UPNP AV Servers "PC-Energiesparmodus durch Anwender/andere Programme... verhindern" deaktiviert und Ethernet wieder ran. Damit sind AddReference / ReleaseReference Einträge im Log alle 30 Sek. auch nicht mehr vorhanden. Nur zum Verständnis... es könnte jetzt allerdings passieren, dass ein Live-Stream per DLNA Client der Pana Glotze dann nach 60 Minuten (Settings im Energiesparplan) abbricht, weil der Rechner in den Standby geht, oder? Wäre aber nicht tragisch. Das könnte man allerdings auch mit nem kleinen Script und ethtool aufm Raspberry abfangen, in der Art: checke ob IP der Glotze pingbar (ja) und Rechner vom DVBViewer pingbar (nein), dann hau magic packet raus. Den internen Zähler vom DVBViewer krieg ich wohl nur übern Neustart des Rechners resettet? Mach ich mal und beobachte. Besten Dank für deinen Support bisher. Edited February 6 by JunePaik Quote
Griga Posted February 6 Posted February 6 vor einer Stunde schrieb JunePaik: es könnte jetzt allerdings passieren, dass ein Live-Stream per DLNA Client der Pana Glotze dann nach 60 Minuten (Settings im Energiesparplan) abbricht, weil der Rechner in den Standby geht, oder? Wahrscheinlich nicht. Die Auslieferung des Streams hat eine Extra-Zählung. vor einer Stunde schrieb JunePaik: Den internen Zähler vom DVBViewer krieg ich wohl nur übern Neustart des Rechners resettet? Über einen Neustart des DVBViewer Media Servers: Stoppen im Tray-Menü, an gleicher Stelle wieder starten. Ich denke, die Zugriffsverletzung in der Netzwerk-Bibliothek ist die Ursache für das Problem. Muss nur noch Zeit finden, das näher zu untersuchen und herauszufinden, ob und wie es sich verhindern lässt. vor 10 Stunden schrieb Griga: Hast Du Windows 10 oder 11? Die verhalten sich hinsichtlich /requests verschieden und werden vom DMS auch verschieden behandelt. Ich vertrage es schlecht, wenn Anwender, die Support möchten, meine Fragen nicht beantworten Quote
JunePaik Posted February 6 Author Posted February 6 Ich habe diese Frage an 2 Stellen in Beitrag #3 und #5 beantwortet. In #3 war es noch nicht mal eine Frage: vor 19 Stunden schrieb JunePaik: diese Windows 10 Kiste vor 2 Stunden schrieb JunePaik: Windows 10 Grüße Quote
Griga Posted February 7 Posted February 7 Am 6.2.2025 um 19:23 schrieb JunePaik: Ich habe diese Frage an 2 Stellen in Beitrag #3 und #5 beantwortet. Sorry, habe ich übersehen. Grundsätzlich ist es immer günstig, wenn eine support.zip vorliegt, weil ich mir anhand des Inhalts solche Fragen selbst beantworten kann, anstatt sie im Text auffinden oder rückfragen zu müssen. Zur Zeit komme ich nicht richtig weiter, weil ich nicht weiß, welche Media Server-Version du hast und weil kein vollständiges Log vorliegt. Fest steht nur, dass das Problem nichts mit dem Timer zu tun hat, sondern wahrscheinlich mit Live Streams. Laut Log wurde beim Auftreten des Fehlers einer an einen Client mit dem User Agent "GStreamer souphttpsrc libsoup/2.52.2" ausgeliefert. Erst RTL CH mit Empfangsart TS Stream - das verlief schon nicht erwartungsgemäß, was ich aber bislang nicht verstehe - danach RTL NITRO, 60 ms davor trat der Fehler auf, und wenige Sekunden später wieder RTL CH. 1 Quote
JunePaik Posted February 7 Author Posted February 7 (edited) Das sind Aufrufe der Dreambox. Die Sender (HLS 7 Streams) werden in dieser Art direkt über die Kanalliste des Receiver vom Media-Server abgerufen: #SERVICE 1:0:19:6F:3264:13E:820000:0:0:0:http%3a//192.168.178.46%3a7522/upnp/channelstream/4135537422240854592|RTL CH.ts:RTL CH #DESCRIPTION RTL CH Alles vor dem http entspricht der Service-Referenz, wobei nur der erste Wert (Service-Type) relevant ist, danach kann irgendwas stehen. Da meine ältere Dream kein HLS/DASH von Haus aus kann, überhaupt der Umweg übern Media-Server. Rein zu Info: Zitat There are 3 (4) servicetypes 1 for DVB or in general TS compliant streams 4097 is basically used for everything via GSteamer 8739 is the new streamservice on Dreambox One and Two, used for HLS, DASH playback and also DRM, as replacement for the crappy GSteamer HLS and DASH support 8193 is not a real servicetype it just calls some resolver code in Python, but playback runs via 4097, just to make that clear as I've seen many users playing m3u8 via 8193 which makes no sense as it just directly is calling 4097 then. Die Streams der Schweizer werden über die telerinsing-Api bereit gestellt. Eine support-zip schicke ich dir per PM. Diese Meldung konnte ich nachstellen: 07.02.25 14:51:44.600 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00667E70 in Modul 'DVBVservice.exe'. Schreiben von Adresse 00667E70 Passiert dann wenn, Wireguard-Verbindung (für schweizer IP) temp down. Telerising kann mit alter Session die Schweizer nicht mehr bereitstellen, Dreambox versucht Streams abzurufen, geht nicht. Wireguard-Verbindung wieder da, Telerising Session Update erfolgt, Streams wieder da, umzappen in Dreambox, Sender spielt ab. Kurz davor diese Fehlermeldung. Beste Grüße Edited February 7 by JunePaik Quote
JunePaik Posted February 7 Author Posted February 7 (edited) Hier hab ich mal VPN gestoppt und durch die Sender gezappt. Der Zähler steigt. Media-Server kriegt wohl nicht mit, daß die Dream den Stream nicht abspielen kann und lässt das TS Stream Device irgendwie offen/laufen? Spoiler 07.02.25 15:10:58.240 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 07.02.25 15:10:58.240 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135663308242914688|ORF Eins.ts 07.02.25 15:10:58.240 TServiceMain AddReference TStreamClient: 3 07.02.25 15:10:58.240 TFileDevice RunDevice 07.02.25 15:10:58.240 TLiveStream AllocateHardware TS Stream Device 07.02.25 15:10:58.240 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 3554512256, LOF: 54869, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 18114, Flags: 24, Group: 0 07.02.25 15:10:58.269 TFileDevice CloseDevice 07.02.25 15:11:02.125 Release TS Stream Device 07.02.25 15:11:02.125 Free TS Stream Device 07.02.25 15:11:02.125 Freed TS Stream Device 07.02.25 15:11:02.125 hamDeleted TS Stream Device 07.02.25 15:11:25.818 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00667E70 in Modul 'DVBVservice.exe'. Schreiben von Adresse 00667E70 07.02.25 15:11:25.865 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 07.02.25 15:11:25.865 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135568105997826127|ORF 2.ts 07.02.25 15:11:25.865 TServiceMain AddReference TStreamClient: 4 07.02.25 15:11:25.865 TFileDevice RunDevice 07.02.25 15:11:25.865 TLiveStream AllocateHardware TS Stream Device 07.02.25 15:11:25.865 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 2101835855, LOF: 3363, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 23252, Flags: 24, Group: 0 07.02.25 15:11:25.897 TFileDevice CloseDevice 07.02.25 15:11:28.208 Release TS Stream Device 07.02.25 15:11:28.208 Free TS Stream Device 07.02.25 15:11:28.208 Freed TS Stream Device 07.02.25 15:11:28.208 hamDeleted TS Stream Device 07.02.25 15:11:35.021 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00667E70 in Modul 'DVBVservice.exe'. Schreiben von Adresse 00667E70 07.02.25 15:11:35.084 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 07.02.25 15:11:35.084 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135606009084206826|ORF3.ts 07.02.25 15:11:35.084 TServiceMain AddReference TStreamClient: 5 07.02.25 15:11:35.084 TFileDevice RunDevice 07.02.25 15:11:35.084 TLiveStream AllocateHardware TS Stream Device 07.02.25 15:11:35.084 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 2680184554, LOF: 60758, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 20703, Flags: 24, Group: 0 07.02.25 15:11:35.117 TFileDevice CloseDevice 07.02.25 15:11:38.240 Release TS Stream Device 07.02.25 15:11:38.240 Free TS Stream Device 07.02.25 15:11:38.240 Freed TS Stream Device 07.02.25 15:11:38.240 hamDeleted TS Stream Device 07.02.25 15:11:40.131 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00667E70 in Modul 'DVBVservice.exe'. Schreiben von Adresse 00667E70 07.02.25 15:11:40.193 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 07.02.25 15:11:40.193 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135710080436770192|ServusTV.ts 07.02.25 15:11:40.193 TServiceMain AddReference TStreamClient: 6 07.02.25 15:11:40.193 TFileDevice RunDevice 07.02.25 15:11:40.193 TLiveStream AllocateHardware TS Stream Device 07.02.25 15:11:40.193 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 4268201360, LOF: 53924, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 24164, Flags: 24, Group: 0 07.02.25 15:11:41.485 TFileDevice CloseDevice 07.02.25 15:11:44.271 Release TS Stream Device 07.02.25 15:11:44.271 Free TS Stream Device 07.02.25 15:11:44.271 Freed TS Stream Device 07.02.25 15:11:44.271 hamDeleted TS Stream Device 07.02.25 15:11:44.382 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00667E70 in Modul 'DVBVservice.exe'. Schreiben von Adresse 00667E70 07.02.25 15:11:44.445 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 07.02.25 15:11:44.445 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135493846013267751|SRF 1.ts 07.02.25 15:11:44.445 TServiceMain AddReference TStreamClient: 7 07.02.25 15:11:44.445 TFileDevice RunDevice 07.02.25 15:11:44.445 TLiveStream AllocateHardware TS Stream Device 07.02.25 15:11:44.445 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 968707879, LOF: 19542, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 17352, Flags: 24, Group: 0 07.02.25 15:11:44.478 TFileDevice CloseDevice 07.02.25 15:11:48.290 Release TS Stream Device 07.02.25 15:11:48.290 Free TS Stream Device 07.02.25 15:11:48.290 Freed TS Stream Device 07.02.25 15:11:48.290 hamDeleted TS Stream Device 07.02.25 15:11:51.560 TStreamManager ServerBgException EAccessViolation: Zugriffsverletzung bei Adresse 00667E70 in Modul 'DVBVservice.exe'. Schreiben von Adresse 00667E70 07.02.25 15:11:51.615 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 07.02.25 15:11:51.615 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135532857201198660|SRF 2.ts 07.02.25 15:11:51.615 TServiceMain AddReference TStreamClient: 8 07.02.25 15:11:51.615 TFileDevice RunDevice 07.02.25 15:11:51.615 TLiveStream AllocateHardware TS Stream Device 07.02.25 15:11:51.615 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 1563952708, LOF: 16366, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 21273, Flags: 24, Group: 0 07.02.25 15:11:51.646 TFileDevice CloseDevice 07.02.25 15:11:54.322 Release TS Stream Device 07.02.25 15:11:54.322 Free TS Stream Device 07.02.25 15:11:54.322 Freed TS Stream Device 07.02.25 15:11:54.322 hamDeleted TS Stream Device Edited February 7 by Griga Spoiler-Tags ergänzt Quote
Griga Posted February 8 Posted February 8 On 2/7/2025 at 3:19 PM, JunePaik said: Hier hab ich mal VPN gestoppt und durch die Sender gezappt. Der Zähler steigt. Media-Server kriegt wohl nicht mit, daß die Dream den Stream nicht abspielen kann und lässt das TS Stream Device irgendwie offen/laufen? Es verhält sich etwas anders. Ich konnte das Problem jetzt dank deiner Untersuchungen reproduzieren, aber erst nach einigen Klimmzügen mittels Simulation, da ich keinen Client habe, der sich wie GStreamer verhält. Es passiert folgendes: GStreamer will einen Stream vom DMS haben. Der Sender ist jedoch nicht empfangbar. Der Livestream Server erhält einen Fehlercode vom verwendeten Gerät (hier ein TS Stream Device) und meldet sich deshalb als Benutzer des Gerätes ab. GStreamer erhält vom Livestream Server einen 404 Not Found Statuscode zurück. Clients beenden daraufhin normalerweise die Verbindung, was ebenfalls dazu führt, dass der Livestream Server sich als Benutzer des von ihm verwendeten Gerätes abmeldet. Es passiert dann also unnötigerweise doppelt, was aber nichts ausmacht. Zusätzlich ruft der Server beim Schließen der Verbindung ReleaseReference auf, was eventuell ReleaseStandbyBlock nach sich zieht. GStreamer lässt jedoch die Verbindung stehen. Also passiert in der Hinsicht erst mal nichts. Wird das Gerät auch anderweitig nicht mehr benutzt, gibt es der DMS mittels Timer nach spätestens 3 Sekunden frei, d.h. entfernt es aus dem Speicher. Dass dies passiert, ist auch in deinem Log zu sehen (Release TS Stream Device usw.). Die verzögerte Freigabe dient dazu, eine eventuell zeitaufwändige erneute Initialisierung zu vermeiden, falls Clients bei einer Senderumschaltung die Verbindung schließen und für den nächsten Sender erneut aufbauen. Geschehen Schließen und Neuaufbau innerhalb von 2 Sekunden, ist das Gerät noch im Speicher und kann "recycelt" werden, wodurch die Senderumschaltung schneller geht. GStreamer schließt die Verbindung jedoch erst und baut eine neue auf, wenn du in der Dreambox auf einen anderen Sender umschaltest. Wie bereits in 2. angegeben, versucht der Livestream Server, sich beim Schließen als Benutzer des Gerätes abzumelden. Dieses ist jedoch inzwischen freigegeben bzw. gar nicht mehr im Speicher, was zu einer Zugriffsverletzung führt. Der nachfolgende Code (ReleaseReference) wird dadurch übersprungen, und die Verbindung bleibt serverseitig stehen, weshalb sie auch weiterhin auf der Statusseite des Webinterface erscheint. Neben dem nicht sehr sinnvollen GStreamer-Management der Verbindung ist auch der Livestream Server in der Hinsicht nicht optimal organisiert. Ein Zugriff auf etwas, das sich nicht mehr im Speicher befindet, ist unbedingt zu vermeiden. Was passieren kann, wenn das Gerät beim Tunen eines Senders einen Fehler meldet, ist nicht ausreichend berücksichtigt. Es lässt sich im Prinzip leicht fixen, und ich könnte dir per PM eine entsprechende Testversion zur Verfügung stellen, aber es bleibt die Tatsache, dass GStreamer im Falle eines Fehlers beim Tunen die Verbindung und damit eventuell auch den Standby-Block aufrechterhält - wie lange, weiß ich nicht. 1 Quote
JunePaik Posted February 8 Author Posted February 8 Die Testversion würde ich gerne ausprobieren. Mit dem Verhalten der Dreambox muss man wohl leben, da beim verwendeten GStreamer od. generell der Entwicklung nach Insolvenz von Dream Property nichts mehr kommen wird. Wenn du magst, kannst du den Thread gerne in etwas Aussagekräftigeres umbenennen, da meine Vermutung des Timer-Management bzgl. ja völlig falsch war. Quote
Griga Posted February 8 Posted February 8 vor 7 Stunden schrieb JunePaik: Die Testversion würde ich gerne ausprobieren. Siehe PM. 1 Quote
JunePaik Posted February 9 Author Posted February 9 (edited) Hab diese "Teststrecke" wiederholt. Sieht gut aus: Spoiler 09.02.25 09:14:11.316 Start App ------------------------------------------------------------ 09.02.25 09:14:11.316 DVBViewer Media Server 3.3.1.1 as service 09.02.25 09:14:11.316 TServiceMain Execute Start 09.02.25 09:14:11.316 TServiceMain StartService start timer 09.02.25 09:14:11.316 TServiceMain StartService Create plugin list 09.02.25 09:14:11.332 TServiceMain StartService found 0 plugins 09.02.25 09:14:11.363 TServiceMain channellist loaded 09.02.25 09:14:11.363 TDVBDeviceList LoadSettings No hardware list found 09.02.25 09:14:11.379 TDVBDeviceList LoadSettings Loading DVBViewer hardware list 09.02.25 09:14:11.379 TDVBDeviceList LoadSettings New Devicelist 09.02.25 09:14:11.395 TServiceMain Start Searches load 09.02.25 09:14:11.410 TTaskList LoadDoc default\config\tasks.xml loaded 09.02.25 09:14:11.410 SendUpdate DVBVUPDATE TMR 09.02.25 09:14:11.410 TServiceMain Start VCR load 09.02.25 09:14:11.552 TServiceMain Start EPG load 09.02.25 09:14:11.614 TUPnPDevice Start 09.02.25 09:14:11.630 TUPnPAnnounce Start 09.02.25 09:14:11.630 TUPnPAnnounce InitWsocket 192.168.178.46 09.02.25 09:14:11.630 TUPnPAnnounce InitWsocket 10.145.166.46 09.02.25 09:14:11.630 TUPnPAnnounce InitWsocket 127.0.0.1 09.02.25 09:14:11.630 TServiceMain LoadSetup end 09.02.25 09:14:11.645 TServiceMain StartService setup loaded 09.02.25 09:14:11.645 TServiceMain Service Enabled 09.02.25 09:14:11.645 SendUpdate DVBVUPDATE REC 09.02.25 09:14:11.645 SendUpdate DVBVUPDATE TMR 09.02.25 09:14:22.080 TServiceMain AddReference WebMain: 1 09.02.25 09:14:22.080 SetStandbyBlock WebMain 09.02.25 09:15:04.743 TServiceMain ReleaseReference WebMain: 0 09.02.25 09:15:04.743 ReleaseStandbyblock WebMain 09.02.25 09:17:00.469 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 09.02.25 09:17:00.469 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135638930008519169|ProSieben MAXX.ts 09.02.25 09:17:00.469 TServiceMain AddReference TStreamClient: 1 09.02.25 09:17:00.469 SetStandbyBlock TStreamClient 09.02.25 09:17:00.469 TFileDevice RunDevice 1 09.02.25 09:17:00.469 TLiveStream AllocateHardware TS Stream Device 09.02.25 09:17:00.469 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 3182506497, LOF: 41504, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 24562, Flags: 24, Group: 0 09.02.25 09:17:07.578 TRTSPWebserver ClientConnect 04482090 09.02.25 09:17:08.620 TRTSPWebserver HttpServerGetDocument /description.xml? 09.02.25 09:17:09.137 TRTSPWebserver ClientDisconnect 04482090 09.02.25 09:17:20.291 TServiceMain ReleaseReference TStreamClient: 0 09.02.25 09:17:20.291 ReleaseStandbyblock TStreamClient 09.02.25 09:17:24.217 Release TS Stream Device 09.02.25 09:17:24.217 Free TS Stream Device 09.02.25 09:17:24.247 TFileDevice StopDevice 09.02.25 09:17:24.247 TFileDevice CloseDevice 09.02.25 09:17:24.249 Freed TS Stream Device 09.02.25 09:17:24.249 hamDeleted TS Stream Device 09.02.25 09:17:56.364 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 09.02.25 09:17:56.364 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135537422240854592|RTL CH.ts 09.02.25 09:17:56.364 TServiceMain AddReference TStreamClient: 1 09.02.25 09:17:56.364 SetStandbyBlock TStreamClient 09.02.25 09:17:56.364 TFileDevice RunDevice 1 09.02.25 09:17:56.364 TLiveStream AllocateHardware TS Stream Device 09.02.25 09:17:56.364 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 1633628736, LOF: 6785, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 23180, Flags: 24, Group: 0 09.02.25 09:17:56.389 TFileDevice CloseDevice 09.02.25 09:18:00.332 Release TS Stream Device 09.02.25 09:18:00.332 Free TS Stream Device 09.02.25 09:18:00.332 Freed TS Stream Device 09.02.25 09:18:00.332 hamDeleted TS Stream Device 09.02.25 09:18:16.130 TServiceMain ReleaseReference TStreamClient: 0 09.02.25 09:18:16.130 ReleaseStandbyblock TStreamClient 09.02.25 09:18:16.192 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 09.02.25 09:18:16.192 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135610191871797287|RTL NITRO.ts 09.02.25 09:18:16.192 TServiceMain AddReference TStreamClient: 1 09.02.25 09:18:16.192 SetStandbyBlock TStreamClient 09.02.25 09:18:16.192 TFileDevice RunDevice 1 09.02.25 09:18:16.192 TLiveStream AllocateHardware TS Stream Device 09.02.25 09:18:16.192 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 2744051751, LOF: 14485, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 18436, Flags: 24, Group: 0 09.02.25 09:18:16.215 TFileDevice CloseDevice 09.02.25 09:18:18.395 Release TS Stream Device 09.02.25 09:18:18.395 Free TS Stream Device 09.02.25 09:18:18.395 Freed TS Stream Device 09.02.25 09:18:18.395 hamDeleted TS Stream Device 09.02.25 09:18:29.911 TServiceMain ReleaseReference TStreamClient: 0 09.02.25 09:18:29.911 ReleaseStandbyblock TStreamClient 09.02.25 09:18:29.958 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 09.02.25 09:18:29.958 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135549100767522031|RTLplus.ts 09.02.25 09:18:29.958 TServiceMain AddReference TStreamClient: 1 09.02.25 09:18:29.958 SetStandbyBlock TStreamClient 09.02.25 09:18:29.958 TFileDevice RunDevice 1 09.02.25 09:18:29.958 TLiveStream AllocateHardware TS Stream Device 09.02.25 09:18:29.958 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 1811819759, LOF: 27001, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 21335, Flags: 24, Group: 0 09.02.25 09:18:29.991 TFileDevice CloseDevice 09.02.25 09:18:32.442 Release TS Stream Device 09.02.25 09:18:32.442 Free TS Stream Device 09.02.25 09:18:32.442 Freed TS Stream Device 09.02.25 09:18:32.442 hamDeleted TS Stream Device 09.02.25 09:18:48.869 TUPnPAnnounce InitWsocket 10.145.166.46 09.02.25 09:18:53.744 TServiceMain ReleaseReference TStreamClient: 0 09.02.25 09:18:53.744 ReleaseStandbyblock TStreamClient 09.02.25 09:18:53.795 TStreamManager GetDocument GStreamer souphttpsrc libsoup/2.52.2; 09.02.25 09:18:53.795 TStreamManager GetDocument c:\wwwroot\upnp\channelstream\4135494068840987946|RTL2.ts 09.02.25 09:18:53.795 TServiceMain AddReference TStreamClient: 1 09.02.25 09:18:53.795 SetStandbyBlock TStreamClient 09.02.25 09:18:53.795 TFileDevice RunDevice 1 09.02.25 09:18:53.795 TLiveStream AllocateHardware TS Stream Device 09.02.25 09:18:53.795 TFileDevice SetTuner TType: 6, Freq: 0, Symrate: 972127530, LOF: 31240, Tone: 9, Pol: 0, DiseqC: 0, FEC: 1, APID: 7791, VPID: 34, PMT: 32, SID: 1, TID: 1, NID: 0, SatMod: 0, DiseqCVal: 20702, Flags: 24, Group: 0 09.02.25 09:19:12.543 TServiceMain ReleaseReference TStreamClient: 0 09.02.25 09:19:12.543 ReleaseStandbyblock TStreamClient 09.02.25 09:19:14.587 Release TS Stream Device 09.02.25 09:19:14.587 Free TS Stream Device 09.02.25 09:19:14.640 TFileDevice StopDevice 09.02.25 09:19:14.640 TFileDevice CloseDevice 09.02.25 09:19:14.641 Freed TS Stream Device 09.02.25 09:19:14.641 hamDeleted TS Stream Device 09.02.25 09:19:24.813 TServiceMain AddReference WebMain: 1 09.02.25 09:19:24.813 SetStandbyBlock WebMain 09.02.25 09:20:04.691 TServiceMain ReleaseReference WebMain: 0 09.02.25 09:20:04.691 ReleaseStandbyblock WebMain Vielen Dank. Edited February 9 by JunePaik Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.