Ember Media Manager 1.4.8.0 Alpha - Diskussionsthread

    vergiss den Link, ich habs geschafft, den ganzen Kram zu löschen (auch bei Github). Ruhe ist!
    Kein master mehr, keine klemmenden merges, Entspannung pur.
    Ich hab keine Ahnung was der Typ, der dieses Github verbrochen hat, so raucht, einwirft, oder spritzt, auf jeden Fall kann man den Mist vollständig vergessen und lebt besser ohne das Zeuch.
    Ich werd nun auch noch alles, was irgendwie mit GIT... anfängt, deinstallieren, dann macht der Rechner wenigstens wieder, was ich will.
    Und dann lad ich immer brav die Alphas runter und probier die aus...

    so, wieder normaler Tester und gleich schon der erste kleine Käfer zu melden:

    Legt man sich ein Icon an und ruft darin Ember mit Profilangabe auf, reicht ein kleiner Fehler, um ein Verschwinden von Ember zu erreichen.

    Nimmt man die (fehlerhafte! don't copy! don't use") Kommandozeile:

    "K:\Ember Media Manager BETA\Ember Media Manager.exe" -profile="Olddefault"

    So erscheint noch das Splashfenster, es geht bis "Lade Module" und SCHWUPPS, ist alles wieder weg :(

    Nach einiger Zeit grübeln kommt man dann darauf, dass die richtige Syntax lauten sollte: (die hier ist ok, die dürft Ihr euch merken!)

    "K:\Ember Media Manager BETA\Ember Media Manager.exe" -profile "Olddefault"


    Und schon klappts auch wieder mit dem Start, es erscheint brav das Hauptfenster.


    Ok, Anwenderfehler, aber dann sollte Ember doch wenigstens eine kleine Messagebox übrig haben, die in die richtige Richtungs schubst, so "Syntaxfehler in den Kommandozeilenparametern" würde schon viel bewirken und helfen...

    Wird im Log geloggt...
    Bei Problemen oder Fehlern einfach ab und zu mal da rein schauen.

    Zitat von DanCooper

    Wird im Log geloggt...
    Bei Problemen oder Fehlern einfach ab und zu mal da rein schauen.

    Lol, guter Witz! Glaubst Du, irgendein DAU guckt ins gut versteckte und nicht so übersichtliche Log ? ? ?

    Natürlich wußte ich sofort, was zu tun ist, aber ich rede vom unbedarften Anwender.

    Also, ich habe die neue Alpha x64 über die alte alpha22 x86 installiert. Jetzt dauert der Start von Ember allerdings locker 90 Sekunden, was ich echt lange finde. Das war vorher nicht so.

    Hier mal mein Log

    pastebin

    Vielleicht weiß ja jemand von euch was da los ist.

    Grüße

    EDIT: Kurzes Update... Mit der x86 Version geht es wieder ganz normal. Muss also irgendwas noch mit der 64Bit Geschichte zu tun haben.

    Einmal editiert, zuletzt von madhat (22. September 2016 um 15:01)

    Kann ich nicht bestätigen. Bei mir sind es gezählte 15 Sekunden. Hab bei der x86 bisher nicht gezählt, aber viel schneller dürfte das auf meinem kleinen Celeron auch nicht gewesen sein.

    Aber was anderes: Markierte Episoden lassen sich immer noch nicht gefiltert anzeigen. Markiert wirkt sich nur auf komplett markierte Serien aus. Für neue Episoden funktioniert die Filterung "neue Episode(n)" nach wie vor. Bei mir werden neue Episoden extra noch fest markiert. Wenn dann aber durch einen blöden Zufall Ember mal abstürzt, bzw. sich beendet, bringt mir die Filterung auch nichts mehr. Dann sollte "markiert" greifen.
    Gab es da nicht mal den Plan das entsprechend zu korrigieren?

    Zitat von nadkp

    Kann ich nicht bestätigen. Bei mir sind es gezählte 15 Sekunden. Hab bei der x86 bisher nicht gezählt, aber viel schneller dürfte das auf meinem kleinen Celeron auch nicht gewesen sein.

    Aber was anderes: Markierte Episoden lassen sich immer noch nicht gefiltert anzeigen. Markiert wirkt sich nur auf komplett markierte Serien aus. Für neue Episoden funktioniert die Filterung "neue Episode(n)" nach wie vor. Bei mir werden neue Episoden extra noch fest markiert. Wenn dann aber durch einen blöden Zufall Ember mal abstürzt, bzw. sich beendet, bringt mir die Filterung auch nichts mehr. Dann sollte "markiert" greifen.
    Gab es da nicht mal den Plan das entsprechend zu korrigieren?

    Ja, war mal geplant. Ich muss dafür den DB View ein wenig anpassen, so dass markierte Episoden auch noch berücksichtig werden. Ich sehe zu, dass ich das demnächst mal entsprechend erweitere.

    Kann ich weder mit x64 noch mit x86 nachvollziehen.

    Zitat von madhat

    Vielleicht weiß ja jemand von euch was da los ist.

    Sorry, keine Idee. Aus Deinem Log kann man ja noch nichtmals erkennen was davon x86 und was x64 ist.

    Im Moment wäre ich auch nicht mutig genug ein direktes Drüberinstallieren anraten zu wollen. Dazu muss der Scheffstratege erst noch einiges aufräumen und z.B. die Modulpfade trennen, damit sich die DLLs nicht beharken können. Ansatzweise gibts da schon X64 und X86 Unterverzeichnisse, aber die sind bislang nur wenig populiert und dienen nur zu Kopierzwecken. Richtig wäre es, alle Module dort abzulegen und programmintern einen erweiterten Pfad beim Aufruf zu verwenden.
    So besteht im Moment die latente Gefahr, dass sich ein falsches Modul dorthin verirrt und Probleme irgendwelcher Art verbreiten kann (die harmloseste Variante wäre es, wenn es nicht geladen werden kann und Ember dann sofort abschmiert, aber andere Szenarien sind leider denkbar).

    Da Mann (äääh Dan) eh gerade beim Grosreinemachen der Projektdateien ist, könnte er die Idee gleich umsetzen :whistling:

    Zitat von mam

    Sorry, keine Idee. Aus Deinem Log kann man ja noch nichtmals erkennen was davon x86 und was x64 ist.

    Ja, ich hab vergessen das im Log mit eintragen zu lassen. Werde ich fixen.

    Zitat von mam

    Im Moment wäre ich auch nicht mutig genug ein direktes Drüberinstallieren anraten zu wollen. Dazu muss der Scheffstratege erst noch einiges aufräumen und z.B. die Modulpfade trennen, damit sich die DLLs nicht beharken können.

    Docht, das geht ohne Probleme, hab's auch explizit hingeschrieben, dass das geht.
    Der Installer löscht bei jeder Installation das Verzeichnis Modules und alle Dateien, die direkt im Ember Verzeichnis liegen. Der Sauberkeit halber müsste ich das auch noch mit dem Verzeichnis Bin machen, aber dort liegen eh immer die selben Dateien, die nur per Code-Aufruf geladen werden. Diese werden durch den Installer einfach überschrieben. Dort drin liegen auch die einzigen Dateien, die manuell ja nach x86/64 Version beim Kompilieren kopiert werden. Alles andere regelt NuGet automatisch.

    Zitat von mam

    Ansatzweise gibts da schon X64 und X86 Unterverzeichnisse, aber die sind bislang nur wenig populiert und dienen nur zu Kopierzwecken.

    Die zwei Verzeichnisse x86 und x64 erstellt das SQLite Package automatisch. Wieso das so gelöst ist kann ich auch nicht sagen.

    Zitat von DanCooper

    Ja, ich hab vergessen das im Log mit eintragen zu lassen. Werde ich fixen.

    Ist ja nicht so schlimm, im Normalfalle sollte man ja wissen, was man installiert hat. Nur hier war es etwas interessant, aber auch nicht wirklich, da ja nix Böses drinstand. Einze Stelle, die ich für einen Hänger in Frage kommen sehe, wäre diese TraktTV, wenn es einfach nicht antwortet auf die falschen Logindaten (warum versucht es den Mist überhaupt? ich hab das Modul hier überall deaktivert, er lädt es trotzdem und versucht sich erfolglos anzumelden. Ich hasse solche "nach Hause telefonieren" Dinger!)

    >Docht, das geht ohne Probleme, hab's auch explizit hingeschrieben, dass das geht.
    Ja, hast Du 8o
    Aber ich bin aus der Kirche schon lange ausgetreten, mit haperte es schon immer am Glauben :whistling:

    >Die zwei Verzeichnisse x86 und x64 erstellt das SQLite Package automatisch. Wieso das so gelöst ist kann ich auch nicht sagen.ist eigentlich auch egal, könnte aber als Vorbild dienen. Microsoft unterscheidet ja auch (nicht ganz umsonst) nach "Program Files" und "Program Files (X86)".
    Das bügelt etwas die Unzulänglichkeit des Explorers aus, er zeigt Dir nirgendwo ob ein Exe/DLL 32 oder 64bittig ist. Das ist recht doof (man hatte wohl Angst den gemeinen DAU mit zuviel Informationen zu belasten).

    Es hätte schon was wenn da ein Baum wäre wie:

    \EMBER
    \BIN86
    \MODULESx86
    \BIN64
    \MODULESx64
    \PROFILS (*)
    ... (und noch die anderen "Common Files")

    Oder eben wirklich nach Microsoft ´Manier aufteilen in ganz unterschiedliche Pfade (wobei dann das Problem entsteht, dass es keine "common" "Common Files" gibt...)

    (*) oberste Priorität sollte haben, den Profilorder aus dem Ast rauszukriegen und an zentraler Stelle abzulegen, die auch bei Installation/Deinstallation/Update nicht tangiert wird. Im Moment ist das Mist, man beißt doch öfter nach Aufräumarbeiten in den Tisch und holt sich den Ordner vom Backup zurück...

    Zitat von mam

    warum versucht es den Mist überhaupt? ich hab das Modul hier überall deaktivert, er lädt es trotzdem und versucht sich erfolglos anzumelden. Ich hasse solche "nach Hause telefonieren" Dinger!

    Die API wird beim Start von Ember erstellt. Ich hab mir aber schon ein paar Mal vorgenommen, dass nur versucht wird ein Verbindung herzustellen, wenn auch Login-Daten eingetragen worden sind. Ich werde das ebenfalls noch fixen.

    Zitat von mam

    Das bügelt etwas die Unzulänglichkeit des Explorers aus, er zeigt Dir nirgendwo ob ein Exe/DLL 32 oder 64bittig ist. Das ist recht doof (man hatte wohl Angst den gemeinen DAU mit zuviel Informationen zu belasten).

    Das macht nur dann Sinn, wenn eine DLL im System registriert und von anderen Programmen genutzt wird. Hier in Ember, wo nur Ember auf die DLL's zugreift und es keine "gemischte" Version gibt macht es auch überhaupt keinen Sinn, bei der x86 Version die DLL's für x64 mitzuliefern. Das selbe gilt natürlich auch umgekehrt.

    Zitat von mam

    (*) oberste Priorität sollte haben, den Profilorder aus dem Ast rauszukriegen und an zentraler Stelle abzulegen, die auch bei Installation/Deinstallation/Update nicht tangiert wird. Im Moment ist das Mist, man beißt doch öfter nach Aufräumarbeiten in den Tisch und holt sich den Ordner vom Backup zurück...

    Das wird zum Stable-Release auch kommen. Ich muss dafür aber noch den Installer so umschreiben, dass man zwischen normaler und portable Installation wählen kann. Dann kann die normale Version auch endlich mal unter C:\Programme installiert werden.

    Zitat von DanCooper

    bei der x86 Version die DLL's für x64 mitzuliefern. Das selbe gilt natürlich auch umgekehrt.

    Ich hab nie was von mitliefern gesagt. Ich will nur, dass WENN jemand BEIDE Versionen installiert, diese sich nicht gegenseitig überschreiben, sondern in verschiedene Pfaden landen. Sonst hast Du irgenwann mal ein Kuddelmuddel und Fehler die schwer bis gar nicht zuordbar sind. Nimm es als Abwehr einer potentiellen Gefahr und Selbstschutz vor dem Anwender :-)))


    Zitat von DanCooper

    Frage: Wenn ihr einen Film/Filmset/Serie/Episode sperrt, sollte das dann auch der NFO gespeichert werden für den Fall, dass ihr die Datenbank neu aufbaut?

    Gegenfrage eines DAUS: Wozu ist das gut? Ich hab noch nie was gesperrt und mir fehlt der Sinn dahinter.

    Zitat von mam

    Ich hab nie was von mitliefern gesagt. Ich will nur, dass WENN jemand BEIDE Versionen installiert, diese sich nicht gegenseitig überschreiben, sondern in verschiedene Pfaden landen. Sonst hast Du irgenwann mal ein Kuddelmuddel und Fehler die schwer bis gar nicht zuordbar sind. Nimm es als Abwehr einer potentiellen Gefahr und Selbstschutz vor dem Anwender :-)))

    Ganz ehrlich, DAS ist ja wohl die schlechteste Idee ever. Wer zum Teufel installiert schon x86 und x64 ins gleiche Verzeichnis? Wenn schon dann installiert man die in verschiedene Pfade. Ich kann und will auch nicht die ganzen Pakete nach dem Kompilieren in den Verzeichnissen rumschieben, nur damit jemand, der beim Installieren Scheisse baut, keine Probleme kriegt...

    Zitat von mam

    Gegenfrage eines DAUS: Wozu ist das gut? Ich hab noch nie was gesperrt und mir fehlt der Sinn dahinter.

    Das Sperren ist z.B. für Filme nützlich, die man nach dem Scrapen manuell editiert hat, weil einem etwas nicht passte oder falsch war. Oder für private Filme, die man so benannt hat, dass der Scraper einen "normalen" Film mit diesem Titel finden würde. Gesperrte Medien werden beim Scrapen immer übersprungen und können nur manuell editiert werden.

    Zitat von DanCooper

    Ganz ehrlich, DAS ist ja wohl die schlechteste Idee ever. Wer zum Teufel installiert schon x86 und x64 ins gleiche Verzeichnis? Wenn schon dann installiert man die in verschiedene Pfade. Ich kann und will auch nicht die ganzen Pakete nach dem Kompilieren in den Verzeichnissen rumschieben, nur damit jemand, der beim Installieren Scheisse baut, keine Probleme kriegt...

    Gut, dann hör aber auch auf den Leuten zu raten, "einfach drüberzuinstallieren". Das mag im Moment gut gehen, weil Du aufräumst, aber das wird nicht immer so bleiben (und vor allen Dingen kann das ausser Dir keiner wissen). Also nimm gleich verschiedene Pfade und gewöhn die Leute nicht an fehlerträchtige Konstrukte.

    Zitat von DanCooper

    Das Sperren ist z.B. für Filme nützlich, die man nach dem Scrapen manuell editiert hat

    Danke, der DAU hat hinzugelernt und wird dies ab sofort in seine Betrachtungen mit aufnehmen :thumbup:
    Obwohl ich das bislang noch nicht gebraucht habe, sagt mir mein Bauchgefühl: JA, auch in der NFO sperren (allerdings bitte dann irgendwo optisch hervorheben, damit man die Dinger bei Bedarf wiederfindet).

    Einmal editiert, zuletzt von mam (23. September 2016 um 09:52)

    Zitat von mam

    Gut, dann hör aber auch auf den Leuten zu raten, "einfach drüberzuinstallieren". Das mag im Moment gut gehen, weil Du aufräumst, aber das wird nicht immer so bleiben (und vor allen Dingen kann das ausser Dir keiner wissen). Also nimm gleich verschiedene Pfade und gewöhn die Leute nicht an fehlerträchtige Konstrukte.

    Doch, denn ich bin sowieso gezwungen, den Ordner Modules und die Dateien direkt im Ember Ordner bei jeder Installation zu löschen. Denn es kommt öfters mal vor, dass eine DLL nicht mehr benötigt wird. Diese soll dann auch nicht mehr vorhanden und geladen werden, nur weil sie in einer älteren Version mal von Nöten war. Von dem her MUSS der Installer so gestaltet sein, dass alle relevanten Verzeichnisse erstmal vom alten "Schrott" gesäubert werden.
    Es gibt hierbei überhaupt keine Probleme, wenn jemand eine neue Version über eine alte installiert, egal ob x86 oder x64.

    Zitat von mam

    Obwohl ich das bislang noch nicht gebraucht habe, sagt mir mein Bauchgefühl: JA, auch in der NFO sperren (allerdings bitte dann irgendwo optisch hervorheben, damit man die Dinger bei Bedarf wiederfindet).

    Die gelockten Einträge werden jetzt schon farblich in der Liste markiert, ebenfalls existiert ein Filter dafür. Neu wird die Info, dass ein Film/Serie/Episode gelockt ist, einfach auch noch in der jeweiligen NFO gespeichert, so dass es bei erneutem Import in die DB immer noch gesperrt ist.

    Servus!

    Mir ist gerade durch Zufall aufgefallen, dass beim Scannen der Metadaten die Laufzeit nicht mehr ermittelt wird. Bei allen neuen Filmen oder Episoden steht da jetzt der Wert 0. Nutze die neue Alpha 23 x64 Version, die ich einfach drüber installiert habe.

    Zitat von nadkp

    Servus!

    Mir ist gerade durch Zufall aufgefallen, dass beim Scannen der Metadaten die Laufzeit nicht mehr ermittelt wird. Bei allen neuen Filmen oder Episoden steht da jetzt der Wert 0. Nutze die neue Alpha 23 x64 Version, die ich einfach drüber installiert habe.

    Danke für den Hinweis. Scheint so, als würde die neue Version von MediaInfo den Wert anderst ausgeben als vorher. Die Regex funktioniert nun nicht mehr und ich muss sie anpassen. Liegt aber nicht an x86/64 ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden