Ember Media Manager 1.4.8.0 Alpha - Diskussionsthread

Zitat von Nepomuk

Sorry, am 03.09. davor und auch noch danach war ich flach gelegen und hatte keine Möglichkeit hier zu lesen.Danach muss offensichtlich mir deine Anfrage in der schieren Masse untergegangen sein. Ich bitte dich das zu entschuldigen.

Das ist richtig. Aber auch ich warte hier noch immer auf eine Antwort von Dan, die ich ihn bereits letztes Jahr angefragt hatte.

@mam hat es dir genau richtig jetzt beschrieben, denn soweit hab ich es auch per testen rausgefunden.Das einzige was ich glaube was nicht ganz richtig ist, ist dass es nicht der Zeitpunkt des Scrapens ist, sondern der Zeitpunkt wo du in Ember den Button "Datenbank aktualisieren" drückst. Aber wie gesagt glaube - nix wisse.

Jetzt vermute ich aber, dass du deine Ember-db nochmals löschen musst und dann nochmals die Filme usw. neu einlesen musst, damit Ember dann das Feld "Hinzugefügt Datum" richtig setzt.
Oder du markierst alle Filme, Sets, Serien und entfernst (ENTF) diese in Ember und machst noch ein "Tools/Datenbank säubern" und liest dann nochmals neu ein - so musst du nicht mehr u.a. die Quellen neu eingeben.

Ist eigentlich alles richtig, was ihr hier erklärt habt. Ich denke das Problem bei @Gimegivya kommt daher, dass unter Ember 1.3.x der DateAdded Wert nicht in die NFO geschrieben worden ist. Somit wird bei Standardeinstellung Hinzugefügt Datum eben der Zeitpunkt gespeichert, an dem die Dateien in die DB gelesen werden. Somit haben alle das selbe Datum mit entsprechend abweichender Zeit.
In deinem Fall müsstest du nun alle Filme aus der DB entfernen und die Einstellung auf ctime setzen. Danach sind die Filme immerhin einigermassen sortiert. Danach würde ich wieder auf Hinzugefügt Datum umstellen, damit wieder das Datum der Aufnahme in die DB gespeichert genutzt wird. Beim Scrapen oder Editieren wird dieser Wert dann auch in die NFO geschrieben, was Ember zu einem späteren Zeitpunkt auch wieder einliest (ausser man deaktiviert das Lesen des Wertes in den Einstellungen).

Beim Einlesen selbst wird übrigens nichts an der NFO geändert, somit fehlt bei den alten Filmen immer noch der DateAdded Wert in der NFO. Als Workaround könntest Du nach der ganzen Umstellerei und neu EInlesen die Funktion Tools => Rewrite All Movie Content nutzen. Dabei wird alles, was zum Film gehört neu abgespeichert, ebenfalls alle Daten auf der DB in die NFO.

Zitat von mam

So ganz klappt das mit dem Restalkohol, bzw. dessen Abwesenheit, noch nicht wirklich, gelle ?
Da braucht man nix umstellen, denn spätere Aufnahmen kriegen ja auch automatisch ne spätere CTIME, also werden sie auch automatisch weiter "nach hinten" einsortiert.

Anders siehts aus, wenn man viele Filme schon vorhanden hat, aber öfters alte Aufnahmen durch modernere Versionen (in hoffentlich besserer Qualität) ersetzt. Damit man die immer schön "oben" angezeigt bekommt, sollte MTIME Dein Freund sein...

Ne, meine Aussage stimmt schon. Ich will neue Filme immer zuoberst, auch wenn sie schon vor Monaten erstellt worden sind. Ich lade öfters mal ältere Filme runter, die sollen dann aber nicht nach ctime oder mtime einsortiert werden, sonder das Datum kriegen, an dem ICH sie in meiner Sammlung aufgenommen habe (das selbe was @Gimegivya auch will).
Das Umschalten auf ctime habe ich in diesem Fall nur vorgeschlagen, damit @Gimegivya wenigsten einigermassen wieder eine Sortierung reinkriegt.

Zitat von Gimegivya

+
@Nepomuk + @mam
ich danke Euch für Eure Hilfe soweit.
Jetzt verstehe ich ctime und mtime.
(ich glaube <dateadded> erklärt sich aus dem Tag Namen selbst.)

