Jump to content

Webinterface tot


DigiAndi

Recommended Posts

Hallo,

 

ich nutze seit ein paar Wochen den Media Server V2.1.6.1 auf einem Rechner mit Windows 10 Pro. Der Service läuft wie gewohnt super stabil und zuverlässig.

Einziges Problem: Das Webinterface war jetzt bereits 2x nicht mehr aufrufbar. Benutzername und Passwort werden abgefragt, doch dann passiert nichts mehr. Die Seite bleibt leer, der Browser scheint diese weiterhin zu laden und es erscheint auch keine Fehlermeldung. Welchen Browser man nutzt, ist egal. Der Service und die programmierten Timer an sich laufen weiterhin problemlos.

Startet man den Service neu, ist auch das Webinterface wieder da. Das hatte ich jetzt schon zwei Mal.

 

Gibt es dafür eine Lösung? Kann ich irgendwelche Logfiles posten, die helfen?

 

Schöne Grüße

Andreas

Link to comment
48 minutes ago, DigiAndi said:

Das Webinterface war jetzt bereits 2x nicht mehr aufrufbar.

 

Von wo aus? Auch nicht auf dem Server PC?

 

50 minutes ago, DigiAndi said:

Kann ich irgendwelche Logfiles posten, die helfen?

 

support.zip

Link to comment

  

3 hours ago, Griga said:

 

Von wo aus? Auch nicht auf dem Server PC?

 

Egal von wo, sowohl von anderen Rechnern aus als auch an dem Rechner, auf dem der Media Server läuft.

 

  

3 hours ago, Griga said:

 

Danke! Ergebnis im Anhang.

support.zip

Edited by DigiAndi
Link to comment

Wie du schon hier berichtet hast, nimmst du massenweise auf - inzwischen mit TBS Tunern. Und die Probleme mit dem Webinterface entstehen offenbar dadurch, dass der Zugriff an einem vermeintlichen oder tatsächlichen Mangel an Arbeitsspeicher scheitert. Durchsuche das svcdebug.log nach dem Begriff "Arbeitsspeicher" und siehe selbst... ob ein Zusammenhang mit den zahlreichen gleichzeitig laufenden Aufnahmen besteht, bleibt zu untersuchen.

 

Kontrolliere erst mal im Taskmanager, wieviel Arbeitsspeicher der DMS tatsächlich im laufenden Betrieb belegt, ob die Menge mit der Zeit ständig anwächst und irgendwann an die Decke stößt - der DMS ist auf 2 GB beschränkt, weil er erstens eine 32-Bit-Anwendung ist und wir zweitens vorsichtshalber das "Large Address Awareness" Flag nicht gesetzt haben, das unter 64-Bit-Windows den Adressraum auf 4 GB erweitern würde, was aber unter bestimmten Umständen zu Problemen führen könnte.

 

Link to comment

Das hilft doch schon mal sehr weiter! Dann werde ich es wohl so machen müssen, dass ich den Dienst regelmäßig neustarte. Zwar nicht schön, aber ist dann halt so.

Danke auf jeden Fall!

Link to comment

Bitte erst mal das Problem wie emfohlen näher untersuchen! Es auf sich beruhen zu lassen hilft niemand weiter. Die Meldung "Zu wenig Arbeitsspeicher" könnte auch bei ausreichendem Speicher durch einen Programmfehler entstehen.

 

Angenommen, der DMS braucht bei deiner Nutzungsweise tatsächlich so viel Speicher, und es handelt sich nicht um ein Memory Leak (d.h. einen Programmfehler, der ständig zusätzlichen Speicher beansprucht, ohne ihn wieder freizugeben), könnte man auch das "Large Address Awareness" Flag setzen. Beim DVBViewer Pro  ist das schon seit geraumer Zeit der Fall, weil die Wiedergabe von UHD das erfordert, und es hat sich bislang nicht als nachteilig herausgestellt.

 

Beim DMS haben wir das Flag nicht gesetzt, um ein unnötiges Risiko zu vermeiden, auch wenn es nur klein ist, weil wir uns nicht vorstellen konnten, dass er mehr als 2 GB Adressraum brauchen könnte. Das ließe sich jedoch leicht ändern.

 

