Ember Media Manager 1.4.8.0 Alpha - Diskussionsthread

Zitat von Stimmenhotel

Ich habe ja schon mal bezüglich eines Aufsichtlosen scrappens gefragt.
Mir ist gerade eine Idee gekommen.

Ich scrappe gerade ei n paar Filme, die Ich vorher markiert habe. (Um ggf. dem Verlust des "Neu" Zustands zu entgehen)
Modus: "Fragen wenn mehr als eine Möglichkeit"

Idee:
Die Fenster die nun für den Fall einer Mehrfachauswahl (Oder keinem Ergebnis) erscheint, könnten einen Timer im "OK (15s)", "Abbrechen (15s)", oder evtl sogar ein neuer "Gesondert Markieren (15s)" bekommen, der bei Interaktion im Fenster (Klicken, Hover, Maus-Bewegung, oder so) abgebrochen wird.
Wird der Timer nicht abgebrochen, dann erhält der Film eine neue Markierung ("Zu überprüfen", "Manuelle Eingabe erforderlich", ...).
Mit dieser Markierung überspringt Ember künftig das Scrappen des Filmes, der User könnte die Film-Liste danach Filtern und nach einem erfolgreichem scrappen wird die Markierung entfernt.

Zusätzlich wäre Möglich:
- Modus "Unbeaufsichtigt scrappen + Mehfachauswahl aufbewahren" - Ember zeigt das Fenster nie an, sondern markiert den Film gleich als Mehrfachauswahl.
- Falls der Nutzer gerade nicht weiß um welchen Film es sich handelt, hat er den Knopf "Gesondert Markieren"
- Sonstige Fehler beim Scrappen die Ember nicht zuordnen kann, aber auf einen Eingriff vom Nutzer abhängig ist, aufschieben

Wichtig wäre:
- Unabhängig von anderen Markierungen (Evtl als Symbol in der Liste zu markieren, oder Hintergrund vom Namen ändern, siehe Anfang)

Alles anzeigen

Die Vorschläge klingen gut. Es wird in Zukunft auf jeden Fall eine Markierung für Einträge geben, die nicht korrekt gescrapt worden sind.

Ich denke aber eher, dass ich beim Modus Skip - Wenn mehr als ein Resultat eine Markierung setzen werde, damit man diese nachher filtern kann. Das Problem beim Modus Nachfragen ist halt, dass man, wenn man viele Filme scrapt und nebenbei was anderes machen möchte, im dümmsten Fall die 15 Sekunden verpasst. Der Film wäre zwar nacher markiert, aber ich denke Nachfragen sollte genau das machen, was der Name sagt. Denn wenn ich das ändere, dann hat der Modus Skip eigentlich keine "Daseinsberechtigung" mehr. Ich werde es aber auf jeden Fall so umbauen, dass man beim drücken von Abbrechen den Eintrag markiert kriegt.

Zitat von Nepomuk

@DanCooper ich hab in der alpha23 noch einen Bug gefunden - in alpha22 gehts noch.
Sorry

Beim Tools/Filme-Exportieren kommt die Fehlermeldung "Der Wert darf nicht NULL sein. Parametername: path 1
Danach verabschiedet sich Ember.
Ferner sind keine Templates mehr vorhanden - Pull-down ist leer.

Übrigens, ist es möglich ein Standard-template fest auszuwählen - also im Voraus?

Btw. wäre es nicht besser, wenn zuerst das Template ausgewählt wird und dann über Button Generiere html das Modul gestartet wird.
Jetzt ist es ja so, wenn es über Tools aufgerufen wird, es gleich losrennt.

Bug ist bekannt, Workaround guckst du hier: Link

Das andere betreffend Default Template gucke ich mir an.

Zitat von jamhacker

Ich bin seit heute neu bei Ember dabei.

Scrapen und umbenennen alles kein Problem.

Nun hat mich das Kodi Interface etwas verunsichert.

Brauche ich das oder nicht? Finde leider auch im Tutorial keine allgemeine Erklärung.

