Jump to content

Ladezeiten beim Media Server Webinterface


Buoysel

Recommended Posts

Seit einigen Tagen benutze ich den Media Server. Vorher hatte ich jahrelang den Recording Service im Einsatz.

 

Seit dem Update habe ich folgendes Problem:

Das Webinterface reagiert oft träge, ich muss dann mehrere Sekunden warten, bevor eine Seite lädt, trotz localhost-Zugriff.

Wenn die Seite endlich geladen ist, kann ich das Webinterface für ca. 1 Minute flüssig benutzen, danach kommt es beim nächsten Zugriff wieder zu einem Hänger und das Problem wiederholt sich.

Es passiert auch jedes Mal, wenn ich nach längerer Zeit wieder auf das Webinterface zugreife.

 

Woran kann das liegen?

Edited by Buoysel
Link to comment

Hinzu kommt, dass der Media Server scheinbar mein NAS mit hunderten Samba-Gastlogin-Anfragen spammt, was ich mir auch noch nicht erklären kann.

Edit: Das liegt an älteren Aufnahmen in der SvcDatabase.db3... Kann es sein, dass die Netzwerkverbindungen zum NAS durchgehend geöffnet bleiben? Mit smbstatus kriege ich ne Liste hunderter Einträge, die nie verschwinden.

 

Das Webinterface-Ladezeitenproblem ändert sich mit neuer Datenbank nicht.

Edited by Buoysel
Link to comment

Wenn der DMS auf Aufnahmen zugreift, ist für ihn transparent, ob sie auf der lokalen Platte oder auf einem NAS liegen. Er benutzt in beiden Fällen das selbe Windows API für Dateizugriffe und hat deshalb mit Netzwerkverbindungen zum NAS nichts am Hut.

 

Kannst du orten, aus welchem Anlass es zu den Problemen kommt? Bei einer Datenbank-Aktualisierung? Beim Aufruf der Seite "Aufnahmen"? Oder generell nach dem Start des DMS? Ein Blick ins svcdebug.log wäre vielleicht nicht schlecht.

Link to comment

In der svcdebug.log steht nichts während der Hänger.

Selbst wenn ich im Windows-Geräte-Manager die Netzwerkkarte oder die DVBSky-Karte deaktiviere, und ich den Webservice per http://localhost:1234/a/ aufrufe, ist sogar die 404-Not-Found-Seite von dem Ladezeitenproblem betroffen. Nicht bei jedem Aufruf, aber schon so ca. ein Mal pro Minute, also wie oben beschrieben.

Ich habe verschiedene Browser ausprobiert (Firefox, Firefox im Safe-Mode und Vivaldi ohne Addons) und bei allen passierte es. Aber nur beim Media Server, bei einem anderen lokalen Webserver passiert es nicht.

 

Dann habe ich testweise die Benutzerauthentifizierung in den Einstellungen vom Media Server deaktiviert.

Damit ist das Problem zu meiner Überraschung verschwunden und es gibt keine Hänger mehr.

Jedoch möchte ich auf die Benutzerauthentifizierung nicht so gerne verzichten.

Beim Reaktivieren der Benutzerauthentifizierung ist das Problem sofort wieder da.

 

(Das Problem mit dem NAS-Gast-Account-Spam habe ich inzwischen behoben, lag daran, dass der Service nicht unter meinem User-Account lief.)

Edited by Buoysel
Link to comment
9 hours ago, Buoysel said:

Dann habe ich testweise die Benutzerauthentifizierung in den Einstellungen vom Media Server deaktiviert.

Damit ist das Problem zu meiner Überraschung verschwunden und es gibt keine Hänger mehr.

 

Dann finden sich vielleicht in der Datei svcusers.log (gleicher Ort wie svcdebug.log) weitere Hinweise. Dort protokolliert der DMS die Versuche, sich mit Username und Passwort anzumelden, und ob sie erfolgreich waren. Es gibt einen Schutz gegen Brute Force-Angriffe auf das Passwort, der zu Verzögerungen führen kann.

 

Link to comment

Während der Hänger gibt es auch in der svcusers.log keine weiteren Einträge. Es gibt nach der ersten Anmeldung keine weiteren Login-Versuche, also auch keine, die fehlschlagen. Trotzdem hängt der Webservice immer wieder, solange die Benutzerauthentifizierung aktiv ist. Woran kann das liegen und bin ich der einzige, dem das auffällt? ?

Edited by Buoysel
Link to comment

Hmm, ich kann das reproduzieren. Merkwürdig. Der Passwort-Mechanismus wurde früher ausgiebig getestet - dabei ist mir das nie aufgefallen - und seitdem nicht geändert.

 

Soweit ich bislang feststellen konnte, hat es etwas damit zu tun, dass die vom DMS verwendete Netzwerkbibliothek die Authentifizierung in gewissen Abständen ändert, um ein Abhören der Kommunikation durch einen Angreifer zu erschweren (genauer gesagt das Nonce, siehe hier). Es hat zur Folge, dass der Browser bei einer Anforderung mit den zuvor von ihm verwendeten Daten erst mal scheitert, den Statuscode 401 Unauthorized zurückerhält, zusammen mit einem neuen Nonce, und er es noch mal probieren darf.

 

Warum es dabei die Verzögerung gibt, weiß ich noch nicht. Bislang sieht es für mich so aus, als ob sie im Browser entsteht. Ich bleibe dran...

 

  • Like 1
Link to comment

P.S. Hab's gefunden. :)Im nächsten Release wird das behoben sein. Bis dahin kannst du den folgenden Workaround benutzen:

  • Stoppe den DMS
  • Öffne die Datei service.xml im Unterordner config des Konfigurationsverzeichnisses mit einem Texteditor.
  • Ergänze in der Section WebGeneral die Zeile <entry name="AuthFailureDelay">0</entry>
  • Speichern und DMS neu starten.
  • Like 1
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...