Als Filter wähle (sinngemäß) ich “Alle Vorgänge berücksichtigen, die noch nicht in den Archivspeicher verschoben wurden”. Damit erfasse ich alle Vorgänge, die noch mindestens einen offenen Schritt im Workflow enthalten.
Die Trefferanzahl ist korrekt. Allerdings stimmt die “Gesamtgröße der Master-Dateien” nicht. In der Liste werden Vorgänge mit “Größe der Master-Dateien” 0 B angezeigt, die defintiv mehrere GB an TIFF-Dateien enthalten.
Stimmt meine Annahme, dass der Wert hier erst berechnet/ angezeigt wird, wenn der Vorgänge im Workflow-Schritt “Metadatenerschließung” angekommen sind?
Wenn ich richtig liege, braucht es ein Update des Datenbank-Caches.
Probiere das für einen beliebigen Vorgang, der 0 B anzeigt, einmal aus mit dem folgenden GoobiScript: (ich habe gestern den gesamten Cache mit nur 8000 Vorgängen aktualisiert, das hat 6 Stunden gedauert.)
---
# This GoobiScript ensures that the internal database table of the Goobi database is updated with the status of the workflows and the associated media files as well as metadata from the METS file.
action: updateDatabaseCache
Du hast recht, das war der Grund. Vielen Dank für die schnelle Hilfe. Jetzt müßte man das skript nur noch an geeigneter Stelle in den Workflow einbinden, um es nicht immer manuell starten zu müssen.
@steffen und @robert.sehr , wo wäre das denn am sinnvollsten? Direkt nach dem übertragen der Masterdateien in Goobi workflow? Oder nach dem erzeugen der Derivate?
ich werde es nach “Image Convert” o.ä. Aufgabenschritten reinhängen. (und vlt. auch als abschliessender Schritt nochmal wiederholen) Veränderungen des Speicherbedarfs durch Metadaten-File-Bearbeitung können unter den Tisch fallen.
Ich hab mir das bei uns angesehen. Im Großen und Ganzen stimmen die Zahlen in dem Report. Deshalb frage ich mich, wie es passieren kann, dass der DB-Cache so asynchron wird und das Update gezielt angestoßen werden muss. Sollte das nicht nur in Ausnahmefällen nötig sein? Oder habt ihr Workflowschritte, bei denen das systematisch passiert?
also bei uns sind einmal grundsätzlich immer 0 Byte Speicherverbrauch bei allen Vorgängen. Wir haben S3-Storage, da ist immer alles anders - daher verwundert es mich nicht, dass es nicht automatisch berechnet wurde.
Aber klar, eigentl. wäre dieser Cache natürlich schön, er würde immer wieder an verschiedenen Stellen automatisch neu gefüllt, bei allen Schritten mit Schreibprozessen etc.
S3 ist natürlich anders
Aber die Fälle, wo ich sehe, dass es auseinanderläuft geschehen meiner Beobachtung nach dort, wo »an Goobi vorbei« mit Skripten oder direkt im Dateisystem herummanipuliert wird (da bin ich in unserem Fall aber auch selber schuld).
Ein Hinweis von @robert.sehr in der Sache hat mir gerade ein großes Stück weitergeholfen. Man kann das “Problem” auch ohne ein manuell ausgelöstes Goobi-Script lösen. In der Vorgangsvorlage bei den Aufgabendetails (aller relevanten Schritte) einfach hier ein Häkchen setzen:
- daher verwundert es mich nicht, dass es nicht automatisch berechnet wurde.
