Ember Media Manager 1.4.8.0 Alpha - Diskussionsthread

Zitat von mam

Ach ja, ich vergaß, da ist noch ein anderer Bug, der wohl bei einigen unbemerkt zuschlägt:

* wenn man so eine Serie am Stück scrapen will, dann gibt Ember reichlich Gas mit seinen Internetverbindungen (wer will auch schon rumschnarchen?)
* er ist dabei so eifrig, dass einige Firewalls mit Standardeinstellungen das Ganze als Angriff betrachten (SYN FLOODING) und die Netzverbindungen verweigern.
* je nach Konfiguration ist man dann auf einer Blacklist (gar nix geht mehr) oder Greylist (x Stunden Sperre, danach darf man wieder) und guckt erstmal blöd in die Röhre

Das kann der eigene Firewall sein, oder irgendeiner bei einem Provider, nur beim eigenen kriegt man dann auch ne Fehlermeldung, bei fremden hängt man irgendwo in den Seilen (die Eieruhr ist Dein Freund...)

Hier wäre etwas Mässigung dringend angeraten, üblicherweise fangen Systeme bei mehr als 200 Verbindungsversuchen pro Sekunde dann an sauer zu werden.

TMDB lässt 30 API Calls in 10 Sekunden pro IP zu. Wird der Wert überschritten, pausiert die TMDB API automatisch für 30 Sekunden. Aus diesem Grund ist das Serien-Scrapen mit TMDB sehr langsam, da für jede Staffel und für jede Episode je ein API Call gemacht werden muss, damit man alle Daten bekommt. Aus dem Grund verzichte ich bei den Episoden-Infos auf gewisse Daten (externe IDs) und komme somit mit einem API Call pro Serie und Staffel aus. Leider funktioniert das bei den TMDB Bildern für die Episoden nicht, da muss ich für jede Episode einen API Call machen. Das Problem liegt aber am Aufbau der TMDB API, und so lange die nichts ändern (z.B. vollständigen Image Container gleich mit den Episoden-Infos mitliefern) wird sich auch betreffend Scrape-Dauer nichts verändern.

Bei IMDB bin ich noch nie als Limit gestossen und hier wurde mir auch nie was in der Richtung berichtet. Da IMDB aber keine offizielle API hat und wir die Website auslesen müssen, was vergleichsweise lange dauert, danke ich, dass wir da auch nicht geblockt werden.

Schlecht siehts' bei OFDB aus, die blocken extrem schnell schon nach ca. 80 Filmen in Folge. Dort ist man dann für 30-40 min gesperrt, danach gehts wieder. Die wollen aber auch nicht, dass man ihre Daten ausliest, deshalb wirds hier auch keine verbesserung geben.

Wir werden aber keine Mässigung der Verbindungen einbauen, das bringt nichts und verlangsamt den Prozess nur unnötig. Eher werfen wir alle Scraper ohne vernünftige API aus dem Sortiment.

Zitat von mam

Mal zurück zum leidigen OoM Problem

Also hierbei wirds Ember schon bei einer einzigen Serie zu eng ums Herz. Dabei sind da nur 131 "Folgen" vorhanden!

Dasselbe passiert auch bei Inspector Barnaby, das sind gerade mal 98 Folgen.

(alle Serien wurden einzeln gescraped, gebrannter MAM scheuts Feuer)

Mein derzeitiger Arbeitsverdacht liegt nicht so wirklich auf die Anzahl der Folgen, sondern die Anzahl der Staffeln (barnaby 15, Tatort 33) scheint ihm das Gnick zu brechen.
Bei Tatort kam dann auch wieder das "böse Renameproblem" mit dem Abbruch. Diesmal allerdings in einer harmloseren Version. Die Datei wurde korrekt umgenannt und in ihr neues Verzeichnis kopiert, das Original wurde allerdings nicht mehr gelöscht, stattdessen wurden zu beiden Kopien NFOs und Bilder angelegt!

Das ist alles noch seeeeehr halbseiden... BEWARE, BEWARE, BEWARE...

Alles anzeigen

Kannst du mit bitte nochmals deine aktuellen Einstellungen hochladen? Am besten das ganze Settings Verzeichnis, einfach ohne Datenbanken (*.emm).
Du hast jetzt in dem Test Ember gestartet und nur die Serie Tatort gescrapt? Oder vorher noch ein paar andere, bis es dann zu dem Fehler kam?
Der Screenshot von der Leistungsübersicht bringt nichts, ich müsste die Auslastung des Ember-Prozesses sehen.

EDIT: Kannst dir den Aufwand sparen, ich krieg das auch mit einer einzigen lokalen Tator Episode hin...

