Der mencoder wird vom Plugin nicht genutzt, sondern nur "cat". Der Aufruf der externremux kann also meines Erachtens nicht direkt vom Plugin kommen. Vielleicht müsstest du dich mit dem Problem an schmirl wenden.
[UPnP/DLNA] Tester gesucht für Release-Candidates des neuen UPnP-Plugins V.1.0.0
-
-
Hallo,
ich habe mir auch das Plugin nach der Anleitung von Seite 19 [UPnP/DLNA] Tester gesucht für Release-Candidates des neuen UPnP-Plugins V.1.0.0 compiliert. Das lief soweit gut durch.
Jedoch habe ich auch das Problem, dass die CPU-Last auf maximum schnell (für einen Core) und dass zwar meine 40-live Kanäle angezeigt werden, jedoch nur ein Bruchteil meiner Recordings. Anders als andere hier, habe ich trotz Satellit nur 40 Kanäle, aber 600 GB Aufnahmen. Ich weiß nicht, wo bei Aufnahmen die Grenze des Plugins erreicht wird, mit 600 GB kommt es scheinbar nicht zurecht.
VLC ist als Client unbrauchbar, er lädt die ganze Zeit nur die Liste nach. Totem funktioniert, jedoch stützt es ab, wenn man in einer Aufnahme springen will.
Braucht ihr logs, Tests oder ähnliches? Gibt es irgendwo einen Bugtracker oder wird die Entwicklung im Moment hier abgewickelt?
Grüße
MPW -
Bitte bei der Pluginhomepage deine "Bugs" einkippen. Die CPU-Last könnte eventuell durch die enorme Menge der Aufnahmen kommen, da die zum "Profilieren" einmal gelesen werden müssen. Da ich bei weitem nicht so viele Aufnahmen habe, habe ich noch keine "Lastbenchmarks" gemacht Logs wären also hilfreich.
-
Alles klar. Was für Logs möchtest du denn da haben?
Meiner Logik nach müsste sich die CPU Last aber dann irgendwann legen und das bleibt sehr lange so?
Bzgl. VLC und totem ist halt die Frage ob das Bugs in VLC un Totem sind oder ob es an dem Plugin liegt. Soll ich dafür auch Bugs anlegen?
-
Die CPU-Last könnte eventuell durch die enorme Menge der Aufnahmen kommen
??? Wir reden hier von VDR und da sind 600 GB meiner Meinung nach Peanuts und haben so gar nichts enormes an sich ... -
Das finde ich ehrlich gesagt auch. Zumal ja die Dateien nicht gehasht oder ähnliches werden. Sondern nur ein Index erzeugt wird. Das entspricht als reinem Text vllt. 10-15 KB, das ist quasi nix! Ich denke, dass es ein Bug ist.
Evtl. kann das jemand mit einem sauberen System gegenchecken? Ich hab leider derzeit kein Testsystem und an meinem Produktivsystem mag ich nicht so viel herumpfuschen.
-
Das stimmt so nicht ganz. Ich muss jede Aufnahme einmal öffnen und die ersten Bytes lesen, um herauszufinden, ob es eine H.264-Aufnahme ist oder MPEG2. Die Info-Dateien gegen keine verlässlichen Infos darüber. Das Scannen wird ja auch nur einmal gemacht und danach nicht nochmal, wenn die Aufnahme bereits in der Datenbank steht. Das Problem sollte sich also lösen, wenn alle Aufnahmen gefunden worden.
-
Verflixt, ich hab es mir zerschossen. Wollte es nochmal neu sauber installieren, da ich das vdr-plugin-upnp package und das selbst kompilierte durcheinander habe.
Und jetzt hab ich einen vdr mit 100% load aber kein upnp (zumindest laut vlc und totem).
Das syslog zeigt nix an, wo kann das klemmen, dass der http-Server nicht richtig initialisiert wird? Wo könnte ich mal reinschauen?
http://localhost:49152/ sagt "500 Internal Server Error"
/edit: Ich sehe auch gerade, dass es den Ordner, der hier im Syslog steht, gar nicht gibt:
CodeJan 31 15:16:40 Server0 vdr: [2298] UPnP#011Using /var/lib/vdr/plugins/upnp/httpdocs/ for static content delivery.
Es gibt nur http, statt httpdocs und http ist leer. Einen httpdocs gibt es unter /etc/vdr/plugins/upnp, aber der ist auch leer.
-
Das Plugin nutzt das Config-Dir, um nach statischen Dateien zu suchen. Das ist standardmäßig auf /var/lib/vdr/plugins gestellt. Dadurch, dass es seit den letzten Versionen ein gewisses Durcheinander herrscht, wo welche Dateien abzulegen sind, kann es durchaus sein, dass yavdr /etc/vdr für so etwas annimmt, ich aber noch von /var/lib ausgehe, weil der VDR mir das so mitteilt.
Kannst du eingrenzen, warum die Last so hoch ist?
-
Hallo,
wie kann ich die Last eingrenzen? Also fakt ist, der rennt jetzt 6 h und die metadata.db hat immer noch nur 100K. Es kann einfach nicht sein, dass er etwas sinnvolles tut. Da wird irgendwas hängen.
Grüße
MPW -
In der Tat. Wenn du das Plugin löschst, normalisiert sich dann die Last?
-
Ja
Wie kann man es eigentlich deaktivieren ohne es zu löschen?
-
die .so aus dem Verzeichnis entfernen oder umbennen, so dass es nicht mehr dem Namensschema entspricht, nach dem der VDR sucht.
Probier mal bitte folgendes:
- entferne mal bitte den dvbProfiler und beobachte die Last
- wenn das hilft, den recProvider entfernen und beobachten
- wenn das nicht hilft, den vdrProvider entfernen.Wenn am Ende einer der beiden Provider die Last verursacht, kann ich mir den genauer ansehen.
-
Hallo,
hab alles getestet: Es ist der recProvider. Was ja auch logisch ist, denn meine Kanäle hatte ich ja, als ich es noch nicht kaputt gemacht hatte
Grüße
MPW -
Bei mir isses allerdings immer noch die Kanalliste.... und wenn ich mir das so ansehe das es mit vielen Aufnahmen aehnlich ist dann waere eine Begrenzung sinnvoll
so das ich sagen nur die ersten 500 kaenele oder 100 aufnahmen....Gruss Gerd
-
Ich könnte es nachvollziehen, wenn proprietäre oder schlecht programmierte Clients nicht mit so einer Menge an Daten zurecht kommen. Aber letztendlich ist dlna doch nur ein bisschen http mit Links drin. Es kann nicht so aufwendig sein, da sagen wir 5000 Kanäle und 5000 Aufzeichnungen in ein http-File zu packen.
Ich vermute, dass es ein Zeichensatzproblem oder ähnliches ist. Ich hab mir gestern mal den Quellcode angesehen, aber leider noch keinen Anhaltspunkt gefunden. Man muss es halt mal debuggen. Die Umgebung dafür habe ich derzeit nicht eingerichtet, aber ich denke methodus wird den Fehler per Debugger schon finden.
-
Ich könnte es nachvollziehen, wenn proprietäre oder schlecht programmierte Clients nicht mit so einer Menge an Daten zurecht kommen. Aber letztendlich ist dlna doch nur ein bisschen http mit Links drin. Es kann nicht so aufwendig sein, da sagen wir 5000 Kanäle und 5000 Aufzeichnungen in ein http-File zu packen.
Ich vermute, dass es ein Zeichensatzproblem oder ähnliches ist. Ich hab mir gestern mal den Quellcode angesehen, aber leider noch keinen Anhaltspunkt gefunden. Man muss es halt mal debuggen. Die Umgebung dafür habe ich derzeit nicht eingerichtet, aber ich denke methodus wird den Fehler per Debugger schon finden.
Wie gut, daß zumindest das Problem lokalisiert wurde, Respekt! Auf die Einfache Idee mal die Subplugins einzeln heraus zu nehmen ist bisher keiner gekommen...
Lucian
-
Wie gut, daß zumindest das Problem lokalisiert wurde, Respekt! Auf die Einfache Idee mal die Subplugins einzeln heraus zu nehmen ist bisher keiner gekommen...
Lucian
Es war methodus' Idee
Und wenn man genauer darüber nachdenkt, dass nämlich das Problem scheinbar von zu viel Input - entweder zu viele Sender oder zu viele Aufnahmen - verursacht wird. Ist es nur logisch anzunehmen, dass das Problem in einer der verwendeten Libs liegt.
-
Hi,
ich habe Methodus im Bugtracker einen Patch der die Makefiles an das neue Muster welches mit vdr-1.7.36 endlich stabilisiert wurde, hinterlegt. Bitte testet die Git-Version mit diesem Patch...
Ciao, Lucian
-
Danke.
Ab kommender Woche sollte sich wieder Zeit finden, Bugs zu beheben und Patches einzupflegen. Ich melde mich bei dir, wenn ich Probleme hab.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!