D3ltorohd Posted May 31, 2019 Posted May 31, 2019 Hall Com, mir ist in letzter Zeit aufgefallen, das sich der Server immer wieder mal aufhängt oder zumindest das Web GUI. Ich kann dann dort nicht mehr drauf zugreifen, aufnahmen die laufen scheint er aber fertig zu machen. Ich kill ihn im Task Manager und starte ihn dann neu, dann läuft wieder alles. Ich hänge HIER mal die Log mit an, gestern Abend muss das passiert sein, ich sage mal ab 19:30 irgendwann. Vllt könnt ihr sehen, warum er sich aufhängt und was man dagegen tun kann. Grüße, Quote
nuts Posted May 31, 2019 Posted May 31, 2019 30.05.19 16:50:12.436 TServiceMain Standby PBT_APMSUSPEND 30.05.19 16:50:12.436 TServiceMain Setting next recording: 30.05.2019 20:07:00 30.05.19 16:50:12.436 ThdProc Enter 30.05.19 16:50:12.436 TUPnPAnnounce Stopped 30.05.19 16:50:12.436 TUPnPDevice Stopped 30.05.19 16:50:12.470 TRTSPWebserver Disconnected 30.05.19 16:50:12.657 TSynHttpServer ServerLoop terminated 30.05.19 16:50:12.673 TSrvDataModule Freed 30.05.19 20:07:33.906 TServiceMain Time changed 30.05.19 20:07:34.233 ThdProc Timer fired 30.05.19 20:07:34.233 TServiceMain Resume PBT_APMRESUMEAUTOMATIC Gestern Abend um 19:30 Uhr hat dein PC lt. Log geschlafen. Quote
D3ltorohd Posted June 1, 2019 Author Posted June 1, 2019 War nur eine grobe Angabe, ich bin mir nicht sicher, ich habe um ca. 22 Uhr oder etwas später probiert Live TV zu schauen, da viel mir auf das nichts geht am Client. Irgendwann zwischen 22 - 23 Uhr. Ich sehe er hat noch 2 Aufnahmen gemacht, ab 20:15 oder 21 Uhr. Also muss er da noch intakt gewesen sein. Quote
Griga Posted June 2, 2019 Posted June 2, 2019 Für die zuletzt gestartete Aufnahme sieht man im Log keinen Abschluss. Es könnte auch daran liegen, dass der Teil des Logs sich noch in einem Puffer befand, als sich der Server aufgehängt hat, und deshalb nicht mehr geschrieben wurde. Ist die Aufnahme vollständig bzw. hat sie die erwartete Länge? Du nimmst relativ viel über die TS Stream-Schiene auf. Besteht vielleicht damit ein Zusammenhang? Sind die URLs HTTP oder HTTPS? Geschieht das Einfrieren während des Empfangs solcher Sender? Wenn der Stream abbricht, der DMS versucht, die Verbindung wieder herzustellen, aber der ausliefernde Server nicht oder nur sehr zögerlich antwortet, vielleicht weil er überlastet ist, kann der Empfänger einige Zeit in dem Prozess festhängen. Er ist dann nicht unbedingt tot, aber zeitweise nicht mehr ansprechbar. Quote
D3ltorohd Posted June 6, 2019 Author Posted June 6, 2019 Also hier noch mal eine Log, denke das ist das selbe Ergebnis. Kann leider hier keine Logs hochladen... Deshalb hier von meiner OneDrive Ich nehme momentan viel über TS Streams auf das stimmt, wenn ich die Sender anschaue, laufen sie einwandfrei und stabil. Ich schaue mir morgen mal die letzten 3 von heute an, ob die Vollständig sind. Zugreifen kann ich dann erst wieder wenn ich den Prozess kille und den DMS neu starte. Die Files sind mal in der Zeit größer geworden. Denke die Aufnahme funktioniert weiterhin. Der Server sollte sehr stabil laufen und ist mit Sicherheit nicht überlastet. Aber stimmt, jetzt wo du das erwähnst, ich meine das tritt so häufig auf, seitdem ich TS Streams für Aufnahmen nutze. Quote
Griga Posted June 7, 2019 Posted June 7, 2019 13 hours ago, D3ltorohd said: Also hier noch mal eine Log, denke das ist das selbe Ergebnis. Bestätigt meine Vermutung. Gestern abend sollte der DMS um 20:10 drei TS Stream-Aufnahmen durchführen. Offenbar waren die Streams nur kurzzeitig empfangbar. Nach den Aufnahmestarts hat der DMS zunächst die Senderdaten aktualisiert, wahrscheinlich weil in der verwendeten Senderliste nur die URLs der Sender (aus einer M3U-Liste?) stehen. Alles weitere muss der DMS erst ermitteln. Würde er ordnungsgemäß beendet, sollte er eigentlich die vervollständigten Senderdaten in der channels.dat speichern, damit er die Sender das nächste Mal schneller einstellen kann, aber soweit kommt es gar nicht. Schon 15 Sekunden nach den Aufnahmestarts erscheinen wiederholte Meldungen "CheckAutoRetune Retuning TS Stream Device..." für alle drei Aufnahmen bzw. virtuellen TS Stream-Geräte im Log. Sowas passiert, wenn keine Daten mehr eintreffen. Das Spiel setzte sich bis ca. 20:24 fort, dann bricht das Loggen dieser Vorgänge ab. Der DMS wurde irgendwann danach irregulär beendet und um 22:00 neu gestartet. Laut Log kann keine der drei Aufnahmen etwas geworden sein. Quote
Webturtle Posted June 7, 2019 Posted June 7, 2019 Hallo, hast Du mal nachgesehen, wieviel Arbeitsspeicher der DMS belegt? Bei mir hängt sich der DVBViewer Pro manchmal auf wenn viele "Karteileichen" in der Aufnahmedatenbank vorhanden sind (vgl. dazu http://de.DVBViewer.tv/wiki/Aufnahme_und_Timerstatistik). Also viele Aufnahmen vom Aufnahmeverzeichnis auf einen externen Datenträger verschoben worden sind. Von den Aufnahmen ist also nur noch der Eintrag in der Aufnahmedatenbank vorhanden. Der DVBViewer Pro fängt dann an extrem viel Speicher zu verbrauchen. Er ist dann nicht mehr bedienbar. Begonnene Aufnahmen werden fortgesetzt, aber nicht mehr automatisch beendet. Noch anstehende Aufnahmen werden nicht mehr gestartet. Das laufende Programm wird auch weiter angezeigt. Wenn man die Aufnahmedatenbank bereinigt (z.B. über Aufnahmeoptionen) hat man wieder eine Weile Ruhr vor dieser Störung. Viele Grüße Webturtle Quote
D3ltorohd Posted June 7, 2019 Author Posted June 7, 2019 3 hours ago, Griga said: Bestätigt meine Vermutung. Gestern abend sollte der DMS um 20:10 drei TS Stream-Aufnahmen durchführen. Offenbar waren die Streams nur kurzzeitig empfangbar. Nach den Aufnahmestarts hat der DMS zunächst die Senderdaten aktualisiert, wahrscheinlich weil in der verwendeten Senderliste nur die URLs der Sender (aus einer M3U-Liste?) stehen. Alles weitere muss der DMS erst ermitteln. Würde er ordnungsgemäß beendet, sollte er eigentlich die vervollständigten Senderdaten in der channels.dat speichern, damit er die Sender das nächste Mal schneller einstellen kann, aber soweit kommt es gar nicht. Schon 15 Sekunden nach den Aufnahmestarts erscheinen wiederholte Meldungen "CheckAutoRetune Retuning TS Stream Device..." für alle drei Aufnahmen bzw. virtuellen TS Stream-Geräte im Log. Sowas passiert, wenn keine Daten mehr eintreffen. Das Spiel setzte sich bis ca. 20:24 fort, dann bricht das Loggen dieser Vorgänge ab. Der DMS wurde irgendwann danach irregulär beendet und um 22:00 neu gestartet. Laut Log kann keine der drei Aufnahmen etwas geworden sein. Hm ist nur komisch, wenn ich über den DVBViewer schaue, laufen die Kanäle wunderbar, anklicken 2 Sekunden und Bild und Ton sind da. Genau sind Sender mit URL's aus einer m3u Liste. Was kann ich hier tun, damit das besser wird ? Oder was kann ich optimieren ? Wie gesagt, direktes anschauen funktioniert wunderbar. Die Aufnahmen sind da, ich werde sie später mal anschauen, ob da was aufgenommen wurde. @Webturtle, ich habe dort eigentlich nur Leichen drin, weil die alle von Emby verschoben werden, werde ich mal bereinigen. Quote
Griga Posted June 7, 2019 Posted June 7, 2019 4 hours ago, D3ltorohd said: Hm ist nur komisch, wenn ich über den DVBViewer schaue, laufen die Kanäle wunderbar Laufen der DVBViewer und DMS auf dem selben PC? Quote
carmen.vvl Posted June 11, 2019 Posted June 11, 2019 (edited) Vielleicht ist es bei mir dasselbe Problem: Der DMS läuft (mit ein paar anderen Diensten) auf einem dedizierten Server, für Aufnahmen gibt es separate Platten, das System hat eine SSD, die DVB-Signale kommen von einer SAT->IP Box (vierfach). Der Viewer läuft auf dem HTPC, alles Gigabit-verkabelt. Das ganze Setup läuft seit über zehn Jahren stabil, natürlich wurde hier und da verfeinert und erneuert, in letzter Zeit aber nicht, die Software ist aktuell. Ich beobachte seit einiger Zeit, dass das Webinterface des Servers äußerst langsam reagiert, ebenso das OSD des Viewers. So dauert der Wechsel von z.B. 'Programme' zu 'Aufnahmen' oder 'Status' ca. eine Minute - ohne (Fehler-)Meldungen des Browsers. Dabei laufen aber die Aufnahmen und das Live-Prgramm weiter, die Aufnahmen sind o.k. Das Ganze passiert anscheinend bei mehreren parallelen Aufnahmen - aber nicht immer. Was hilft ist ein Neustart des DMS, aber über 'Dienste', da auch das Beenden sehr lange dauert. Ach, die CPU-Last auf dem Server liegt im einstelligen Prozentbereich, auch ein Speicherleck ist mir nicht aufgefallen, ebenso nichts bei den Platten, alles ruhig und normal wie sonst. Ach ja, ich habe schon mal die Priorität der Aufnahmen von 'höher als normal' auf 'normal' herunter gesetzt - ohne Effekt. Edited June 11, 2019 by carmen.vvl Quote
D3ltorohd Posted July 31, 2019 Author Posted July 31, 2019 On 6/11/2019 at 10:59 AM, carmen.vvl said: anscheinend bei mehreren parallelen Aufnahmen Das meine ich auch. Habe das nun eine weile beobachtet. So 1-2 aufnahmen alles ok, sind dann mal mehr wie 2 zur gleichen Zeit wars das. Das Webinterface und denke auch der DMS sind danach weg. Die Aufnahmen wurden angefangen, aber nicht zu ende gebracht. Die wo noch anstanden sind natürlich nicht ausgeführt worden. Könnte man hier mal noch genauer nachforschen und vllt auf den Fehler stoßen, was hier das Problem ist ? Wenn noch irgendwas gebraucht werden sollte, bitte melden. Man kann es normal auch reproduzieren. Wenn ich mehrere Aufnahmen zur selben Zeit starte, müsste es dem DMS den rest geben. Wäre klasse, wenn man das irgendwie in den Griff bekommt. Ich habe auf Grund dieser Probleme, schon alternativen ausprobiert, aber nicht wirklich eine gefunden. Quote
Griga Posted August 1, 2019 Posted August 1, 2019 13 hours ago, D3ltorohd said: Habe das nun eine weile beobachtet. So 1-2 aufnahmen alles ok, sind dann mal mehr wie 2 zur gleichen Zeit wars das. Da du TS Stream als Empfangsart für deine Aufnahmen verwendest, vermute ich, dass bei mehr als zwei Streams gleichzeitig die Gesamt-Datenrate zu hoch wird, an welcher Stelle der Netzwerkverbindung auch immer... dann kommt es zu Aussetzern bzw. Stream-Abbrüchen, die Option "Bei fehlendem Stream neu tunen nach..." greift ein, beim Retune lassen die Server elend lange auf eine Antwort warten (oder antworten bis zum Timeout gar nicht), und dann reagiert der DMS insgesamt nur noch sehr zögerlich. Der Vergleich mit dem DVBViewer hat wenig Aussagekraft, solange du dort nur einen Stream (oder maximal zwei mit Bild in Bild) empfängst. Der Code für den TS Stream-Empfang ist im DMS und DVBViewer identisch. Quote
D3ltorohd Posted August 2, 2019 Author Posted August 2, 2019 Hm, ich hatte gestern auf die 2.5.1.0 geupdated. Gestern abend liefen dann 4 Aufnahmen gleichzeitig und das ohne Probleme, er hat sich nicht aufgehängt, das Webinterface war erreichbar und die Recordings gehen alle. Ich wollte vorher schon schreiben, ob da vllt was gefixt wurde, was diese Sache betrift. Aber leider sah es heute wieder anders aus. Heute Abend liefen 3 Aufnahmen gleichzeitig, ich hab immer wieder mal ins Webinterface geschaut, alles IO. Irgendwann zwischen 20:30 und 20:45 wars das dann wieder, das WebI ging nicht mehr. Die Recording Files wurden nicht größer, also den Task beendet. Was komisch war und zum ersten mal passierte, er startete direkt neu und nahm weite rauf, das war sonst nicht der Fall. Aber auf jeden Fall gestern ging's mit 4 heute bei 3 dann irgendwann nicht mehr. Wenn ich unter Status schaue, braucht jeder Stream meistens so bis 0,8 MB/s das wären 4 MB/s hab eine 5 MB/s Leitung, das sollte doch passen. Kann man hier irgendwas anderes einstellen, oder das so programmieren das er sich deswegen nicht aufhängt, oder in Panik gerät und einfach weiter aufnimmt, dann könnte vllt sein das in der Aufnahme mal kurt 1,2,3 Sekunden fehlen ? Aber das der gleich abschmiert. Quote
Griga Posted August 3, 2019 Posted August 3, 2019 11 hours ago, D3ltorohd said: braucht jeder Stream meistens so bis 0,8 MB/s das wären 4 MB/s hab eine 5 MB/s Leitung, , das sollte doch passen Beachte den Unterschied zwischen Brutto- und Netto-Datenrate! Provider-Angaben sind üblicherweise Brutto, der DMS zeigt die Nettorate an, d.h. der ganze Protokoll-Overhead ist nicht mit drin. Hast du schon daran gedacht, dass die Probleme auch durch die von dir belangten Server bzw. deren Auslastung bedingt sein könnten? Quote
Griga Posted August 3, 2019 Posted August 3, 2019 21 hours ago, D3ltorohd said: Kann man hier irgendwas anderes einstellen, oder das so programmieren das er sich deswegen nicht aufhängt In den Hardware-Optionen eine ausreichende Anzahl TS Stream-Geräte vorsehen und bei allen das standardmäßige "Bei fehlendem Stream nach neu tunen nach..." auf 0 setzen könnte helfen. 1 Quote
D3ltorohd Posted August 5, 2019 Author Posted August 5, 2019 Das werde ich mal probieren und schauen, wie es sich die Tage verhält. Mit dem Server sollte es keine Probleme geben. Quote
nixi Posted August 9, 2019 Posted August 9, 2019 Ich habe auch das der Server sich spontan aufhängt. Es ist aber völlig unabhängig von der Anzahl der Aufnahmen und vom Sender. Manchmal läuft der Server mehr als 4 Wochen ohne Probleme und dann hängt er 2 mal die Woche. Gestreamt wird von einem OctopusNet Receiver. Seit dem letzten Update lässt sich der Dienst über den Taskmanager beenden und über das Tray Icon wieder starten, vorher musste der Rechner neu gestartet werden. Noch schöner wäre es, wenn der Dienst automatisch neu gestartet werden würde, nur erkennt Windows das scheinbar nicht. Quote
D3ltorohd Posted August 15, 2019 Author Posted August 15, 2019 Das wäre vllt eine Idee, das er automatisch neustartet. Ich habe jetzt mal 4 Devices am laufen, die werden auch fleißig benutzt. Mir ist aufgefallen, das ein Stream sauber aufgenommen wird, 2 weitere dann irgendwann nicht mehr, der andere läuft ganz normal weiter, die beiden anderen Aufnahmen, nehmen kaum an Größe zu, und es wird auch fast nichts gestreamed von der Mbit/s her. Ich hab ja wie oben als Tip nun mal On 8/3/2019 at 7:19 PM, Griga said: "Bei fehlendem Stream nach neu tunen nach..." auf 0 setzen gesetzt. Ich meine seither ist der Server nicht mehr abgeschmiert, aber die Streams werden nicht immer sauber aufgenommen. Schau ich Life verschiedene Sender an, kann ich diese Stundenlang schauen ohne einen Aussetzer. Es ist aber wie auch @nixi gesagt hat wohl Random wann der Server sich aufhängt. Kann sein an einem Tag 4 Aufnahmen gleichzeitig, dann 2 Tage später bei 2 Server weg. Quote
Siox Posted January 2, 2023 Posted January 2, 2023 Hallo zusammen, das Thema ist noch nicht durch. Auch ich kann immer wieder Hänger feststellen. Erst dachte ich, es liegt an EventGhost. Aber auch ohne EventGhost hängt der MediaServer immer mal wieder, was dazu führt, dass das Webinterface nicht reagiert. In Hochzeiten waren das bis zu 2 Minuten. Ich habe dann mal die Datenbanken über das Webinterface aufgeräumt. Das hat dann Wirkung gezeigt, nachdem ich den Rechner noch einmal durchgebootet habe. Trotzdem habe ich noch Hänger. Ich betreibe Server und DVBViewer auf demselben Rechner. Meine Datenbanken sollten gut gefüllt sein, weil ich dieses Konstrukt schon bestimmt 12 Jahre nutze und immer alles mitgeschleift habe. Festplatten habe ich immer wieder durch größere ersetzt. Jetzt wäre natürlich die Frage, ob bei der Menge an Videos, Bildern etc. es vielleicht im MediaServer evtl. For Schleifen existieren, die im Hauptthread des Servers laufen. Vielleicht unabsichtlich und nicht auffällig. Sobald aber die Datenmenge steigt, steigt auch die Blockade im Hauptthread, was dann zu Hängern führt. Wenn dann noch Datenbanken abgefragt und dieser Output ebenfalls mit einfließt... Vor allem, wenn der Output der Datenbanken sowas wie: "Select * from..." enthält, der dann noch zeilenweise abgearbeitet werden muss. Soll keine Schuldzuweisung sein, nur so ein Gedanke, den ich selbst schon erlebt habe. Quote
carmen.vvl Posted January 3, 2023 Posted January 3, 2023 Also bei mir gibt es (derzeit) keine 'Hänger' in der Weboberfläche des Servers mehr, leider weiß ich aber nicht mehr, wann das Problem wodurch gelöst wurde oder verschwunden ist. An Deinen Medien dürfte es aber eher nicht liegen: Quote
Siox Posted April 7, 2023 Posted April 7, 2023 Ich hänge immer noch an dem Problem. Folgendes habe ich herausgefunden. Die Hänger werden immer länger, je länger der Service läuft. Bei mir ist das aber so der Fall. Der PC mit dem Server wird automatisch, nach 2 Stunden ohne Fernbedienung, Zeitplan oder durch drücken der Powertaste an der Fernbedienung in den Ruhezustand versetzt. Per Fernbedienung wird er auch wieder aufgeweckt. Einmal im Monat wird der PC nicht in den Ruhezustand versetzt, sondern durchgebootet und dann in den Ruhezustand versetzt. Das wird von EventGhost automatisch erledigt. Und hier merke ich, dass dies auch Auswirkungen auf die Reaktion des Mediaserver hat. Je länger nicht durchgebootet wird, umso länger hängt der Service. Was mir beim Server noch aufgefallen ist. Die Aufgabe "Video-Datenbank neu aufbauen" (Version 3.2.3.0) war nach sehr vielen Stunden nicht fertig geworden. Ich hatte die Vermutung, dass diese sich komplett aufgehangen hat oder gar nicht erst gestartet ist. Ich habe dann den Rechner durchgestartet und keine Veränderung an den Medien festgestellt. Die anderen Aufgabe, wie bereinigen und löschen scheinen zu funktionieren. Danach schien auch der Server besser zu werden, aber es dauerte nicht lange, bis er wieder verzögert reagierte. Das schlimme daran ist, dass dies nicht immer so ist. Sondern immer sporadisch auftritt und dann echt bis zu 2 Minuten dauert. Mit sporadisch meine ich, wenn man die Fernbedienung in die Hand nimmt und mal so 3-4 Ordner + Unterordner durchklickt, dann bleibt es hängen. Aktuell habe ich den UPnP AV Server abgeschaltet. Und jetzt hängt der Service sehr selten und wenn dann nur so 2-3 Sekunden. Der Server läuft aber auch erst seit 1 Tage und ein paar Stunden. Bisher habe ich aber auch von EventGhost keine Timeouts mehr erhalten. Das war sonst nie der Fall. Quote
Griga Posted April 9, 2023 Posted April 9, 2023 Am 7.4.2023 um 18:19 schrieb Siox: Die Aufgabe "Video-Datenbank neu aufbauen" (Version 3.2.3.0) war nach sehr vielen Stunden nicht fertig geworden. Gibt es vielleicht Netzwerkpfade im DMS, inbesondere in den Media-Sammlungen, die nicht vorhanden sind? Windows operiert mit eklig lange Netzwerk-Timeouts. Davon sind auch API-Aufrufe betroffen, die sich auf nicht vorhandene Netzwerk-Orte beziehen. Ich habe letztlich nach einem Windows 8.1 -> Windows 10 Upgrade die Erfahrung gemacht, dass sowohl das bei der Gelegenheit aktualisierte LibreOffice als auch Wordpad mehrere Minuten brauchten, um zu starten. Nach einigen Versuchen stellte sich heraus, dass dies nur der Fall war, wenn ein anderer PC mit einer Druckerfreigabe nicht lief. Dieser (Netzwerk-)Drucker war auf dem betroffenen PC als Standarddrucker eingestellt. Offenbar wollten die dortigen Textprogramme beim Start über Windows Druckereigenschaften ermitteln, womit sie im Netzwerk-Timeout festhingen... nach Auswahl des immer vorhandenen "Microsoft Print to PDF" als Standarddrucker bestand das Problem nicht mehr. Quote
Basic.Master Posted April 10, 2023 Posted April 10, 2023 Ich bin leider ebenfalls von dem Problem betroffen, dass der DMS sich hin und wieder aufhängt. Die Web-GUI ist dann nicht mehr erreichbar (Verbindungsaufbau im Browser bricht nicht ab, er wartet aber ewig/vergebens auf eine Antwort). Die Timer-Aufnahmen, die zum Zeitpunkt des Einfrierens aktiv waren, laufen unverändert weiter, und dann auch über das eigentlich eingeplante Ende hinaus (teilweise stundenlang). Das Aufnahmelog wird dann an der Stelle einfach nicht mehr weitergeschrieben, wo er einfriert. Webstreams nehme ich übrigens keine auf und nutze auch keine Freigaben; es sind nur direkt eingebaute/angeschlossene DVB-Geräte für DVB-S(2) und DVB-T2 im Einsatz. Quote
Griga Posted April 12, 2023 Posted April 12, 2023 On 4/10/2023 at 7:46 PM, Basic.Master said: Die Web-GUI ist dann nicht mehr erreichbar (Verbindungsaufbau im Browser bricht nicht ab, er wartet aber ewig/vergebens auf eine Antwort). Die Timer-Aufnahmen, die zum Zeitpunkt des Einfrierens aktiv waren, laufen unverändert weiter, und dann auch über das eigentlich eingeplante Ende hinaus (teilweise stundenlang). Das heißt, der Haupt-Thread des Media Servers bleibt hängen. Aufnahmen werden in separaten Threads geschrieben, die zunächst nicht betroffen sind. Da im Haupt-Thread keine Botschaftsverarbeitung mehr stattfindet, bleiben jedoch die Timer-Botschaften aus, die die Aufnahme beenden würden. In solchen Fällen empfiehlt es sich im Taskmanager die CPU-Last zu überprüfen. Wenn sich der Haupt-Thread in einer Endlosschelife verfangen hat, ist i.a. ein Kern sehr hoch ausgelastet. Bei einem Deadlock (zwei Threads warten vergeblich darauf, dass der jeweils andere mit etwas fertig wird) produziert der Haupt-Thread überhaupt keine CPU-Last (aber andere vielleicht noch). im svcdebug.log nachzuschauen, was dem Festhängen vorausgegangen ist. Auch ein Blick in die Windows-Eventlogs könnte vielleicht Aufschluss über den Auslöser geben. 1 Quote
Webturtle Posted April 12, 2023 Posted April 12, 2023 (edited) Hallo, genau das was Basic.Master beschrieben hat, passiert bei mir manchmal beim DVBViewer Pro! Die Support.zip hat bisher keine Aufklärung gebracht. Beim nächsten Mal werde ich schauen, ob Grigas Tips etwas zutage fördern. Ich habe immer noch den Verdacht, daß eine große Aufnahmedatenbank mit vielen "Dateileichen", also gelöschten oder verschobenen Aufnahmen, nicht völlig unbeteiligt ist. @Griga: Kannst Du genauer angeben, worauf man achten soll? Wenn man eventvwr startet gibt es ja viele Auswahlmöglichkeiten. Viele Grüße Webturtle Edited April 12, 2023 by Webturtle Quote
HaraldL Posted April 12, 2023 Posted April 12, 2023 vor 34 Minuten schrieb Webturtle: Ich habe immer noch den Verdacht, daß eine große Aufnahmedatenbank mit vielen "Dateileichen", also gelöschten oder verschobenen Aufnahmen, nicht völlig unbeteiligt ist. Ich nicht 😉 Zumindest bei mir, mit aktuell > 3600 "Dateileichen" in der Aufnahmedatenbank (zum automatischen Deaktivieren von Autotimern bei Wiederholungen) hat sich der DMS bisher (seit ca. 2009, vor dem DMS eben der RS, von Win7 über Win8.1 bis jetzt zu Win10, und der PC läuft auch schon mal eine Woche im Stück durch) kein einziges Mal so aufgehängt. 1 Quote
Webturtle Posted April 12, 2023 Posted April 12, 2023 Hallo, @HaraldL: Danke, daß Du Deine Erfahrungen mit der Aufnahmedatenbank mitegeteilt hast. Na dann habe ich ja die Hoffnung, daß ich die Aufnahmedatenbank nicht deswegen dauern bereinigen muß. Viele Grüße Webturtle Quote
Siox Posted April 22, 2023 Posted April 22, 2023 (edited) Am 9.4.2023 um 19:35 schrieb Griga: Gibt es vielleicht Netzwerkpfade im DMS, inbesondere in den Media-Sammlungen, die nicht vorhanden sind? Windows operiert mit eklig lange Netzwerk-Timeouts. Davon sind auch API-Aufrufe betroffen, die sich auf nicht vorhandene Netzwerk-Orte beziehen. Oh man, ich habe tatsächlich im DMS einen Ordner gefunden, der nicht mehr existierte. Jetzt muss ich mal schauen. Die Deaktivierung des UPnP Servers war trotzdem eine Lösung, die keine minutenlangen Hänger mehr produzierte. Ich habe den fehlenden Ordner aus dem DMS gelöscht und den UPnP AV Server wieder Online genommen. Wenn es an dem nicht mehr existierenden Ordner liegt, wäre das Ergebnis super. Und vielleicht hätte der DMS eine neue Option den User darauf hinzuweisen. Ich werde berichten. Edit: Nö, der UPnP AV erzeugt sofort Probleme. Also habe ich ihn wieder deaktiviert. Edited April 22, 2023 by Siox Quote
Siox Posted June 23, 2023 Posted June 23, 2023 (edited) Ich konnte das Problem lösen. Auch wenn ich es nicht mehr geglaubt hätte. Und es hat tatsächlich etwas mit dem Netzwerk zu tun, aber nicht so wie man das eigentlich annehmen sollte. Es ist also nicht trivial. Ich werde das jetzt beschreiben, damit es 1. nicht untergeht und 2. mir vielleicht jemand erklären kann, was der Unterschied ist. Ich hatte als Workaround den UPnP AV Server deaktiviert. Das hat auch geholfen und zumindest die bis zu 2 Minuten dauernden Hänger beseitigt. Aber sie waren nie weg, nur deutlich kürzer. Sie waren also permanent Teil meines Fernsehgenusses. Nach einem Neustart des PC war erstmal alles gut, aber es dauerte nicht lange und dann hing wieder etwas. Die grundlegende Funktion war aber immer vorhanden. Griga hatte angedeutet, dass evtl. Pfade existieren, die nicht mehr erreichbar sind. Da hatte ich einen gefunden, das beseitigte aber nicht das Problem. Er sagte auch ich sollte mal die Windows Eventlogs anschauen. Und da hatte ich schon keine Lust mehr. Aber das ging mir alles nicht mehr aus dem Kopf. Also habe ich vor einer Woche angefangen und mir die Windows-Eventlogs angeschaut. Da sah ich zwar: "Huch, da geht aber einiges schief", aber Netzwerk war nicht dabei. Dann versuchte ich etwas, was man allgemein als try and error bezeichnet. Es war einfach eine Verzweiflungstat. Ich ging in die Media Server Konfiguration und Media-Sammlungen und sah die Ordner, die im gesamten Netzwerk freigegeben sind. Diese hatte ich manuell über \\IP-Adresse\Ordner eingebunden. Jetzt band ich diese Ordner nochmals über \\Hostname\Ordner hinzu, und zwar über das leidige Klick auf Hostname Klick auf Freigabeordner. Anschließend entfernte ich die \\IP-Adresse\Ordner. Dann klickte ich auf OK. Und bemerkte sofort einen Unterschied. Jeder Tastendruck auf die Fernbedienung wurde sofort umgesetzt. Warum? Hatte ich vielleicht einen Tippfehler im alten System. Aber diese Ordner, es sind nicht viele, hatten doch auch immer funktioniert? Am Ende habe ich den UPnP AV Server wieder aktiviert und alle anderen Optionen wie alternativen Handshake auch. Jetzt ist eine Woche vergangen und das System wird immer nur in den Ruhezustand versetzt und wieder aufgeweckt. Alle Hänger sind weg. Warum? Edited June 23, 2023 by Siox Quote
HaraldL Posted June 23, 2023 Posted June 23, 2023 Es macht für Windows (nicht für den DMS) einen Unterschied ob du einen externen Ordner über \\IP oder \\Hostname ansprichst. Per \\Hostname gilt das für Windows als "Lokales Netzwerk" also vertrauenswürdig. Per \\IP aber immer als "Internetzone" selbst wenn es eine IP aus dem lokalen Subnetz ist. Dadurch kann ggf. die Firewall oder der Virenscanner anders/strenger arbeiten. Ob dies tatsächlich die Ursache für das Verhalten bei dir ist kann ich dir nicht sagen. Aber diesen Unterschied gibt es, obwohl es ansonsten scheinbar gleich aussieht. 1 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.