OFDb

Verhalten QI-Einstellung der Coverbreite zu Bildbreiten im Ordner

Begonnen von 80erSiFi-Fan, 22 Januar 2024, 19:40:41

⏪ vorheriges - nächstes ⏩

0 Mitglieder und 1 Gast betrachten dieses Thema.

80erSiFi-Fan

ACHTUNG: Romanlänge!                                    Seite 1 von xxx

Nachdem hier 3 Tage lang nix los war, versuche ich mit meinem Käse hier mal für etwas Wind zu sorgen.
Hoffe es ist zumindest ein klein wenig brauchbares in so viel Text.
Ja mir war heute langweilig und ich hoffe mir nimmt keiner den Roman hier krumm.

 
Wenn die QI-Einstellung der Coverbreite (Pixel) eine andere ist als die Bildbreite der Dateien im movies oder covers Ordner.

Grund der neuen Testreihen:
Anlass war diesmal, dass ich die Filmpreise anhand der IMDB Seite (Danke an xletterx für den Link) eingetragen habe und MyMDb-CE dabei sehr lange am Stück geöffnet war.
Dabei fiel mir auf das MyMDb-CE bei einer Java-Speicherauslastung ab 900MB sehr träge wird. Dieses Verhalten hat franklyn ja auch schon festgestellt und erwähnt.

Getestet mit, auf & wie:
Für diese neuen Testreihen habe ich wieder meine Test-Datenbank mit 690 Einträgen hergenommen.
Allerdings diesmal nur auf meinem kleinen Büro PC mit nem i5-6500.
Um den Speicher extrem schnell mit MyMDb-CE ans Limit zu bringen, habe ich auch dieses Mal, immer nach neu geöffnetem MyMDb-CE, den Eintrag Nr.1 markiert und die Pfeiltaste ↓ dauerhaft gedrückt gehalten.
Jedes Testergebnis wurde mit mind. 3 oder mehr Testwiederholung ermittelt.

Verwendetes Zusatzprogramm:
HWiNFO64 um CPU- und Speicherauslastung vergleichen zu können.

Vorgeschichte/Info:
Bei meinen ersten Testreihen vor einigen Tagen, war der kritische Punkt ab welchem MyMDb-CE Standbilder bekam oder sogar eingefroren bzw. abgestürzt ist, als eine Java-Speicherauslastung um die 1100 MB (+-50MB) erreicht wurde und der Test noch nicht am Listenende angekommen war.

Meine Erstmaßnahme um der Geschwindigkeit der Speicherauslastung entgegen zu wirken:
Zuerst habe ich meine bisherigen Bilder mit 400x563p (87KB/Bild) im movies Ordner jetzt doch durch etwas kleinere Bilder mit 300x422p (38KB/Bild) ersetzt.
Das alleine hat schon sehr viel geholfen und die optische Qualität der Bilder in MyMDb-CE ist noch immer um Welten besser als die 120er Bilder.

Weitere Überlegungen und Beginn der Testreihen:
Um die Geschwindigkeit in welcher der Speicher durch Java vollläuft, weiter reduzieren zu können, habe ich nochmals etliche durchgeführt.
Diesmal jedoch auch die Einstellungen in MyMDb-CE verändert, um zu sehen ob es Zusammenhänge zwischen Bildgrößen und den Einstellungen in MyMDb-CE gibt.

Auch den Hinweis von tbengel (Danke dafür), sich die Cover im Quick-Info Feld mit den ,,Front Cover-Feld" anstelle dem ,,Cover-Feld" anzeigen zu lassen, habe ich getestet.

1.Test mit ausgewähltem ,,Cover (Feld)" im Quick-Info Feld zur Coveranzeige:
Bilder im movies Ordner: 300x422
Bilder im covers Ordner: 767x1080
Quick-Info-Einstellungen/Maximale Breite: 300
Einstellungen/Quick-Info/ Pixel Cover-Breite: 300
Ausgewähltes Anzeige Element im Quick-Info Feld: Cover (Feld)
kurze Legs: ab Nr. 150-200,  Längere Standbilder: keine,  1000 MB Speicherlast bei: Nr.580-650, Listenende erreicht: Ja-sehr flüssig.