Link to comment

OK, ich verstehe. Dann beobachte ich das in den kommenden Tagen. Ich kann schonmal sagen, dass aus anfangs 615 MB Arbeitsspeicherbelegung nach sieben Stunden Betrieb 730 MB geworden sind. Ich melde mich die nächsten Tag nochmal mit "Zwischenständen".

Link to comment

Ich habe inzwischen untersucht, ob der Recorder ein Speicherleck aufweist, indem ich einen Programmteil aktiviert habe, der dann beim Beenden des DMS Alarm schlägt. Er hatte nach Testaufnahmen jedoch nichts zu bemängeln...

 

Link to comment

So, seit gerade eben geht das Webinterface wieder nicht mehr. Sieht jetzt so aus:

 

grafik.png.bf3edb0bd2c48463b3a0818a0a59b20c.png


Interessant ist, dass sich der Dienst jetzt beim Versuch, ihn zu Beenden, nicht beenden lies. Auch die Task lies sich erst nach meheren Minuten beenden. Die Prozessorauslastung war dabei gering. Ich habe nochmal eine support.zip angehängt, falls das was hilft.

 

Mich wundert auch, dass der Zeitraum, bis das Webinterface nicht mehr funktioniert, jetzt so gering geworden ist. Beim ersten Mal lief der Dienst sicherlich 10 oder 12 Tage ohne Probleme. Jetzt ist es gerade mal ein Tag.

 

Hintergrund: Ich habe so einen Rechner schon seit ein paar Jahren laufen. Bis vor ein paar Wochen noch mit dem alten Recording Service. Jetzt habe ich die Hardware gewechselt und bin mit dem neuen Rechner auf den Media Server umgestiegen. Auf dem alten Rechner hatte ich den Recording Service auch jeden Tag einmal neugestartet, da ich anfangs (vor Jahren) auch das Problem hatte, dass er nach längerer Laufzeit nicht mehr funktionierte (was genau war, weiß ich nicht mehr). Auf das Problem mit dem Webinterface bin ich jetzt auch nur gestoßen, da ich sehen wollte, ob der neue Media Server auch ohne diesen Neustart (der natürlich eine kurze Unterbrechung in die Aufnahmen bringt) dauerhaft läuft.

support.zip

Edited by DigiAndi
Link to comment

Das svcdebug.log sagt, dass du den DMS heute um 08:08:10 gestartet hast. Dann wurden zügig im Abstand von jeweils einer Sekunde Aufnahmen gestartet. Alles Radiosender vom selben Transponder. Um 08:09:24 liefen 46 Aufnahmen. Und da bricht das Log ab. Ohne Meldungen über zu wenig Arbeitsspeicher oder Einträge für ein ordnungsgemäßes Beenden. Sowas passiert, wenn das svcdebug.log während des laufenden Betriebs in die support.zip kopiert oder der DMS mit Gewalt abgeschossen wird.

 

Zu welchem Zeitpunkt gehört der obige Screenshot? Er zeigt, dass fast schon der gesamte vom DMS nutzbare Arbeitsspeicher (2 GB)  in Gebrauch ist. Der Speicherverbrauch scheint sich also tatsächlich bis zum Anschlag zu erhöhen.

 

Inzwischen habe ich eine (theoretische) Möglichkeit gefunden, wie so etwas passieren kann. Der DMS gesteht jeder Aufnahme maximal 100 MB Puffer zu, um sicherzustellen, dass keine Daten verlorengehen. Er fordet jedoch nicht pro Aufnahme pauschal 100 MB an, sondern nur so viel, wie tatsächlich gebraucht wird, bei Radioaufnahmen in 24 kb- und bei TV in 512 kb-Portionen. Normalerweise sollten zwei bis drei Puffer dieser Größe reichen.

 