Mein System:
- Filme liegen auf einem NAS
- Jeder Film im Eigenen Ordnet mit den Daten aus Ember
- Die Quelle ist weiterhin, wie früher auch schon in Kodi (auf Raspherry 3 ) eingebunden.
- Angegeben, dass die Filme im eigenen Ordner liegen.

Müsste das nicht alles so schon funktionieren oder wofür benötige ich das Interface?

Alles anzeigen

Mit dem KI kannst du jede Änderung oder auch die ganzen zusätzlichen Bilder (DiscArt, ClearLogo, ClearArt, Landscape usw., die Kodi von Haus aus nicht einliest) syncen, ohne dass du den ensprechenden Film manuell neu lädst. Der ArtworkDownloader (Kodi Addon) ist somit nicht mehr nötig. Wenn du im KI den Autosync aktiviert hast, dann wird nach dem Scrapen in Ember der Film gleich der Kodi DB hinzugefügt, ohne das du jedes mal die DB updaten musst. Macht vor allem dann Sinn, wenn du für jeden Film einen eigenen Ordner verwendest. Mit dem KI durchsucht Kodi nähmlich nur den Filmordner, nicht die ganze Quelle. Das selbe gilt für neue Episoden, dort wird dann nur der Serienordner durchsucht.

Ebenfalls kannst du so ohne Kodi-Addon die Movieset Bilder syncen.

Damit das ganze funktioniert muss einfach irgendwo Kodi laufen und der Webserver (in Kodi) aktiviert sein.

Einmal eingerichtet läuft das ganze dann schon fast automatisch.

Zitat von jamhacker

Gut also direkte Einträge in diesem Datenbank von kodi. Aber das wäre analog zu einer Bibliotheksaktualisierung? Wenn somit das Kind richtig eingerichtet ist benötige ich kein handischen Update der kodi Datenbank mehr?

Discart usw. Werden ja auch Normannen verwendet wenn der skin dies benötigt sonst nicht? Gibt es zu kodi und Ember skin Vorschläge wo die ganzen gesammelten Daten auch genutzt werden?
Nutze aeon nox zur Zeit.

Die ganze Aeon Skins können so ziemlich alle ImageTypes anzeigen. Das Landscape wird aber zum Beispiel meist nur in der speziellen Landscape-Ansicht angezeigt, das selbe gilt für die Banner. Ich selbst nutze auch irgendeinen Aeon Skin, weiss aber nicht gerade welchen.

Optimale Voraussetzung für die Verwendung des KI's:
- In Kodi ist der Webdienst aktiviert
- die Quellen sind analog zu den Quellen in Ember eingerichtet (sprich die selben, Pfad darf/kann natürlich abweichen)
- in Kodi ist bei allen Quellen der Scraper "local NFO only" eingestellt, damit Kodi nur das hinzufügt, was eine NFO (von Ember erstellt) hat (somit hast du dann 1:1 das, was du in Ember gescrapt hast)
- in der KI Host-Einstellung sind die Quellen korrekt gemappt (damit Ember weiss, welche Ember-Quelle welcher Kodi-Quelle entspricht)
- in der KI Host-Einstellung ist Autosync aktiviert (ansonsten musst du denn Sync immer manuell über das Kontextmenü starten)
- falls du die MovieSet Bilder auch syncen möchtest: in den Host-Einstellungen den Pfad mit smb://SERVER/REIGABE einrichten

Danach musst du eigentlich nur noch in Ember scrapen und dabei Kodi am laufen haben. Neue/editierte Filme und Serien/Episoden werden automatisch hinzugefügt.

Zur Zeit gibt's noch einen Bug im KI: das ganze funktioniert noch nicht bei Quellen, die in Kodi per webdav eingebunden sind. Das wird erst/hoffentlich im nächsten Release funktionieren.

Zitat von V-I-M

Servus,

zuerst vielen, vielen Dank um das Bemühen von EmberMM ... es ist ein wirklich tolles und unverzichtbares Tool!!!