Was ich nicht verstehe ist, wie speichert die alte Version EMM 1.3.0.20 die Eingangsreihenfolge in seiner Datenbank ab.
In der Version gibt es keine Option ctime und mtime.
Auch einen Tag Eintrag <dateadded> habe ich in den von der Version 1.3.0.20 geschriebenen *.nfo Dateien nicht gefunden.
(Ist in dieser Version wohl noch nicht angelegt worden.)
Wie "merkt" sich die Version 1.3.0.20 die "Hinzugefügt" Reihenfolge?
Und könnte man das irgendwie auf die Version EMM 1.4.8.0 übertragen?

Das ist vielleicht auch eine Frage an@'DanCooper'. Er kennt ja das "Innenleben" des EMM mit am besten.

Der Grund warum ich Wert auf die "Hinzufügen" Sortierung lege, liegt darIn, dass ich im Kodi die "[definition='2','1']advancedsettings[/definition].xml" modifiziert habe.
Dort werden mit unter dem Menüpunkt "Hinzugefügt" nicht nur 15 Filme angezeigt sondern alle aus meiner Sammlung, aber eben in der Reihenfolge in der ich sie im Kodi eigelesen habe. (*.nfos hergestellt mit Emm 1.3.0.20)

Das ist ein nettes Gimmick, wenn man mal stöbern möchte, wann was hinzugekommen ist.

Ich muss noch dazu sagen, dass ich noch dei Kodi Vers. 14.1 (Gotham) benutze.
Der Grund ist das Skin "Ace" von "MarcosQui", der es leider nicht mehr weiter entwickelt.
Der Skin ist elegant, dezent in den Farben und sehr übersichtlich und hell.
Es hat nicht die schrill bunte Kacheloptik vieler anderer Skins.
Ich weiß, über Geschmack lässt sich nicht streiten, und das ist gut so.
Aber deshalb nutze ich noch diese ältere Kodi Version.
Vielleicht entwickelt es ja jemand irgendwann weiter.

Ist Dan schon aus dem Urlaub zurück?
Ich hoffe er braucht nicht nochmal Urlaub vom Urlaub.

Alles anzeigen

Ember 1.3.x speichert immer den Wert "Hinzugefügt am", jedoch nur in der DB und nicht in der NFO.
Kodi importiert den Wert leider auch nicht aus der NFO, zumindest die letzten Versionen. Ich habe aber gesehen, dass man ab Kodi 17 zumindest den Wert per JSON übermitteln kann. Vielleicht haben sie es nun endlich auch eingebaut, dass der Wert ebenfalls aus der NFO gelesen wird. Leider sind die Herren bei Kodi manchmal ziemlich inkonsequent, was das Schreiben und Lesen der Daten in der NFO betrifft.

Mir fällt gerade keine Lösung ein, wie du das Datum aus der 1.3.x Datenbank nutzen könntest. Ich würde wie gesagt auf ctime umstellen, alles neu einlesen und dann wieder auf Hinzufüge-Datum wechseln. Dann hast du zumindest einigermassen eine Sortierung.

Ich nutze auch "Hinzugefügt am", sowohl in Ember wie auch in Kodi. Ich will ja sehen, was neu in meinem Archiv ist, unabhängig davon, wann der Film gerippt worden ist.

Zitat von Gimegivya

Das Datum des Filmnamen Verzeichnisses (ctime) ist ja das relevanteste Datum für die "Hinzugefügt" Option.

Nein. Ich weiss nicht ob du dich verschrieben hast, aber das Verzeichnis spielt überhaupt keine Rolle. Ember liest nur die Videodatei aus und nutzt davon ctime oder mtime, standardmässig aber wie gesagt den Zeitpunkt, an dem die Videodatei in die DB aufgenommen worden ist.

Die mtime eines Verzeichnissen ändert sich immer dann, wenn direkt innerhalb dieses Verzeichnisses etwas verändert worden ist, also z.B. wenn eine NFO erstellt oder geändert worden ist. Dieser Wert dürfte also nutzlos sein. Die ctime eines Verzeichnisses ist fast immer die selbe wie die der Videodatei selbst, ausser man hatte früher keine separaten Verzeichnisse für jeden Film und hat das irgendwann geändert. Von dem her macht das eigentlich auch nur wenig Sinn.