2&3.Test mit ausgewähltem ,,Cover (Feld)" im Quick-Info Feld zur Coveranzeige:
Bilder im movies Ordner: 300x422
Bilder im covers Ordner: 767x1080
Quick-Info-Einstellungen/Maximale Breite: 1x mit 280 & 1x mit 320 (jeweils nur 20 pix Unterschied zu den Bildern)
Einstellungen/Quick-Info/ Pixel Cover-Breite: 300
Ausgewähltes Element im Quick-Info Feld: Cover (Feld)
kurze Legs: ab Nr. 70-90,  Längere Standbilder: ab Nr. 350-450,  1000 MB Speicherlast bei: Nr.540-590, Listenende erreicht: Ja-nach einigen 2 sekündigen Standbildern beginnend bei Nr. 630-650.

Weitere Tests mit ausgewähltem ,,Cover (Feld)" im Quick-Info Feld:
Weitere Test mit 300x422 Bildern im movies Ordner, bei ,,Quick-Info Einstellungen/Maximale Breite" immer 300, jedoch mit größeren, kleineren oder keine Bildern im covers Ordner, sowie unterschiedliche Einstellungen von 300-400 unter ,,Einstellungen/Quick-Info/Pixel Cover-Breite", brachten keinerlei Veränderungen.

Dieselben Testreihen habe ich dann mit eingestelltem ,,Front-Cover (Feld)" im Quick-Info Feld durchgeführt.

Mit dem ,,Front-Cover (Feld)" als Anzeige im Quick-Info Feld, einem eingestelltem Wert von 300 unter ,,Quick-Info-Einstellungen/Maximale Breite" und mit Bildern in 300x422 im covers Ordner, liefen die Test bis zum Ende flüssig durch.
Einziger Unterschied, Bei allen Tests lag die Speicherauslastung auf 1000MB um ca. 50-70 Nr. früher an.

Was jedoch in beiden Fällen extrem aufgefallen ist:
Weicht der in den ,,Quick-Info Einstellungen/Maximale Breite" eingestellte Wert, hier 300, von der Breite der Bilder welche sich im movies bzw. covers Ordner befinden ab, dann steigt die Geschwindigkeit in welcher Java den Speicher auslastet, je nach Höhe der Abweichung, sehr stark an.
Auf meinem alten PC könnte ich selbst bei nur einem Pixel Abweichung, bei 300er Bildern im Ordner und Einstellungen von 299 und  301 in den ,,Quick-Info Einstellungen/Maximale Breite", bereits Unterschiede in der Geschwindigkeit feststellen.
In diesem +/- 1 Pixel Bereich  wurden die 1000MB ca. 20-40 Bilder früher erreicht, je Größer der Unterschied in den ,,Quick-Info Einstellungen/Maximale Breite" zu den Bildbreiten im Ordner movies oder covers ist, desto schneller wird die Kritische Speicherauslastung erreicht.

Mit der Einstellung ,,Auto" als Maximale Breite habe ich auch getestet. Da werde ich jedoch nicht schlau draus. :denk:
Die 1000MB wurde mal etwas früher und mal etwas später als mit fest eingestellten 300, erreicht. Diese Schwankung lag immer im Bereich um die +/- 50 Nr.
Nur die CPU Auslastung war mit der Einstellung ,,Auto" immer um 4-5% höher als mit festen Werten 300 und passenden 300er Bildern.

Mein Persönliches Fazit:
Wer eine mMn schlechte Bildqualität bei allen Covers in der Coverübersicht unter dem Tab-Reiter ,,Covers" und als Front-Covers auch keine großen Bilder über 300 Pix braucht, der ist mit der Coveranzeige im Quick-Info Feld mit der Einstellung ,,Front-Cover (Feld)" bestens beraten.

Der sehr sehr große Vorteil mit der Einstellung des ,,Front-Cover (Feld)" ist: Die 120x??? Bilder im movies Ordner können in der Größe so bleiben wie sie von MyMDb-CE abgelegt werden.
Auch das mühselig, zeitaufwändige und exakte umbenennen der Bilder für den movies Ordner muss nicht gemacht werden.

Macht man sich jedoch die Mühe und ersetzt alle 120x??? Bilder welche im movies Ordner sind mit in einheitlichen und größeren (300x422) Bildern und nimmt die Arbeit auf sich, alle Bilder auch noch exakt mit den bisherigen Bilder-Namen umzubenennen, wird man auch belohnt.