Nach mehreren Jahren EmberMM 1.3.0.20 (stable) bin ich auf 1.4.8.0A23x64 umgestiegen. Soweit bin ich sehr zufrieden, insbesondere mit den neuen Features wie SETS und vollständigen Anpassung an Kodi(>=Helix), aber mit einem nervigen Bug habe ich zu kämpfen: Die Unterstützung und der Umgang mit extrathumbs!

Beschreibung:
Wie bereits im Eintrag 1.029 (27. Mai 2016) angesprochen, werden Dateien einfach gelöscht bzw. das Verhalten ist nicht wie gewollt/gedacht => laut DanCooper ein BUG. Bei mir ist das Verhalten ähnlich - Scrapen funktioniert soweit ... ABER wenn man ausserhalb von EMM die Reihenfolge der thumbs verändert, Aussortiert und/oder thumbs ergänzt, dann passiert beim nächsten Öffnen der Details (natürlich mit vorherigen aktualisieren (F5)) in EMM komisches. Zum einen ist die Reihenfolge der Bilder im Reiter "Extrathumbs" beliebig und was sehr unangenehm ist, dass beim Beenden des Editor (zurück aus der Detailansicht in die EMM-Hauptebend mit "OK") der gesamte Ordner "extrathumbs" und damit alle Bilder/thumbs gelöscht werden. Manchmal passiert es auch, dass nichts gelöscht wird, ich konnte noch nicht klären welcher Zusammenhang hier besteht. Ich habe alle möglichen Einstellungen durchprobiert (Optionen=>Allgemein=>Diverses, Filme=>Scraper - Bilder=> *, usw.), aber das Verhalten ist geblieben

Ich hoffe es gibt Abhilfe.

Erstmal besten Dank für die Spende, die soeben eingetroffen ist. Auch dir schöne Festtage und einen guten Rutsch!

Zum Thema "Bilder werden gelöscht" muss ich etwas weiter ausholen:
Früher, also bis zur Alpha Version, gab's die Einstellung Datei überschreiben. Dabei wurde beim Speichern der Bilder überprüft, ob der Dateiname schon vorhanden ist und je nach Einstellung die Datei überschrieben oder nicht. Die meisten User haben diese Option dazu benutzt, dass bereits gescrapte Bilder beim Rescrapen nicht neu heruntergeladen und überschrieben worden sind.
Dabei gab's zwei Probleme: Die User konnten die Bilder erstmal nicht mehr im Edit Dialog ändern, da die Dateien ja eben nicht mehr überschrieben wurden. Das zweite Problem war, dass wenn jemand z.B. poster.jpg und <filename>-poster.jpg als Dateiname für Poster aktiviert hatte, jedoch nur poster.jpg bereits als Datei existierte, die poster.jpg unverändert blieb, die <filename>-poster.jpg jedoch neu erstellt wurde und im dümmsten Fall ein anderes Bild war als poster.jpg.
Das erste Problem konnte so gelöst werden, dass allen Bild-Objekten ein Trigger isEdit = true/false hinzugefügt wurde, welcher beim manuellen Editieren auf true gesetzt wurde. Beim Speichern konnte nun überprüft werden, ob die bestehende Datei überschrieben werden soll oder nicht. Leider löste das das zwei Problem nicht. Ich hätte hier natürlich noch weitere Trigger und Funktionen einbauen können, die dann das bestehende Bild laden usw. usf... Wollte ich aber nicht, denn Trigger sind in der Art total beschissen, weil man bei jeder neuen Funktion daran denken und das manuell umsetzen muss. Ausserdem musste ich auch noch einen Trigger einbauen, mit dem man das Bild löschen kann, auch wenn die Option Datei überschreiben deaktiviert war. Aus diesem Grund habe ich die neue Lösung entwickelt...

Bei der neuen Lösung heisst die Option existierende behalten, was soviel wie "Datei darf überschrieben werden, soll aber, wenn von Ember erkannt und eingelesen, als Basis beim Scrapen genutzt werden". Das bedeutet also, dass ein bereits existierendes Bild eingelesen wird und beim Speichern für alle aktivierten Dateinamen genutzt wird. Somit ist erstmal das Problem mit den unterschiedlichen Bildern nach dem Speichern Geschichte. Beim Rescrapen und aktivierter Option existierende behalten wird ausserdem kein anhand der bevorzugten Einstellungen ausgewählt sondern das bestehende behalten. Das sowohl beim automatischen Scrapen wie auch im Bildauswahl-Dialog.