1) zur Zeit werden für jede Episode die Actorthumbs und alle anderen Bilder geladen, auch wenn sie nachher gar nicht gespeichert werden, weil die Episode lokal gar nicht vorhanden ist. Hier fehlt einfach eine Überprüfung. Kleiner Fehler, sehr grosse Auswirkung.

2) ich werd nun einbauen, dass die Bilder nach dem Speichern gleich aus dem Speicher gelöscht werden. Ich muss dafür die Klasse so umbbauen, dass die Bilder bei Bedarf automatisch wieder geladen werden. Sollte aber mit zumutbarem Aufwand gehen.

Zitat von Misaal

Ok bei House of Lies stürzt auch ab. Hier mal ein Log:

Da ist kein Log...

Zitat von mam

Gut, klingt pausibel, viel Glück

Erledigt. Die Klassen ist nun so angepasst, dass die Bilder nach dem Speichern gleich wieder aus dem Speicher entfernt werden. Ebenso werden nun nur noch bei vorhandenen Episoden Bilder geladen
Das Problem ist vor allem durch die Actor Thumbs entstanden, denn die wurden für jede Episode erneut in den Speicher geladen. Bei einer Serie mit vielen Episoden und dem obigen Fehler waren irgendwann tausende Bilder im Speicher. Das Problem sollte nun gelöst sein. Falls nicht, dann landet irgendwo noch was im ewigen Nirvana. Ich warte vorerst mal eure Feedbacks ab.

Zitat von mam

Die Ausführungen zeigen mir, dass Du Dich schon mal mit dem Thema auseinandergesetzt hast, sehr löblich!
Leider übersiehst Du dabei einen Punkt:

* auf dem Weg zur Webseite können noch beliebig (na ja, zumindest hop-zig ) viele dieser Kameraden unsichtbar rumlauern.

In meinem Fall sprang mein eigener Ausgangsfirewall an, weil das Modul zur Verhaltensanalyse meinte, hier sein ein Trojaner am Werk und meine Arbeitsstation flugs im LAN gesperrt hat. Dadurch war die Zuordnung natürlich leicht, aber es kann auch irgendwo beim Provider, beim Xchange oder sonstwo stecken.

Und wie stellst du dir die Lösung vor? Ich kann ja nicht jede Firewall oder ISP berücksichtigen. Ausserdem reklamieren eh schon sehr viele User, dass Ember der wohl langsamste Scraper überhaupt ist. Mal abgesehen davon, dass das meistens der Fehler der User selbst ist, da sie einfach alle Scraper aktivieren oder nicht verstehen, dass gewisse Informationsanbieter eine API haben und andere nicht, stimme ich dem zu. Ember ist langsamer als andere, bietet aber auch viel mehr Möglichkeiten und Funktionen als andere Programme. Ich seh's deshalb nicht ein, weshalb ich das ganze noch langsamer machen soll es jetzt schon ist. Wenn's zu Problemen kommt muss der User erstmal selbst sehen, dass er seine Software richtig konfiguriert.

Zitat von mam

Im Prinzip gehen wir da kondom Aber hier liegt ein Problem vor, dass der User im Normalfalle gar nicht erkennen kann. Du kannst auch nicht von jedem verlangen, zu wissen, was eine API ist, und wer vielleicht eine hat oder nicht.
Weniger ist manchmal mehr. Wenn Dir irgendwelche Scraper nicht gefallen, dann schmeiß sie raus.

In Bezug auf den Firewall sieht es aber schlecht für Dich aus. Meiner steht "auf default", so wie jedes BSD System auf der Welt in der Grundkonfiguration vorliegt (zumindest bei der Verhaltensanalyse). Wenn der anschlägt, erst den Begrenzer aktiviert und nach ein paar Minuten sogar den großen Netzbann verhängt. dann macht die Software da wirklich "komische Zicken". Es mag allerdings sein, dass dies bei sehr vielen nicht passieren kann, da sie eine deutlich langsamere Internetverbindung haben oder ihr Schlapprouter eh nicht mit der Speed mitkommt und von sich aus die weiße Fahne schwingt.

Aber lass erstmal die Version mit "weniger Bilder und dann auch nur, wenn nötig" rüberwachsen. Damit wird sich die Netzlast ja schon mal deutlich reduzieren und wir sehen weiter, ob er dann noch in den Begrenzer läuft.

So verbleiben wir

Kolpilierst Du noch selber oder soll ich dir für einen Test mal was rüberwachsen lassen? Die nächste offizielle Alpha kommt erst am Freitag. Ich will da noch einen Fehler in Scanner beim Reload der Staffeln fixen und den Bug, dass der Renamer beim Rescrapen einer Serie die Epsioden nicht umbenennt beheben.

Zitat von mam