Alle Covers in der Listenansicht, alle Covers in der Coverübersicht unter dem Tab-Reiter ,,Covers" als auch das Cover im Quick-Info Feld, werden in sehr guter Bildqualität angezeigt.
Zusätzlich können Front-Covers eingefügt werden, welche wesentlich größer sind als dies möglich ist wenn man sich im Quick-Info Feld mit dem ,,Front-Cover (Feld)" die Covers anzeigen lässt.
Die Bilder welche sich im Ordner movies befinden, sollten dann jedoch exakt die gleiche, eingestellte Anzeigebreite welche im Quick-Info Feld ist haben.

Die wichtigste Feststellung bei meinen Test hier war:
Die Einstellung unter ,,Quick-Info Einstellungen/Maximale Breite" müssen mit der Breite der Bilder im movies oder covers Ordner übereinstimmen oder auf Auto steht. Ansonsten steigt die Speicherauslastung wesentlich schneller an.
Was am besten eingestellt wird wenn die Breite der Bilder im covers oder movies Ordner unterschiedlich sind, kann ich nicht sagen, da nicht getestet.
Bei Einstellung eines festen Wertes wird wohl wie oben getestet, die Speicherauslastung zumindest etwas schneller ansteigen.
Ob die Einstellung ,,Auto" in so einem Fall entgegenwirkt, kann ich ebenfalls nicht sagen.

Wie ich nach meinen ersten Testreihen vor Tagen festgestellt habe, unterscheiden sich die Ergebnisse und Auswirkungen der Test, von PC zu PC je nach Leistung und Hardware, sehr stark.
Mein hier verwendeter PC gehört schon zum sehr alten Eisen. Daher kann ich nicht beurteilen ob und in wie weit meine hier festgestellten Ergebnisse auf andere PC übertragbar sind.
Vor allem wenn es sich um einen ganz neuen Hightech-PC handelt welcher mehrere Hundert Watt verzehrt. Mein kleiner PC verbraucht bei 100% CPU-Last max. 40 Watt (Idle 3-4W).
Info am Rande, damit man sieht auf welchem Steinzeitmodel bei mir MyMDb-CE trotz der vielen persönlichen Anpassungen und größeren Bilder, noch immer sehr gut und flüssig funktioniert.

Sicher bin ich mir jedoch, dass je nach Einstellung welche Breite unter ,,Quick-Info-Einstellungen/Maximale Breite" eingetragen wurde und welche Breite die Bilder im Ordner haben, aufeinander Einfluss haben was die Speicherauslastung angeht.
Je größer diese Differenz ist umso schneller lastet Java den Speicher aus. Auch hierbei wird wohl die Hardware einen Effekt haben wie schnell das geschieht.

Wenn jetzt jemand denkt, der braucht doch nur alles so lassen wie es ist. Ja der hat natürlich auch Recht, aber:
Mir sind die Optik der Buttons, Filmpreise usw. und vor allem die Bildqualität der Covers in jeder Ansicht, extrem wichtig.
Unscharfe und zu kleine Bilder (in meinen Augen) gehen gar nicht!
Zum anderen habe ich MyMDb-CE auch in der Standartkonfiguration getestet. Auch da steigt die Speicherauslastung kontinuierlich an. Natürlich um einiges langsamer.
Nur bei einem Test, mit deaktiviertem Quick-Info Feld hat Java keine 600MB Speicherauslastung erreicht.
Da lief der Test sogar 2x hintereinander ohne Probleme durch ohne MyMDb-CE neu gestartet zu haben.


Und der letzte Punkt, wenn ein Programm schon so viele gestalterische Freiheiten anbietet und auch nur ganz wenige Veränderungen (wie die Banner) in der optischen Gestaltung unterbindet, wäre es doch schade dies nicht auszuloten und nach seinem pers. Geschmack anzupassen.
Testen und Fehler finden war mal vor langer Zeit ein Teil meines Jobs in der Endkontrolle.
Dieses tüfteln, testen und nach Verbesserungen zu suchen mache ich auch heute noch sehr gerne. Wenn auch wie hier in etwas anderer und Form.


Grüße 80erSiFi-Fan

