Ember Media Manager 1.4.8.0 Alpha - Diskussionsthread

  • 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.

  • @DanCooper kannst du den Bug, den ich hier beschrieben hatte nachvollziehen??

    Kodi-Hardware anzeigen

    HTPC: Kodi 19.x auf Nvidia Shield 2017
    TV: LG 65SK9500, AVR: Pioneer SC-LX57, Boxen: Nubert NuLine 284 Set 7.1
    Server: OmniOSce r151024 mit Napp-it pro, SM-Board X8SI6-F, Intel Xeon L3426, 16GB ECC RAM, LSI 9211-8i & 9201-16i, nur Hitachi/HGST 7k4000, XCase-Gehäuse RM424

  • @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.

  • Ich hab auch eine Lösung zu meinem obigen Problem gefunden und auch dort gleich beschrieben.

    Kodi-Hardware anzeigen

    HTPC: Kodi 19.x auf Nvidia Shield 2017
    TV: LG 65SK9500, AVR: Pioneer SC-LX57, Boxen: Nubert NuLine 284 Set 7.1
    Server: OmniOSce r151024 mit Napp-it pro, SM-Board X8SI6-F, Intel Xeon L3426, 16GB ECC RAM, LSI 9211-8i & 9201-16i, nur Hitachi/HGST 7k4000, XCase-Gehäuse RM424

  • 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?

  • 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.

  • 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.

  • 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.

  • 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, aber die beliebige Reihenfolge wird dann auf den thumbs-Dateiname übertragen ... 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 :(
    In EMM 1.3.0.20 hat die Funktion der Extrathumbs so funktioniert wie es soll.

    Ich hoffe es gibt Abhilfe bzw. einen Workaround.

    3 Mal editiert, zuletzt von V-I-M (16. Dezember 2016 um 16:35)

  • 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 ;)

  • Servus,

    vielen Dank für die ausführliche Erläuterung.

    Das Vorgehen habe ich soweit nachvollziehen können. Allerdings hatte ich das Verhalten von EMM 1.3.x besser nachvollziehen können, beim ersten Scrapen werden alle Fanarts die mit einem Hacken versehen sind ins Extrathumbs-Verzeichnis abgelegt und nur bei einem neuen scrapen der Fanart mit erneut angehackten Fanart, werden diese dem Extrathumbs-Verzeichnis angehängt - und dies einfach nach der letzten regulären thumb#.jpg datei, also wenn thumb7.jpg schon da war dann werden die Neuen beginnend mit thumb8.jpg angehängt. Dabei wurde scheinbar vor jedem schreiben der thumbs ganz einfach nach der letzten Datei (hier in dem Beispiel: thumb7.jpg ) gesucht und es musste weder neu eingelesen werden (F5) noch hatte es eine Bedeutung, ob die thumbs durch EMM oder manuell erstellt wurden. Hat immer super funktioniert!!! 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), und da bei Ember 1.3 so langsam die Features veraltet sind, habe ich mich 1.4 zugewendet.

    Zu Deiner Vermutung mit der "beliebigen" Reihenfolge, kann ich Dir bestätigen, dass es an der Zählweise ohne führende 0 ("Null") und mehr als 9 Thumbs liegt. Und ja ich habe üblicherweise mehr als 9 Thumbs, da dies EMM 1.3 (und früher) zu meiner Anfangszeit von Ember normalerweise locker aus der Auswahl von Fanarts ins Extrathumbs-Verzeichnis abgelegt hat und ich dies dann als quasi Backup/Backdrop-Verzeichnis verwendet habe. 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!? 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. Aber so wie Du geschrieben hast, wird normalerweise max. die ersten 4 thumbs (thumb1.jpg .. thumb4.jpg) in Kodi genutzt, dementsprechend ist die Reihenfolge nei mehr als 4 Thumbs nicht unwichtig. Ach ja, in EMM 1.3 (und früher) hat das Thema Extrathumbs ganz gut funktioniert, evtl. war das Verhalten garnicht so schlecht, normalerweise scrapt man doch nur sehr selten öfters ;)

    Naja, ich werde vermutlich meine Strategie des Backups von verschiedenen Bilder (Poster, Fanarts und sonstiges) so abändern, das ich diese in ein gesondertes Verzeichnis ablege und eine kleine Auswahl (Anzahl < 9) ins Extrathumbs kopiere. 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. Vielleicht fällt Dir was ein? Mir wäre eine Rückkehr zum vorherigen Vorgehen Ember 1.3 am liebsten!

    Viele Grüße und ebenfall schöne Festtage und einen guten Rutsch!


    P.S.
    * Wann kommt das nächste Update?
    * Für was werden die extrafanarts benötigt?

    3 Mal editiert, zuletzt von V-I-M (16. Dezember 2016 um 21:18)

  • 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.

    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.

    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.

    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! 8o Das kann man aber völlig zu Recht als Bug bezeichnen, den ich in der nächsten Version fixen werde.

    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.

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

    Nope, siehe oben.

    * Wann kommt das nächste Update?

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

    * 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.

  • Klasse Arbeit die Ihr bei EMM gemacht habt.

    Ich nutze das Tool nun seit zwei Tagen und konnte ohne Probleme meine Filmdatenbank umbenennen, sortieren und Scrapen.
    Das Kodi Interface läuft auch.

    Ich nutze zwar "nur" die Standard Einstellungen, aber das reicht.

    Jetzt fehlt nur noch das automatische raus schneiden von Werbung in Filmen :D .. ;)

  • Ich habe mir vorhin mal den Genre Manager zu herzen geführt, nachdem Ich gesehen habe, dass Ich 3 Kategorien für Sci-Fi hab. (Und andere doppelte, ENg/Deu Mix,...)
    Sci-Fi mit 3 verschiedenen das "umfangreichste" Beispiel:
    Sci-Fi, Science Fiction, Science-Fiction: Will ich alle in Kodi als "Sci-Fi" stehen haben.
    Crime soll Krimi anzeigen, etc...

    Mein Vorgehen:

    Genre Manager:
    Alle Drei auf den Selben Eintrag zugewiesen -> Sci-Fi
    Rest gelöscht.
    Gespeichert -> "Alles fertig"

    Ember:
    Datenbank gesäubert, abgewartet bis die Statusleiste keine Änderung mehr anzeigte. (Kein "Alles fertig" Popup)

    Kodi:
    Datenbank aktualisiert und anschließend gesäubert.


    Die Filme werden in Ember nun richtig dargestellt, aber in Kodi immer noch nicht.


    Ich meine mich damit so nah wie möglich an das Tutorial gehalten zu haben, habe in Kodi aber keine Änderung feststellen können.
    Was mache Ich falsch?
    Oder hat Ember keine Anzeige, dass die Datenbank gesäubert wird? (Zmd. nicht durchgehend?)

  • Kodi nur zu aktualisieren hat noch nie dazu geführt, dass veränderte Daten wie Genres oder Bilder oder andere Informationen in die Kodidatenbank eingetragen wurden. Das geht bei Kodi nur über das entfernen des Films aus der Datenbank und dem Neuhinzufügen dieses Films. Oder den Film manuell auswählen und dann über das Kontextmenü diesen Film aktualisieren.

    Ansonsten hilft dir in Ember auch das "Kodi Interface" dabei, da Ember direkt an Kodi die Änderungen übermittelt und Kodi das dann in die Datenbank aufnimmt

  • @ DanCooper (1.952 Gestern, 01:07)

    Nochmals vielen Dank, für Deine sehr ausführlichen Erläuterung, ist mehr als ein dickes Kompliment wert !!!

    Ich habe das Thema Nummerierung nochmal durch exemplarische JPGs nachvollzogen, wobei das System dahinter bzw. was passiert schnell klar ist/wird:

    Windows-Explorer mit Sicht auf die thumbs#.jpg im Verzeichnis 'extrathumbs':

    Hier die Auflistung in EMM 1.4.8.0A23x64:

    Leider speichert EMM die Thumbs in der Reihenfolge, so wie sie in EMM aufgelistet ist, auch ab ... wäre echt toll, wenn dieser Bug bereinigt wird!? Momentan muss man bei mehr als 9 Thumbs eigentlich immer ein Backup auf Dateiebene machen und nach dem speichern Rückspielen, was die Arbeit mit EMM doch beeinträchtigt/verlangsamt ... und ja, eigentlich werden HEUTE max. 4 Thumbs je nach Skin verwendet, aber ...


    Noch ein Wort zu dem Arbeitsspeicherproblem. 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 - obwohl EMM 13.0.20 als x64 Variante genutzt wurde. Warum bei mit in der Alpha23 zum Teil zum kompletten Löschen des EThumbs-Verzeichnis kommt, konnte ich bisher nicht gänzlich nachvollziehen, aber ich beobachte weiter und hoffe, dass es evtl. doch irgendwie mit dem Nummerierungsproblem und dem "Abgleichproblem" von der EMM-DB und dem tatsächlichen Thumbs herkommt. Von daher, soll ich Dir nochmal einen Euro spenden, um ein neues Release zu beschleunigen ... evtl. auch zwei Euro für vor Weihnachten ... 2016 :)

    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!?

    Grüße und schöne Festtage sowie einen guten Rutsch !

    5 Mal editiert, zuletzt von V-I-M (18. Dezember 2016 um 15:06)

  • 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.

    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.

    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.

    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.

  • 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 :cursing:

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

Jetzt mitmachen!

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