Wenn der Recorder jedoch aus irgendeinem Grund die eintreffenden Daten nicht schnell genug auf die Festplatte wegschreiben kann, erhöht er die Anzahl Puffer immer weiter, bis sie in ihrer Summe den Maximalwert 100 MB erreichen. Das wären bei einer Radioaufnahme ca. 100.000 / 24 = 4167 Puffer mit jeweils 24 kb in der Warteschlange. Und das bei 46 gleichzeitigen Aufnahmen... kannst du dir selbst ausrechnen. Da kommt man mit 2 GB nicht mehr hin.

 

Zudem gibt es bei maximaler Puffernutzung Datenverluste, weil der Recorder eintreffende Daten verwerfen muss. Das wird jedoch nirgendwo angezeigt oder geloggt (werde ich ändern). Die Aufnahmen sind dann zumindest teilweise kaputt.

 

Die maximale (kumulative) Puffergröße pro Aufnahme kann man einstellen. Dazu den DMS stoppen, DMSTweaker.bat (siehe Programmverzeichnis) starten, im Tweaker die Einstellung "Maximale Größe des Aufnahme-Puffers" suchen und z.B. von 100 auf 10 MB ändern. Das würde in dem obigen Szenario den Speicherüberlauf verhindern. Es löst jedoch nicht das Problem, dass der DMS die eintreffenden Daten nicht oder nicht schnell genug los wird (falls das bei dir vorliegt), sondern verschärft es noch.

 

Schau erst mal, ob du damit weiterkommst. Notfalls kann ich dir eine Version mit zusätzlichem Logging zur Verfügung stellen, die Aufschluss darüber gibt, ob ein derartiges Problem vorliegt.

 

Link to comment
1 hour ago, Griga said:

Das svcdebug.log sagt, dass du den DMS heute um 08:08:10 gestartet hast. Dann wurden zügig im Abstand von jeweils einer Sekunde Aufnahmen gestartet. Alles Radiosender vom selben Transponder. Um 08:09:24 liefen 46 Aufnahmen. Und da bricht das Log ab. Ohne Meldungen über zu wenig Arbeitsspeicher oder Einträge für ein ordnungsgemäßes Beenden. Sowas passiert, wenn das svcdebug.log während des laufenden Betriebs in die support.zip kopiert oder der DMS mit Gewalt abgeschossen wird.

 

Sorry, das hätte ich dazuschreiben sollen. Ich hatte den Dienst mit Gewalt beendet, da er sich nicht beenden lies. Daher der Abbruch im Log.

Der Screenshot ist von vor diesem Beenden. In diesem Zustand ging das Webinterface nicht mehr.

 

1 hour ago, Griga said:

Die maximale (kumulative) Puffergröße pro Aufnahme kann man einstellen. Dazu den DMS stoppen, DMSTweaker.bat (siehe Programmverzeichnis) starten, im Tweaker die Einstellung "Maximale Größe des Aufnahme-Puffers" suchen und z.B. von 100 auf 10 MB ändern. Das würde in dem obigen Szenario den Speicherüberlauf verhindern. Es löst jedoch nicht das Problem, dass der DMS die eintreffenden Daten nicht oder nicht schnell genug los wird (falls das bei dir vorliegt), sondern verschärft es noch.

 

Ich habe die Einstellung angepasst und beobachte, was passiert.

Wenn die Daten nicht schnell genug weggeschrieben werden können, müsste das ja Fehler in den Aufnahmen verursachen, oder? Das wäre mir aber schon aufgefallen, daher wundert mich das. Im Normalzustand laufen übrigens 86 Aufnahmen. Bisher alles fehlerfrei, sowohl mit dem alten Rechner und dem Recording Service als auch jetzt mit dem neuen Rechner.

Edited by DigiAndi
Link to comment
59 minutes ago, DigiAndi said:

Wenn die Daten nicht schnell genug weggeschrieben werden können, müsste das ja Fehler in den Aufnahmen verursachen, oder?

 

Allerdings. Da fehlen dann Stücke. Bei reinen Audioaufnahmen merkt man es jedoch womöglich nur, wenn man konzentriert zuhört.

 

1 hour ago, DigiAndi said:

Im Normalzustand laufen übrigens 86 Aufnahmen. Bisher alles fehlerfrei

 