PS: Ich kann mir gut vorstellen dass dies für den einen oder anderen Anwender Interessant sein könnte.
Vor allem wenn beim herumprobieren in den Einstellungen der Wert mal verändert wurde und jetzt nicht mehr auf der Standarteinstellung ,,Auto" steht.

Roman -ENDE-

franklyn

Moin @80erSiFi-Fan,
Zitat von: 80erSiFi-Fan am 22 Januar 2024, 19:40:41... und ich hoffe mir nimmt keiner den Roman hier krumm.

Wenn etwas nicht interessiert, muss man es ja nicht lesen... , also keine Sorge.
Du nimmst ja auch niemandem etwas weg, es hat noch genügend Platz im Internet.

Meine 2 cents zu dieser Angelegenheit (Bildertausch, Größenänderung...) hatte ich Dir ja schon in Deinen Beutel geworfen.

Was ich bei Deiner ganzen Arbeit nicht so ganz nachvollziehen kann (ist nicht schlimmm, muss ICH ja auch nicht, brauche auch keine Erklärung) ist:
Zitat von: 80erSiFi-Fan am 22 Januar 2024, 19:40:41...dabei sehr lange am Stück geöffnet war.
Das alleinige "offenhalten" des Programms macht bei mir keine "Probleme".
Das kann 10 Stunden offen sein und rennt trotzdem wie Schmitt's Katze, wenn ich nach dieser Schlafperiode wieder etwas mache (suchen, blättern, rumkucken....).

Wenn ich allerdings sehr viel editiere, Reihenfolgen abändere und andere "Änderungen" an meiner Datenbank vornehme,
ja DANN passiert es (aber auch erst nach längerer Zeit), dass es dann anfängt zu stocken, "merklich hakeliger, langsamer" läuft.
An einer solchen Stelle, schließe ich das Programm - und starte es sofort wieder.
Dank des gemerkten, letzten Datensatzes bin ich ja auch sofort wieder an der "richtigen" Stelle.

Dazu muss natürlich gesagt werden, dass ich eben keinen  :frech2: :frech2: - "Cover-Aufwand" betreibe...

Warum ich das so handhabe, ist auch schnell gesagt:
Zitat von: 80erSiFi-Fan am 22 Januar 2024, 19:40:41...Datenbank mit 690 Einträge
Meine Datenbank hat ein "paar mehr" Einträge und dient auch nicht als Test- sondern als echte Arbeitsumgebung.
Und diese Arbeitsumgebung will ich so effektiv und stabil wie nur möglich bei mir haben.

Das wäre mit "Deinen Cover-Optimierungen", trotz flotter Hardware, bei mir schlicht nicht möglich... :happy:
Abgesehen von dem ganzen Vorab-Zeitaufwand der gesonderten Bearbeitung, wäre ich viel zu oft genervt von "zögerlichen Reaktionen" des Programms.

Daher ist die Standard-Einstellung des Programms für mich auch die beste. Selbst hinzugefügte (geänderte) Cover werden automatisch vom Programm "verkleinert". Da muss ich nichts weiter tun - und kann mich wichtigeren Dingen zuwenden.
Die qualitative Cover-Darstellung in der Listen-Übersicht, auf dem (engestellten) Covertab und in der edit-box genügen meinen Ansprüchen vollauf.
Einzig die QI-Panel Ansicht des Covers könnte, aufgrund meiner dort eingestellten Darstellungsgröße, etwas schöner sein...
Aber über den Weg des "Front-Cover-hinzufügen" will ich standardmäßig nicht gehen, auch deswegen nicht, weil ich mir, wie oben schon gesagt,
ein möglichts effektiv rennendes Programm auch auf Dauer erhalten möchte.

Das hält mich ja nicht davon ab, im Einzelfall dennoch auch mal ein "Front-/Back-Cover" (bei einem Zusatznutzen) hinzuzufügen, um es dann in der edit-box (nicht QI-Panel) angezeigt zu bekommen.

Und solange das Java-Imperium nichts an seiner "freien-Speicher-wieder-freigeben-Politik" ändert  :wut: , halte ich meine "Einstellungen" für mich besser geeignet.