Ich könnte natürlich ohne Probleme auch die Daten der Verzeichnisse auslesen, welche die Videodateien beinhalten, aber ehrlich gesagt sehe ich da keinen wirklichen Vorteil gegenüber den jetzigen Lösungen.

Zitat von mam

Sachma, großer Düsenflieger,
Hast Du seit Deiner Wiederkehr noch keinen neuen Commit gemacht, um Deine eklatante Schande vor der übereilten Flucht zur Saufkur wieder wegzumachen?

Das Warten wird langsam langweilig...

Das, was da im Moment als Projekt rumliegt, ist nicht wirklich lebensfähig und irgendwann möchte ich meine Lib auch mal wieder updaten können...

Oder soll ich die schnöde Alpha-IRGENDWAS installieren, damit ich mal wieder neue Filme zu Gesicht bekomme???

Ich ignoriere jetzt mal den ersten Teil und versuche dein Problem mit VS zu lösen.
Am besten löschst Du das ganze EmberMM - [definition='1','3']Debug[/definition] - x86 Verzeichnis (mit Ausnahme des Profiles Ordners) und erstellst dann neu. Projekt bereinigen hat bei mir noch nie was gebracht bzw. weiss ich gar nicht, was VS da überhaupt macht.

Im übrigen habe ich bereits zwei neue Commits hochgeladen, einmal einen Fix für den Trakt.tv Scraper und eine Optimierung für den Fanart.tv Scraper.

Zitat von mam

Ok, back to business....
Ich hab hier mal wieder einen Bedienungsfehler, der den User allerdings zur Verzweifelung treiben kann und damit die Akzeptanz des Programmes deutlich beeinträchtigen könnte. Eine vergleichsweise kleine Änderung könnte Linderung bringen.

Guckst Du:

Da werden im Moment "nur" 3427 Filme angezeigt, obwohl da doch so fast 50% mehr sein sollten. Auch beim Durchscrollen der Liste findet man den einen oder anderen Film nicht mehr.
Was war passiert?
Der unbedarfte User ist (unbeabsichtigt) in das Suchfeld (Pfeil) geraten und hat z.B. ein Leerzeichen eingegeben. Das ist natürlich nicht sichtbar, aber es blendet sofort alle Filme OHNE Leerzeichen aus.
Man kann aber nirgends erkennen, das gerade ein Filter aktiv ist, und somit wird der User irgendwann nervös und mehr.

Also, ich würde vorschlagen, die Optik etwas zu verbessern, entweder die Zahl zu ändern ( z.B. "(3427 von 5903)") oder das Eingabefeld für die Suche optisch hervorzuheben sobald irgendein Zeichen drin ist (oder den Text "Suchfilter aktiv" irgendwo hinzupappen).

Übrigens: bei den TV Shows ist das ebenfalls etwas verwirrend (201/7737) bedeutet 201 Shows mit 7737 Episoden, kann aber auch als 201 von 7737 Shows gelesen werden. Vielleicht noch ein S und E anhängen, um die "Einheit" klar zu machen?

Alles anzeigen

Ich stimme dir zu, es ist in diesem Fall nicht ersichtlich, dass im Suchfeld etwas eingetragen ist. Mein Vorschlag: ist werde dort als "Wasserzeichen" die Tastenkombi für das Suchfeld eintragen. Wenn das Wasserzeichen angezeigt wird, dann ist das Feld leer, ansonsten nicht. Betreffend aller anderen Filter schau ich mal, ob ich den "Titel" des Filterbereicht farblich kennzeichnen kann bzw. Filters (enabled) oder sowas hinschreibe.

3427 von 5903 möchte ich hingegen nicht einblenden, aus zwei Gründen:
- die Tabs werden unnötig breit, vor allem wenn man noch Cutom Tabs eingeblendet hat
- aktuell wird einfach die Anzahl Zeilen in der Liste gezählt. Wenn ich jetzt 3427 von 5903 anzeigen lassen würde, dann müsste ich jedes mal eine DB Abfrage machen, um die Gesamtsumme zu ermitteln.

Aus letzterem Grund wird auch die Anzahl Episoden nie angepasst, egal ob die Serien gefilter sind oder nicht. Ich müsste dort immer alle Serien ID's der aktuellen Liste auslesen und einen DB Abruf dazu generieren (der ellenlang werden würde). Dein Vorschlag mit S bzw. E ist eigentlich ganz gut, guck ich mir mal an. Vielleicht entferne ich die Anzahl Episoden auch einfach.

