1 Solution
Accepted Solutions
Hallo Matthias,
Matthias Marm schrieb:
Hallo Community,
bei einem Kunden machen wir gerade ein ReDesign mit neuer Rasterlogik. Dafür müssen wir dann bei der Umstellung die alten Auflösungen mit den neuen Werten anlegen (ändern geht ja nicht in FirstSpirit, oder hat sich dawas getan?) Jetzt kam die Frage auf, ob sich das auf den benötigten Speicherplatz auf dem FS Server auswirkt. Laut dem technischen Ansprechpartner auf Kundenseite werden wohl die Auflösungen für jedes Medium direkt in der Berkely DB gespeichert (wusste ich vorher nicht 😉 und bei der Generierung lediglich ins Staging kopiert.
Wenn dem so ist, weiß jemand, wie sich das neue Anlegen auswirkt? Gibt es für die Auflösung der Medien dann auch eine Art Versionierung, so dass sich das Datenvolumen in der DB drastisch erhöht? Bei der Generierung sollte es ja keine Probleme geben, denn da werde nur die aktiven Auflösungen generiert, oder?
Die Auflösungen ändern sich natürlich nur marginal, etwaige Schwankungen des Datenvolumens wegen dieser Änderungen sind dann natürlich auch zu erwarten. Es geht vorrangig darum, dass jetzt nicht auf einmal das doppelte an Datenvolumen für die Medien auf dem FS Server benötigt wird.
Vielen Dank fürs Feedback und viele Grüße
Matthias
Also, der Satz
> Dafür müssen wir dann bei der Umstellung die alten Auflösungen mit den neuen Werten anlegen?
ist ein größeres Problem 
Um das zu erklären, muss ich etwas ausholen:
Die Aussage, das die Auflösungen direkt im Repository gespeichert werden, ist nur bedingt korrekt. Es werden dort nur die bereits berechneten Auflösungen (und natürlich die manuell hinzugefügten) gespeichert. eine Auflösung wird nur dann berechnet, wenn Sie benötigt wird.
Das bedeutet also zum Beispiel, dass bei einer Generierung/Vorschau geprüft wird, ob zu dem für diese Aktion gültigen Originalbild bereits eine berechnete Auflösung vorliegt. Wenn ja, so wird diese direkt aus dem Repository gestreamt. Wenn nein, so wird diese Auflösung neu berechnet, im Repository gespeichert und dann daraus gestreamt.
Die Prüfung, ob eine Auflösung vorhanden ist oder nicht, geschieht über deren Referenznamen.
Kommen wir zum Problem (und einem der Gründe, warum Auflösungen nicht geändert werden können):
Wenn Du eine Auflösung löscht, ändert sich erst einmal nichts an den bereits vorhandenen Medien.
Wenn Du nun die Auflösung mit dem selben anmen, aber anderen Werten neu anlegst, ändert sich wieder nichts an den bereits vorhandenen Medien.
Anmerkung: Du WILLST auch gar nicht, dass sich hier etwas ändert, da die Aktion ansonsten entsprechend lange dauern müsste. {Das war in der Version 3.1 der Fall und da konnten gewisse Projektänderungen in größeren Medienprojekten auch mal einige Stunden dauern, was dann meistens zum Abbruch der entsprechenden Aktion durch den Administrator führte}
Also haben wir nun den Stand, dass es eine Auflösung mit geänderten Werten gibt, für viele der vorhandenen Bilder aber bereits ein berechnetes Bild für genau diese Auflösung vorhanden ist.
Bei der nächsten Generierung wird für diese Bilder geprüft, ob es für die entsprechende Auflösung bereits ein Bild gibt (Ja) und dann wird dieses Bild gestreamt. Leider hat es nun die falschen Maße.
Auflösungen für ein Bild werden nur verworfen, wenn sich die Originalauflösung des Bildes ändert. [Und auch dann werden nur automatisch berechnete Auflösungen verworfen, keine manuell eingestellten]
Anmerkung: Wie alle anderen Änderungen werden auch diese verworfenen Auflösungen weiter im Repository gespeichert bleiben, aber bei der nächsten Anforderung des Bildes in der entsprechenden Auflösung wird diese neu berechnet werden.
Fazit: Es wäre eine sehr gute Idee, wenn Ihr die geänderte Auflösung mit einem neuen Namen anlegen würdet, da Ihr ansonsten massive Probleme mit den bereits vorberechneten Auflösungen bekommen werdet!
Hinweis: Um das Repository kleiner zu bekommen, besteht die Möglichkeit, eine Archivierung des Projektes durchzuführen. Das geht über entsprechende Aufträge und führt dazu, dass nicht mehr benötigte Informationen aus dem Projekt entfernt werden. Natürlich stehen diese Informationen anschließend dem projekt (bis zum Wiedereinspielen des Backups) nicht mehr zur Verfügung, so dass zum Beispiel eine historische Generierung oder das Wiederherstellen einer alten Version/eines gelöschten Objektes zu Problemen führen kann.
Viele Grüsse aus Dortmund,
Holger
Hallo Matthias,
Matthias Marm schrieb:
Hallo Community,
bei einem Kunden machen wir gerade ein ReDesign mit neuer Rasterlogik. Dafür müssen wir dann bei der Umstellung die alten Auflösungen mit den neuen Werten anlegen (ändern geht ja nicht in FirstSpirit, oder hat sich dawas getan?) Jetzt kam die Frage auf, ob sich das auf den benötigten Speicherplatz auf dem FS Server auswirkt. Laut dem technischen Ansprechpartner auf Kundenseite werden wohl die Auflösungen für jedes Medium direkt in der Berkely DB gespeichert (wusste ich vorher nicht 😉 und bei der Generierung lediglich ins Staging kopiert.
Wenn dem so ist, weiß jemand, wie sich das neue Anlegen auswirkt? Gibt es für die Auflösung der Medien dann auch eine Art Versionierung, so dass sich das Datenvolumen in der DB drastisch erhöht? Bei der Generierung sollte es ja keine Probleme geben, denn da werde nur die aktiven Auflösungen generiert, oder?
Die Auflösungen ändern sich natürlich nur marginal, etwaige Schwankungen des Datenvolumens wegen dieser Änderungen sind dann natürlich auch zu erwarten. Es geht vorrangig darum, dass jetzt nicht auf einmal das doppelte an Datenvolumen für die Medien auf dem FS Server benötigt wird.
Vielen Dank fürs Feedback und viele Grüße
Matthias
Also, der Satz
> Dafür müssen wir dann bei der Umstellung die alten Auflösungen mit den neuen Werten anlegen?
ist ein größeres Problem
Um das zu erklären, muss ich etwas ausholen:
Die Aussage, das die Auflösungen direkt im Repository gespeichert werden, ist nur bedingt korrekt. Es werden dort nur die bereits berechneten Auflösungen (und natürlich die manuell hinzugefügten) gespeichert. eine Auflösung wird nur dann berechnet, wenn Sie benötigt wird.
Das bedeutet also zum Beispiel, dass bei einer Generierung/Vorschau geprüft wird, ob zu dem für diese Aktion gültigen Originalbild bereits eine berechnete Auflösung vorliegt. Wenn ja, so wird diese direkt aus dem Repository gestreamt. Wenn nein, so wird diese Auflösung neu berechnet, im Repository gespeichert und dann daraus gestreamt.
Die Prüfung, ob eine Auflösung vorhanden ist oder nicht, geschieht über deren Referenznamen.
Kommen wir zum Problem (und einem der Gründe, warum Auflösungen nicht geändert werden können):
Wenn Du eine Auflösung löscht, ändert sich erst einmal nichts an den bereits vorhandenen Medien.
Wenn Du nun die Auflösung mit dem selben anmen, aber anderen Werten neu anlegst, ändert sich wieder nichts an den bereits vorhandenen Medien.
Anmerkung: Du WILLST auch gar nicht, dass sich hier etwas ändert, da die Aktion ansonsten entsprechend lange dauern müsste. {Das war in der Version 3.1 der Fall und da konnten gewisse Projektänderungen in größeren Medienprojekten auch mal einige Stunden dauern, was dann meistens zum Abbruch der entsprechenden Aktion durch den Administrator führte}
Also haben wir nun den Stand, dass es eine Auflösung mit geänderten Werten gibt, für viele der vorhandenen Bilder aber bereits ein berechnetes Bild für genau diese Auflösung vorhanden ist.
Bei der nächsten Generierung wird für diese Bilder geprüft, ob es für die entsprechende Auflösung bereits ein Bild gibt (Ja) und dann wird dieses Bild gestreamt. Leider hat es nun die falschen Maße.
Auflösungen für ein Bild werden nur verworfen, wenn sich die Originalauflösung des Bildes ändert. [Und auch dann werden nur automatisch berechnete Auflösungen verworfen, keine manuell eingestellten]
Anmerkung: Wie alle anderen Änderungen werden auch diese verworfenen Auflösungen weiter im Repository gespeichert bleiben, aber bei der nächsten Anforderung des Bildes in der entsprechenden Auflösung wird diese neu berechnet werden.
Fazit: Es wäre eine sehr gute Idee, wenn Ihr die geänderte Auflösung mit einem neuen Namen anlegen würdet, da Ihr ansonsten massive Probleme mit den bereits vorberechneten Auflösungen bekommen werdet!
Hinweis: Um das Repository kleiner zu bekommen, besteht die Möglichkeit, eine Archivierung des Projektes durchzuführen. Das geht über entsprechende Aufträge und führt dazu, dass nicht mehr benötigte Informationen aus dem Projekt entfernt werden. Natürlich stehen diese Informationen anschließend dem projekt (bis zum Wiedereinspielen des Backups) nicht mehr zur Verfügung, so dass zum Beispiel eine historische Generierung oder das Wiederherstellen einer alten Version/eines gelöschten Objektes zu Problemen führen kann.
Viele Grüsse aus Dortmund,
Holger
Hallo Matthias,
Matthias Marm schrieb:
Hallo Holger,
vielen Dank für die ausführliche Antwort!
Holger Höbbel wrote:
Anmerkung: Du WILLST auch gar nicht, dass sich hier etwas ändert, da die Aktion ansonsten entsprechend lange dauern müsste. {Das war in der Version 3.1 der Fall und da konnten gewisse Projektänderungen in größeren Medienprojekten auch mal einige Stunden dauern, was dann meistens zum Abbruch der entsprechenden Aktion durch den Administrator führte}Da hier größtenteils RemoteMedia zum Einsatz kommt werden sowieso immer sämtliche Auflösungen aller verwendeten Medien generiert, deshalb wird es wohl genauso lange dauern, bis die mit neuem Namen angelegten Auflösungen generiert sind, wie die mit gleichem Namen, also eigentlich würde ich es schon wollen 😉
Das ist leider ein Missverständnis. Ich meinte, dass das Klicken auf den OK Knopf in der Admin-Konsole, mit dem Du die Änderung der Auflösung bestätigst, dazu führt, dass die Admin-Konsole für einige Stunden einfriert.
Natürlich kannst Du mir jetzt antworten, dass man da doch einen Thread im Hintergrund starten könnte, der die Änderung für alle Medien übernimmt. Dann würde ich Dir aber antworten, dass Du ja direkt danach eine zweite Änderung an der selben Auflösung (diesmal die Neuanlage) durchführen willst. Wenn auch hier ein Thread im Hintergrund gestartet würde, kann ich förmlich die entsprechenden Tickets im helpdesk bereits sehen, da es dabei garantiert zu Timing Problemen kommen würde.
Beide Änderungen zusammen durchzuführen könne hierbei klappen, aber die obige Möglichkeit würde ja weiterhin gehen - und würde auch garantiert irgendwann benutzt werden .
Matthias Marm schrieb:
Holger Höbbel wrote:
Anmerkung: Wie alle anderen Änderungen werden auch diese verworfenen Auflösungen weiter im Repository gespeichert bleiben, aber bei der nächsten Anforderung des Bildes in der entsprechenden Auflösung wird diese neu berechnet werden.
Heißt das am konkreten Beispiel (Name der Auflösung "col_1"):
bild_col_1.jpg ist in Repository --> Auflösung löschen + neu anlegen + Originalauflösung von "bild" ändern + erneute generierung in RemoteMedia(=alle Auflösungen angefordert) --> bild_col_1.jpg(ALTE col_1) weiterhin in Repository UND bild_col_1.jpg (NEUE col_1) in Repository oder nur die Neue? Wenn letzteres der Fall wäre, wäre das Wiederverwenden der alten Auflösung ja für die Datenmege im Repository doch sehr entscheidend. Wenn nicht macht die Datenmenge mit neuer statt wiederverwendeter Auflösung ja keinen Unterschied, oder?
Ergänzende Frage: reicht es das Medium in den Bearbeitunsmodus zu setzen und erneut freizugeben um die Auflösung neu zu berechnen oder werden da die Hashwerte des Originals verglichen? Sonst könnte man doch so evtl. ein bisschen tricksen, oder?
Bei deinem konkreten Beispiel würden beide Auflösungen im Repository verbleiben. [Oder genauer - solange keine Archivierung gestratet wird, bleiben _immer_ alle Informationen im Repository gespeichert.
Zur ergänzenden Frage: Nein, das reicht nicht. Es muss das Originalbild geändert werden. Ich bin mir hier aber sehr sicher, dass ein "einfaches" Neueinpflegen des exakt selben Bildes ausreichend sein würde. Wenn Du tricksen willst, wäre es aber "resourcenschonender" wenn Du die alten Auflösungen mit einem externen Bild "überschreibst" und dieses danach wieder löscht (zum Beispiel ein 1 Pixel großes gif). Das führt dann auch dazu, dass bei der nächsten Anforderung der Auflösung diese neu berechnet wird.
Wenn Du ein entsprechendes Skript tatsächlich schrieben solltest, wäre ich Dir sehr dankbar, wenn du das hier ablegen würdest 
Viele Grüsse aus Dortmund,
Holger
Hallo Matthias,
Matthias Marm schrieb:
"Abbildung 7-86: Neue Auflösung hinzufügen Nachdem eine neue Auflösung hinzugefügt wurde, müssen alle Medien in der Medien-Verwaltung erneut freigegeben werden.
Die Namen bereits gelöschter Auflösungen dürfen nicht wieder verwendet werden, da sonst Medien übernommen werden könnten, die nach der gelöschten Auflösung berechnet wurden."
Habe in einem Testprojekt eine neue Auflösung hinzugefügt, danach war diese bei den Medien vorhanden, aber die Medien waren auch alle weiterhin (oder bereits) freigegeben. Was bedeutet das im Kontext der obigen Aussage?
Ich weiß jetzt nicht, wie ich es am besten umschreiben soll. Sagen wir es mal so - diese Aussage bezieht sich eher auf FirstSpirit Versionen, bei denen die Verwaltungen noch nicht auf Massendatenfestigkeit programmiert waren. Ab der Version 4 ist dies eigentlich nicht mehr notwendig.
Matthias Marm schrieb:
Ein weiteres Thema ist das Hinzufügen der Auflösungen bei einem recht großen Datenbestand (u.a. auch weil RemoteMedia).Gibt es da irgendwelche Richtwerte, wie sich das auf das erneute Generieren auswirkt?
Habe vom Kunden gehört, dass wohl damals (war evtl. glaub ich sogar noch 3.1) bei der Mediengenerierun der Server ne Woche beschäftigt war. Ist natürlich schon ein bisschen her (auch hardwaremäßig 🙂
Da aber eben jetzt neue Auflösungen anstehen (mindestens erst einmal 7) müssen wir Feedback geben, was das für den FS-Server an Auswirkung haben könnte.
Eine haben wir ja oben bereits festgehalten --> größerer Datenbestand im Repository
Bin aber für jede weitere Info dankbar, denn wie sich das System in solchen Situationen intern verhält haben wir ja leider keine Ahnung.
Die Generierung wird länger dauern, da ja alle Bilder in den 7 neuen Auflösungen skaliert werden müssen.
Einen Richtwert kann ich nicht angeben, da dies natürlich von der Anzahl der Bilder, deren Größe und der Rechenleistung des FirstSpirit Servers abhängt.
Die Dauer der Berechnung steigt linear mit der (Anzahl der zu berechnenden Bilder) mal (neuen Auflösungen) an, wenn alle Bilder exakt gleich groß sind [was natürlich nicht der Fall ist].
Wenn Du eine ganz grobe Abschätzung haben willst, kannst du entweder eine Teilmenge mit den neuen Auflösungen generieren (das brauchst du dann nur mit dem Faktir zur Gesdamtzahl der Medien multiplizieren) oder Du kannst die neuen Auflösungen von typischen Bildern berechnen lassen und die Zeit stoppen. Dummerweise läuft diese Berechnung aber auf dem client, so dass Du dann noch zusätzlich die unterschiediche Geschwindigkeit zwischen Client udn Server in die Berechnung einfließen lassen musst
Viele Grüsse aus Dortmund,
Holger