Kleiner Tip für eine "Grundsatz-Überlegung" zum Schluss:
Getestet hast Du mit einer Test-Datenbank mit 690 Einträgen.
Du hast jetzt schon, wenn ich mich richtig erinnere, eine "Backup-Größe" von ca. 400 MB bei nur ca. 1.000 Filmeinträgen... bei Deiner "echten" Datenbank...
Denk das doch mal ALLES etwas länger, dauerhafter.... z.B. mit einer Datenbank von nur 5.000 Filminträgen oder noch viel mehr...
Ich könnte mir vorstellen :denk2: , dass Du IRGENDWANN einmal nicht mehr ganz glücklich über Deine aufwendigen "Cover-Größen-Änderungen" sein wirst....

Denn die Grund-Problematik liegt ja in erster Linie nicht bei "unzureichender Hardware", was jederzeit änderbar ist, sondern beim "Speicher-Management" von JAVA.


Deine aufführlichen Tests halte ich natürlich für sehr sinnvoll und besonders lobenswert. :respect: :respect:
Der geneigte Leser kann daraus sehr gut seine eigenen Schlüsse ziehen und so viel besser für sich selbst entscheiden, welche der vielen Möglichkeiten für ihn selbst "gangbarer" sein dürfte.


Viele Grüße

franklyn

80erSiFi-Fan

Zitat von: franklyn am 23 Januar 2024, 20:31:07Was ich bei Deiner ganzen Arbeit nicht so ganz nachvollziehen kann (ist nicht schlimmm, muss ICH ja auch nicht, brauche auch keine Erklärung) ist:
Gebe doch mal ne kleine Bemerkung zu ab.
Habe mich mit ,,sehr lange am Stück geöffnet war" nicht klar ausgedrückt. Beim Eintragen der Filmpreise war MyMDb-CE sehr viele Stunden am Stück offen und dabei habe ich sehr oft in der Liste rauf und runter gescrollt und Filmpreise und Einträge bearbeitet.
Das alleine hat bei mir ausgereicht das der Speicher mit der Zeit bei meinem kleinen PC vollgelaufen ist.
Mag wohl mit an meinen eigenen Bildern liegen, das kann ich nicht abstreiten.
Zitat von: franklyn am 23 Januar 2024, 20:31:07Kleiner Tip für eine "Grundsatz-Überlegung" zum Schluss:
Getestet hast Du mit einer Test-Datenbank mit 690 Einträgen.
Du hast jetzt schon, wenn ich mich richtig erinnere, eine "Backup-Größe" von ca. 400 MB bei nur ca. 1.000 Filmeinträgen... bei Deiner "echten" Datenbank...
Denk das doch mal ALLES etwas länger, dauerhafter.... z.B. mit einer Datenbank von nur 5.000 Filminträgen oder noch viel mehr...
Ich könnte mir vorstellen :denk2: , dass Du IRGENDWANN einmal nicht mehr ganz glücklich über Deine aufwendigen "Cover-Größen-Änderungen" sein wirst....

Denn die Grund-Problematik liegt ja in erster Linie nicht bei "unzureichender Hardware", was jederzeit änderbar ist, sondern beim "Speicher-Management" von JAVA.
Ja seit Deinem ersten Hinweis vor einiger Zeit hier, habe ich dies immer im Hinterkopf.
Im letzten Jahren wurden bereits gute 100 Einträge in MyMDb-CE gelöscht. Habe sehr viele alte TV Aufnahmen gelöscht, sehr viele DVD verschenkt und verkauft.
Demnächst werden alle TV-Aufnahmen und DVDs mit Kinderfilmen und Kinderserien an meine Kinder verschenkt und aus MyMDb-CE gelöscht.
Auch alle DVDs, alle Restlichen alten TV-Aufnahmen welche noch übrig sind, mich nicht mehr interessieren und ich mir mit Sicherheit auch nicht mehr ansehen möchte, verschenke ich an Familie und Freunde. Wer halt was möchte.

Von daher wird meine Datenbank in nächster Zeit extrem zusammenschrumpfen und neues kaufe ich ohnehin kaum noch dazu. Die Serie 1883 war vor kurzem seit Monaten mal eine Ausnahme. Da hab ich mir die DVDs zugelegt.