Es könnte situationsabhängig eng werden. Bei 86 Dateien, die gleichzeitig geschrieben werden, erreicht die Festplatte wegen starker Fragmentierung wahrscheinlich nicht ihren nominellen Datendurchsatz. Und wenn dann andere Prozesse wie der Windows-Indexdienst hinzukommen und intensiv auf der Platte herumkratzen, gibt es vielleicht einen Stau. Für einen Speicherüberlauf würden ja schon 86 Aufnahmen reichen, die jeweils 20 MB Puffer brauchen, neben dem, was der DMS ohnehin belegt. Mit einem 10 MB Limit erhälst du dann womöglich Aufnahmefehler.

 

Mal schauen, wie es bei dir weitergeht. Für Testzwecke könntest du von mir auch eine Version mit 4 GB Adressraum erhalten, plus zusätzlichem Logging.

 

Link to comment
11 minutes ago, Griga said:

Mal schauen, wie es bei dir weitergeht. Für Testzwecke könntest du von mir auch eine Version mit 4 GB Adressraum erhalten, plus zusätzlichem Logging.

 

Ich lasse es jetzt mal ein bisschen laufen und jage die Aufnahmen dann zum Überprüfen durch den TS Doctor.

Link to comment

Wenn bei TS-Dateien Teile nicht geschrieben werden, ist typischerweise die TS-Paketstruktur an der Stelle im Eimer, d.h. es gibt dann unvollständige Paketfragmente (bei Diskontinuitäten z.B. aufgrund von Empfangsstörungen fehlen dagegen immer ganze Pakete). Wenn sowas vorliegt, wird der TS Doctor mit Sicherheit etwas darüber erzählen...

 

Link to comment

Das ist das Problem der Aufnahmen letzten Tage. Ist nicht auszuschließen, dass eines Gewitter oder der Starkregen auch mal ein paar Ausfälle produziert hat. Naja, mal sehen, was die nächsten Tage bringen. Mir kommt auch so langsam, warum anfangs keinerlei Probleme waren: Da war die 8 TB Festplatte auch noch leer und bei weitem nicht so fragmentiert. In dem alten Rechner war nur eine 4 TB, bei der war das vermutlich alles nicht so kritisch.

 

Werden nicht schreibbare Daten, also der Pufferüberlauf, auch als Discontinuity angezeigt?

Link to comment
21 minutes ago, DigiAndi said:

Werden nicht schreibbare Daten, also der Pufferüberlauf, auch als Discontinuity angezeigt?

 

Nicht im geringsten. Und wie bereits dargelegt ergeben sich daraus Fehler, die der TS Doctor nicht nur als Diskontinuitäten, sondern noch auf andere Weise bemängeln würde. Z.B. mit corrupted packet structure, packet sync lost oder so.

 

Was mir gerade einfällt: Ein (On Access-)Virenwächter, der meint, alles mitlesen und auf verdächtige Signaturen überprüfen zu müssen, kann Festplatten I/O erheblich aufhalten. Falls möglich, würde ich ihn so konfigurieren, dass er seine Finger von .ts Dateien lässt.

 

Link to comment
  • 2 weeks later...

Soooo... ich denke, das Problem ist vom Tisch. Im Endeffekt war es die von mir verwendete Festplatte, die ich überfordert habe - eine 8 TB Segate mit SMR. Deshalb lief die auch zunächst einwandfrei und erst am Ende, als sie dann recht voll war, gingen die Probleme los. Die Platte ist dann so fragmentiert, dass sie nicht mehr mit dem Wegschreiben der Daten nachkommt, geschuldet der SMR-Technik. Dadurch liefen dann die Aufnahmepuffer voll, die Auslastung im Arbeitsspeicher stieß an die Grenze und das Webinterface ging deshalb nicht mehr.

 

Lösung: Ich habe jetzt zwei Festplatten rein, die eigentlich für Videoüberwachung gedacht sind und mit CMR-Technik arbeiten. Einerseits verteilt sich so die Last und andererseits sollten diese Platten mit den vielen Aufnahmen auch zurecht kommen.

 

Ich kann sagen: Again what learned about Festplatten und Arbeitsspeicher. ?

Danke für den super Support!

Edited by DigiAndi
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...