Unschöner Nebeneffekt 1: nach jedem Edit wird das Bild neu gespeichert, auch wenn es sich nicht verändert hat. Das spielt zwar für die meisten User keine Rolle, jedoch für die, welche Backupsoftware für ihr Archiv nutzen. Da sich jedes Mal der "bearbeitet/erstellt am" Zeitpunkt ändert hat sie Software das gefühl, die Datei wurde geändert und macht davon ein neues Backup. Dieses Problem wird aber in der nächsten oder einer der übernächsten Alphas gelöst bzw. so weit wie möglich optimiert sein.

Der zweite unschöne Nebeneffekt ist der, dass wenn Ember beim laden des Objektes aus der DB für ein Bild, Trailer oder Theme keinen Pfad kennt, das Objekt beim Speichern leer ist... und das ist der "Trigger" beim Speichern, dass das Bild entfernt wurde und alle Dateien mit aktivierten Dateinamen gelöscht werden sollen. Wenn also jemand ein Bild manuell abspeichert und in Ember den Film nicht mit F5 neu lädt (dabei wird das Verzeichnis nach allen Dateien durchsucht), dann ist das Objekt leer und die manuell erstellte Datei wird gelöscht. Wie ich diese Problem sauber löse weiss ich noch nicht genau. Es wird aber warscheinlich darauf hinauslaufen, dass ich vor dem Scrapen oder Editieren das Verzeichnis nochmals auslesen lasse und so manuell hinzugefügte Dateien erkannt werden.

Was genau das Problem mit deinen gelöschten EThumbs ist kann ich nicht sagen, wenn deine Aussage "natürlich mit vorherigen aktualisieren (F5)" zutrifft. Denn wenn die Bilder im Edit Dialog angezeigt werden, dann sollten sie auch beim Bestätigen des Dialogs in das DB-Objekt aufgenommen und danach gespeichert werden. Beim Speichern der EThumbs (und auch EFanarts) werden erstmal alle Bilder in den Speicher geladen, dann das existiernde Verzeichnis gelöscht,danach wieder neu erstellt und die Bilder neu angelegt. Ich könnte mir eigentlich höchstens vorstellen, dass irgendwo ein Speicherleck ist und die Bilder keinen Platz mehr im RAM haben und somit nicht zwischengespeichert, dafür aber trotzdem gelöscht werden. Dies sollte sich dann aber nicht nur bei EThumbs sondern auch bei anderen Bildern zeigen, aussderm werden in diesem Fall eher einfach Dateien mit 0 kB erstellt als gar keine.

Was ich auch nicht verstehe ist die Aussage "die Reihenfolge der Bilder im Reiter "Extrathumbs" ist beliebig". Beim Laden der Bilder ist keine spezielle Reihenfolge programmiert, d.h. die Bilder werden dem ABC nach geladen. Da die EThumbs immer mit thumb1.jpg, thumb2.jpg usw. benannt sind, sollte das eigentlich kein Problem sein. Das einize, was ich mir vorstellen könnte ist der Fall, wenn du mehr als 9 Bilder hast. Evtl. sortiert .NET dann so:

thumb1.jpg

thumb10.jpg

thumb11.jpg

...

thumb2.jpg

Aber wer hat schon mehr als 4 EThumbs, zeigt doch eh kein Skin mehr als 4 an

Zitat von V-I-M

es musste weder neu eingelesen werden (F5) noch hatte es eine Bedeutung, ob die thumbs durch EMM oder manuell erstellt wurden.