Ich gehe davon aus das meine Datenbank wenn alles Mal weg ist, auf 700-800 zusammenschrumpfen wird und die 1000 werde ich nicht mehr erreichen.
Ja, was Java mal im Speicher hat, möchte es nicht mehr hergeben. Kenne ich als meine Tochter an meinem PC immer Megabauten-Welten mit Minecraft-Java erstellt hat.
Da ist Minecraft auch des Öfteren ins Standbildkino gekommen. Spiel Neustarten und weiter giengs.

Kann aber gut nachvollziehen da Du bei einer so großen Datenbank, mit MyMDb-CE keine Spielchen betreibst und alles auf optimaler Stabilität und Geschwindigkeit ausrichtest.

Für meine kleine Datenbank um die 1000 und bald viel weniger kann MyMDb-CE auch mal die Haare schön haben.

Da ich mit den Eintragungen der Filmpreisen fertig bin und heute auch die letzten eigenen Symbole für einige buttons, Links, usw. erstellt und eingefügt habe, ist MyMDb-CE für mich jetzt komplett nach meinem Geschmack fertig eingerichtet.
Somit werde ich wohl auch keine Speicherprobleme mehr bekommen, da nix mehr an MyMDb-CE herumprobiert wird. Alleine die Verkleinerung der Covers von den 400er auf die 300er mit halber Größe, hat extrem viel gebracht.

Jetzt ist MyMDb-CE bei mir das wofür es vom Schöpfer und allen aus dem MyMDb-CE Team hier gemacht wurde und auch noch wunderbar gepflegt wird.
Eine super tolle Filmdatenbank. Danke für Eure Arbeit! :anbeten:  :respect:

Oh man, ich kann nicht kurz. Sorry  :happy2:

Zitat von: franklyn am 23 Januar 2024, 20:31:07Deine aufführlichen Tests halte ich natürlich für sehr sinnvoll und besonders lobenswert. :respect: :respect:
Der geneigte Leser kann daraus sehr gut seine eigenen Schlüsse ziehen und so viel besser für sich selbst entscheiden, welche der vielen Möglichkeiten für ihn selbst "gangbarer" sein dürfte.
Vielen Dank  :bier:
Grüße 80er SiFi-Fan

franklyn

Moin @80erSiFi-Fan,

:schock: :schock:   :frech2: :schock: :schock:
Auf die für mich vollkommen abwegige Idee, dass jemand seine Datenbank nicht als ständigen Prozess mit der Zeit immer weiter vergrößern, 
sondern sogar VERKLEINERN will, wäre ich im Leben nicht gekommen!
Hätte ich SOWAS geahnt, hätte ich mir meinen Senf verkneifen können. :happy3:

Da sieht man mal wieder: Jeder Jeck ist anders.
Und das ist gut so. Und besonders gut ist, dass MyMDb-CE es jedem Jeck ermöglicht, seine eigenen Spielchen mit sich spielen zu lassen.

Zitat von: 80erSiFi-Fan am 23 Januar 2024, 22:46:24... meine Datenbank ... auf 700-800 zusammenschrumpfen wird ... 1000 werde ich nicht mehr erreichen.
Bei so einem "besonderen Umgang" mit MyMDb-CE kannst Du Dir "mit den Covern" sicherlich mit gutem Gewissen fast alles erlauben, 
bevor das Java-Imperium das Programm in die Kapitulation zwingt... 

Vielleicht ist in Deinem Fall die Cover-Darstellung im QI-Panel für Dich sogar gesondert auf einem zweiten Monitor machbar ?   :dodo:
... dann kannste alles noch mal neu machen, mit hochauflösenden RiesenCovern in Monitor-Größe...   :happy3: :dodo:

Ok, Scherz beiseite,
Zitat von: 80erSiFi-Fan am 23 Januar 2024, 22:46:24... kann MyMDb-CE auch mal die Haare schön haben
Da stimme ich Dir in Deinem Fall vollkommen zu. Fein machst Du's Dir! :respect:

Aber für die sicherlich meisten User (???) dürften Deine Tests, so sie verstanden und ernst genommen werden,
wahrscheinlich eher zu einem zu Dir gegensätzlichem "Umgang mit Covern" führen. Also "Standard und gut is !"
Dazu würde ich zumindestens raten, so man auf Dauer seine DB, bzw. die enthaltenen Datensätze immer nur weiter "vergrößern" will ...


Viele Grüße

franklyn

TinyPortal 2.0.0 © 2005-2020