@mam

Ich hab jetzt erstmal folgendes geändert:
- statt Ctrl + S wird jetzt Ctrl + F (Find, wie ansonsten auch üblich) verwendet
- die Textbox hat nun ein Wasserzeichen wenn nichts eingetragen ist
- der Titel der Filterbox heisst nun Filters (Active) bzw. Filters (Inactiv) (bezieht sich nur auf angewendete Filter inkl. Suchtext, nicht auf die Spezialsortierungen)

Kann sich der Herr mit dieser Lösung abfinden?

Zitat von Nepomuk

WOW, eine versteckte/nicht dokumentierte Funktion.

Nicht dokumentiert? Kann doch fast nicht sein ***hust***

Zitat von Nepomuk

Nee, muss ich nicht machen, da das Wasserzeichen direkt angezeigt wird. Wer das nicht versteht, versteht auch mein Tutorial nicht.
Übrigens, Ctrl + F ohne die Leerzeichen Ctrl+F - wäre es üblich und in Ember bisher auch so geschrieben..

Hab's geändert, danke für den Hinweis.

Zitat von mam

Jojo, Hauptsache IRGENDWAS ist erkennbar und Nepomuk kann seine Wiki erweitern
Übrigens: man muß nicht immer für jeden Mist die Datenbank quälen. Die Designer der Programmiersprachen haben zu diesem Zweck eine tolle Erfindung gemacht und eingebaut: LOKALE VARIABLEN!
Da kann man dann EINMAL sonne Abfrage machen und sich darin das Ergebnis merken! Und da Ember ja am Besten weis, wann Änderungen vorgenommen werden, die die Gesamtzahl betreffen könnten, kann man noch ein Flag mitführen um anzuzeigen, dass ein Update nötig ist. So könnte die intelligente Get Funktion dieser Klasse entscheiden, ob sie den gecachten Wert sofort zurückliefert, oder erst ein Update der Datenbank einholt, dieses cached und das Flag zurücksetzt...

(nochne DAU Frage: ist davon schon irgendwas committed? hier kam heute morgen, wie immer, nix an. Ich könnte diesen GIT Dreck auf den Mond schiessen (und scheine damit nicht alleine zu sein, derPate war ebenfalls böse am Fluchen über das Zeuch...)

(DAU Frage #2: eigentlich will ich ja nur ne 64Bit Version von Ember machen und testen. Builden lässt sie sich auch, aber beim Start fliegt sie auf die Nase, da die Module in .\packages nun nicht wirklich 64bit tauglich sind. Ist das Absicht, oder sollen wir mal einen Ordner packages64 in Erwägung ziehen und mit Inhalt füllen ? ? ?)

Ja, lokale Variablen sind toll, nützen im Falle der Anzahl Episoden bei gefilterten Serien genau gar nichts. Ausserdem wäre es selbst bei Filmen viel zu kompliziert und umständlich, das Hinzufügen und Entfernen immer sauber zu tracken. Bei den Episoden ist mir aber gerade in den Sinn gekommen, dass ich pro Serie die Anzahl lokaler Episoden bereits im View berechnen lasse und diese eigentlich nur noch zusammengezählt werden müssen. Ich denke da wird's gleich mal eine Änderung für geben.

Die letzten Änderungen sind Commited, siehe hier: Link

Die Packages sind alle x64 tauglich. Das einzige, was nicht x64 tauglich ist, ist das VLC Addon. Dort müsste man immer VLC als x86 oder x64 installieren, damit Ember nacher lauffähig ist. Das war auch der Grund, wieso es keine x64 Version von Ember gibt.
Nun ist es aber so, dass das VLC Modul eh nicht mehr richtig funktioniert und irgendwann mal komplett erstetzt oder zumindest anderst eingebunden wird (ebenfalls über x64 taugliche NuGet Packages). Du kannst also eigentlich einfach das VLC Modul/Addon in der Projektmappe entladen und von Hand die entsprechenden DLL's im Build Verszeichnis löschen. Ich denke ich werde demnächst mal die Projektmappe für x64 vorbereiten und das VLC ganz entfernen.