Einlesen extrem langsam je mehr Files in der Queue sind

  • Hallo zusammen,

    natürlich dauern 5000 Files länger als 10 ... das mein ich aber nicht mit dem Betreff. Wenn ich die in einem Ordner packe und dann "Datenbank aktualisieren" drücke wird etwa je 2 Minuten (!) ein Ordner erstellt. Knapp 5min hab ich abgebrochen.

    Da ich mich an EMM nur die DB interessiert - da ein Eintragen ohne Dateinamen leider nicht möglich ist - hab ich 4800x Dateien mit 0-Byte erstellt. Dateiname = imdb .mkv

    Jetzt packe ich 5 MKVs in den Ordner - Starte - > sofort fertig.
    100 MKVs = zusammen ca. 20sek. = 5/Sek
    177 MKVs = zusammen ca. 70sek = 2,5/Sek
    221 MKVs = ca. 125sek = 1,7/Sek
    Und so geht das weiter. Je mehr neue Dateien desto länger dauert die Verarbeitung je File. Ich lag zuletzt bei ca. 133 Files - mit dem verschieben usw. ist das die effektivste Menge.

    Vermutlich wird ja noch versucht die Meta-Daten zu ziehen - klar - aber das sollte bei 5 Files auch nur 5x so lange dauern.

    Mir scheint als wäre die Abarbeitungsqueue hier überlastet - aber einer Queue ist es eigentlich egal ob da 10 oder 100 Files drin sind. Wird strikt abgearbeitet. Vielleicht mit dem Übertrag der DB was nicht ok?

    Ganz interessant: Ich packe 133 Files in den Ordner - Drücke auf Aktualisieren und schiebe kurz vor ende noch mal 133 Files in den Ordner - während der eine Prozess noch läuft (also um das nächste "aktualisieren" drücken schon vorzubereiten). FATAL. Hab jetzt ca. 3min gewartet bis ich wieder auf aktualisieren drücken konnte (also die neuen 133 Files wurde natürlich nicht bearbeitet - klar - waren ja nicht in der queue). EMM reagiert also extrem sensible auf neue Dateien während des Aktualisierungsprozess.

    Hat für mich den Anschein als wäre hier beim Aktualisieren irgendwo ein Fehler im Tool?
    Ich nutze die Karnevalsedition - 1.11.1 64Bit.

    Grüße
    Wulfman

  • In Ember gibt's bis auf sehr wenige Bereiche keine Queues oder Multitasking. Es gibt nur Backgroundworker, die verhindern, dass das GUI bei längeren Prozessen trotzdem noch reagiert und Windows nicht meint, dass sich die Software nicht mehr "meldet". Deshalb wird beim DB Update und Scrapen so gut wie jeder Button deaktiviert, damit man den selben Backgroundworker nicht zweimal starten kann (was zum Crash führen würde). Die Software ist mittlerweile über 12 Jahre alt und hat ein komplettes Rework dringend nötig. Das ist mit Ember 3.0 auch geplant, aber noch in weiter ferne. Erstmal soll die aktuelle Code-Basis als Version 2.0 stable ein Ende an Änderungen haben.

    wird etwa je 2 Minuten (!) ein Ordner erstellt

    Anhand dieser Aussage gehe ich davon aus, dass du mehrere Filme in einem Ordner hast und diese vor dem Einlesen in eigene Ordner verschieben lässt; entweder weil du diese Option aktiviert hast oder du in der Quelle "jeder Film in eigenem Ordner" eingestellt hast und Ember Filme direkt in der Quelle findet. In der Tat scheint es da einen Abgleich zu geben, der bei einer höheren Anzahl Filme immer in ein Timeout läuft... danke für den Hinweis! Ich werde versuchen, das Problem in der nächsten Version zu fixen.

    Ich habe testweise 4100 Videos mit 0 Bytes erstellt und diese werden ohne Verschieben in ca. 80 Sekunden eingelesen. Wenn das Verschieben aktiviert ist wird bei mir ebenfalls nur alle 2 Minuten ein Ordner erstellt. Ich denke das ist einfach das automatische Timeout-Limit der Funktion, die Dateien gegeneinander überprüft. Mir ist das Problem nie aufgefallen (und soweit ich weiss auch nie gemeltet worden), da ich neue Filme immer in eigenen Ordnern in die Quelle verschiebe und wenn ich Filme direkt in der Quelle liegen hatte waren das höchstens 2-3 Stück.

  • So, kleines Update:
    Hab die Prozedur nun etwas geändert, mit folgendem Ergebnis:

    • 4100 Files nur in die DB einlesen (ohne Bilder, NFO usw.): ca. 80 Sekunden
    • 4100 Files in einzelne Ordner verschieben und in die DB einlesen(ohne Bilder, NFO usw.): ca. 170 Sekunden

    Somit rein für's Verschieben ca. 90 Sekunden. Das klingt nun wesentlich besser als 1-2 Minuten pro Video. Ich werde noch ein paar andere Varianten testen, aber das Problem wird mit nächstem Release gefixt sein. Interessanterweise hat heute kurz nach dir jemand im Kodi Forum ebenfalls das selbe Problem erwähnt :)

  • ich finde gerne sehr spezielle Probleme ... sehr zum Leidwesen meiner Chefs ;) (Probleme die mich nichts "angehen"...)

    Super das du das so fix nachgestellt hast und ein fix unterwegs ist! Danke ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!