Du hast doch vier Stellen Platz, warum nutzt Du nicht auch die letzte für Alphas/Betas ?

Weil bei jeder Änderung der Versionsnummer bei allen 1.4.7.2 Beta Usern die Info ausgelöst werden würde, dass eine neue Version verfügbar ist... und das soll nicht sein. Ich kann das leider erst mit Version 1.5.0.0 lösen (das wird dann die eigentliche 1.4.8.0 sein).

Zitat von Nepomuk

@DanCooper und @Cocotus
ich wollte ins TUT noch den noch nicht beschriebene Imagefilter einbauen.
Leider ist jetzt euer WIKI im Eimer. Könnt ihr das mal bitte checken.

Ja, leider ist das Wiki und der Bugtracker abgekackt... Für den Bugtracker habe ich bereits Ersatz besort, der wird später direkt auf dem Server von thebuggenie.com laufen. Ich hoffe damit haben wir dann weniger Aufwand das ganze zu warten.

Der Imagefilter prüft die gescrapten Bilder und markiert doppelt vorkommende Fanarts und Poster (auf TMDB und Fanart.tv sind ja häufig die selben Bilder vorhanden). DIe markierten Bilder werden dann ans Ende der Bilderliste verschoben und im Image Select Dialog mit einem Flag markiert. Ausserdem bewirkt der Filter, dass das automatisch ausgewählte Fanart weder in den Extrafanarts, noch in den Extrathumbs nochmals vorkommt, ebenso dass die Extrafanarts nicht in den Extrathumbs vorkommen.

Leider ist es zur Zeit so, dass das System im Zusammenhang mit dem Sprach-, Auflösungs- und eben Dublicate-Filter noch nicht einwandfrei funktioniert. Wir müssen uns da erst noch überlegen, was wie wann wie starkt priorisiert wird. Es erscheint momentan noch ziemlich komplex, das korrekt zu lösen. Aber kommt Zeit kommt Rat...

Die einstellbaren Zahlen bewirken, wie ähnlich sich die Bilder sein müssen, um als Duplikate markiert zu werden. Wie es funktioniert musst du aber @Coctus fragen, der hat das ganze umgesetzt, ich kapiers selbst noch nicht ganz
Irgendwie werden die BIlder auf eine sehr kleine Auflösung reduziert, dann die Farben entfernt und dann irgendwas verglichen...

Zitat von Nepomuk

Lösungsvorschlag:
In den Standard-Einstellungen ist ja von dir ein Scraper an erster Stelle und aktiviert.
Wenn der User jetzt z.B. TMDB aktiviert, poppt eine Meldung auf, in der kurz erklärt wird, warum der Scrapvorgang eventl. jetzt verlangsamt wird. Bei OFDB das Gleiche nur in verstärkter Form.
Das ändert zwar nichts an der Situation, aber der User weis jetzt wenigstens warum seine Scraps so lange dauern und vielleicht, hoffentlich meckert, jammert er hier im Forum dann nicht mehr so schnell - weil er weis ja jetzt woran es liegt.

Ist eigentlich ein guter Vorschlag. Ich denke, ich werde bei jedem Scraper unter den Einstellungen ein Infobereich einbauen, in den man solche Hinweise verfassen kann. Da es sich aber um ganze Sätze handelt und mein Englisch ziemlich schlecht ist, werde ich einen Kollegen damit beauftragen. Mal gucken wann der Zeit für sowas findet.

Zitat von Nepomuk

Ich hab jetzt mal folgendes bei dem TUT eingebaut:

.....

Ist das so richtig oder verbesserungsbedürftig.

Danke. Nein, ich denke das passt so.

Zitat von Misaal

Hier nochmals den LOG

Ich kann mir den Fehler ehrlich gesagt nicht erklären. Ich hab gerade folgendes getestet, ging ohne Probleme:

C:\Unsorted\Dragon Ball Kai\Season 1\Dragon Ball Kai - S01E01 - Der Vorhang öffnet sich für den Kampf! Son-Goku kehrt zurück\Dragon Ball Kai - S01E01 - Der Vorhang öffnet sich für den Kampf! Son-Goku kehrt zurück.mkv

Der Pfad ist aber auch nur 216 Zeichen lang. Woher nimmst du die Info, dass das es diese Datei war? Links unten steht die letzte hinzugefügt Datei, und die steht nur bei erfolgreichem Hinzufügen da. Ich denke es handelt sich eher um die nächste Datei im nächsten Episoden-Verzeichnis C:\Unsorted\Dragon Ball Kai\Season 1\*****. Kannst du mir diese mal nennen? Also nicht die nächste Episode, sondern der nächste Ordner in alphabetischer Reihenfolge.