Grundsätzlich spielt es auch heute noch keine Rolle, ob die EThumbs manuell oder mit Ember erstellt werden. Wichtig ist nur, dass Ember mindestens eines erkannt hat und den EThumbs-Pfad in der DB hat. Ember speichert in der DB nicht die einzelnen EThumbs, sondern nur den Pfad, in dem sie liegen. Beim Laden für das Scrapen/Edit wird das gesammte EThumbs-Verzeichnis ausgelesen, sofern bereits ein Pfad in der DB ist. Es spielt dann also keine Rolle mehr, wenn du in der Zwischenzeit neue Bilder hinzugefügt hast. Wichtig ist nur, dass mindestens eines beim Einlesen des Filmes oder beim letzten mal F5 drücken vorhanden war.

Zitat von V-I-M

Leider ist EMM 1.3x64 bei mir tatsächlich in ein Speicherproblem (Arbeitsspeicher Überlauf >2GB ==> Absturtz mit entsprechender Fehlermeldung !?:-/) gelaufen (an verschiedenen x64-Rechnern mit weit mehr als 2GB Arbeitsspeicher)

Die knapp 4GB teilen sich alle laufenden x86 Programme. Es kann also schon bei 1GB Nutzung durch Ember zum Crash kommen, wenn du viele andere Programme mit Speicherhunger laufen hast. Bei x64 ist das Problem natürlich nicht so gross, da unter x64 mehr als die 4GB verwaltet werden können. Es sollten aber in der aktuellen Alpha auch alle Memoryleaks behoben sein. Zum Problem kommt es eigentlich eh fast nur im Edit Dialog, denn dort werden alle Bilder als Bitmap dargestellt, was im Normalfall ein vielfaches an Speicher des original JPG Bildes benötigt (12MB JPG => ca. 40MB Bitmap, wenn ich mich recht erinnern kann). Wenn du nun 50 EThumbs und 50 EFanarts hast, die alle im Edit Dialog aufgelistet werden müssen, dann geht irgendwann der Speicher aus.

Zitat von V-I-M

Die Nummerierung von Ember war und ist OHNE führende 0 ("null"), dementsprechend kommt es bei EMM 1.4 zwangläufig zu der "beliebigen" Reihenfolge und vermutlich kommt daher auch die Problematik mit dem Löschen des gesamten Verzeichnis bzw. dem nicht mehr schrieben!?

Die Vorgabe der EThumbs Namen habe ich aus den Kodi-Vorgaben übernommen. Die Problematik mit dem Löschen des ganzen Ordners kann ich mir nur so erklären, dass vor dem Edit keine EThums erkannt wurden (der Hacken war nicht grün) und Ember beim Speichern (ohne geladene/bekannte EThumbs) das Verzeichnis zur Bereinigung löscht. Wie gesagt werde ich das Problem warscheinlich durch vorheriges "neuladen" lösen.

Zitat von V-I-M

Allerdings habe ich gerade noch ein wenig mit den Extrathumbs und mehr als 9 thumbs gespielt, also z.B. manuell verändert, dann F5, dann in EMM die Reihenfolge geändert ... am Ende war es eine wildes durcheinander ... leider.

Die "beliebige" Reihenfolge lässt sich aber so erklären:
- du hast 10 Bilder (thumb1.jpg bis thumb10.jpg)
- beim Laden wird aus dem Bild 10 das Bild an zweiter Position (thumb1.jpg, thumb10.jpg, thumb2.jpg), das Bild 2 dann 3, das Bild 3 wird 4
- deim Speichern wird in neuer Reihenfolge gespeichert
- beim nächsten Laden wird erneut das Bild 10 (das ursprünglich mal Bild 9 war) an zweiter geladen, die anderen nachgeschoben

Resultat: bei jedem Edit fallen die Würfel neu!
Es ist also nicht beliebig sondern hat System! Das kann man aber völlig zu Recht als Bug bezeichnen, den ich in der nächsten Version fixen werde.

Zitat von V-I-M

Allerdings habe ich weiterhin das Problem bei meinem "alten" Bestand (Filme), wenn ich dort mal kurz was editieren möchte muss ich jedesmal aufpassen, dass mir das extrathumbs-Verzeichnis nicht "zerschossen" wird - leider keine elegante Lösung.

Sollte mit dem nächsten Release dann nicht mehr vorkommen.

Zitat von V-I-M

Mir wäre eine Rückkehr zum vorherigen Vorgehen Ember 1.3 am liebsten!

Nope, siehe oben.

Zitat von V-I-M

* Wann kommt das nächste Update?

Ca. warscheinlich in etwa um vor Ende Juni 2017. Spätestens, ganz sicher
Vielleicht auch schon um Ende 2016, das weiss man nie so genau...

Zitat von V-I-M

* Für was werden die extrafanarts benötigt?

Je nach Skin werden die EFanarts in so einer Art Diashow als alternative vom normalen Fanart angezeigt, wenn du in der Filmliste etwas länger auf der selben Stelle bleibst. Teilweise zeigen die Skins auch schon beim ersten "Anfahren" immer ein random Bild aus dem EFanarts-Verzeichnis.

Zitat von V-I-M

Leider speichert EMM die Thumbs in der Reihenfolge, so wie sie in EMM aufgelistet ist, auch ab

Das ist auch richtig so, nur müssten sie beim laden eben auch in der richtigen Reihenfolge geladen werden Aber der Bug wird in der nächsten Version gefixt sein.

Zitat von V-I-M

Bei EMM 13.0.20 hat das Problem erst mit der (massiven) Verwendung von 4k-Bildern bei den FanArts beim Scrapen (insbesondere bei populären Titeln) angefangen, somit scheint es sich hier tatsächlich um einen "unvorhergesehenen" Speicherüberlauf zu handeln

Die 1.3.x hatte auch noch mindestens ein fettest Memoryleak, in dem ganze Container (inkl. Bilder) für immer im Speicher verloren blieben. Die Alpha sollte keine Leaks mehr haben, das Speicherproblem kann bei sehr, sehr vielen EThumbs und EFanarts aber trotzdem noch auftreten. Ausserdem beim Rescrapen von kompletten Serien mit sehr viele Episoden. Aber zumindest der Serien-Bug wird ebenfalls inder nächsten Version behoben sein.

Zitat von V-I-M

Von daher, soll ich Dir nochmal einen Euro spenden, um ein neues Release zu beschleunigen ... evtl. auch zwei Euro für vor Weihnachten ... 2016

Naja, ich kann mir leider mit Geld nicht mehr Freizeit kaufen. Eigentlich hätte ich jetzt Urlaub, aber ich muss trotzdem noch ein zwei Tage arbeiten.

Zitat von V-I-M

Habe noch eine Anregung: In EMM 13.0.20 wurde in Edit-Modus beim Trailer-Eintrag hingewiesen, dass ein lokaler Trailer vorhanden ist ('<filename>-trailer.*'), das ist im neuen EMM leider nicht mehr so!?

Der Tab "Details" zeigt nur noch NFO Inhalte an. Ob ein lokaler Trailer vohanden ist siehst du im Tab "Trailer". Dort wird unter dem Bereich, in den eigentlich irgendwann mal die Vorschau geladen werden soll, der Pfad zum Trailerfile angezeigt.

Zitat von mam

Hmm, passend zum Fest hab ich da gerade einen nervigen DAU-Bug gefunden:

* bin aus Versehen (oder aus Schwäche) mit der Maus auf "Extra Sortierung" abgerutscht und hab da was angeklickt.
Nun sortiert er schön um, wenn man drauf klickt ändert sich der Pfeil und er sortiert umgekehrt.
Wenn man ein anderes Feld anklickt, wird danach sortiert.

Alles sehr hübsch, NUR WIE ZUM TEUFEL WERD ICH DAS WIEDER LOS UND KRIEG WIEDER DIE GEWOHNTE ALFABETISCHE SORTIERUNG ???

(PS: "Filter löschen" lacht einen nur hämisch aus, und behauptet, es gäbe gar keinen Filter...)
(PPS: auch "neu Laden kann nicht schaden" hilft nicht, er hat sich den Mist irgendwo in der Config gemerkt...)

GRRRR

Alles anzeigen

Einfach oberhalb der Liste wieder auf Titel klicken
Und Sortierung ist nicht gleich Filter
Und ja, die Sortierung merkt sich Ember