Latino schrieb
Werde eventuell eine ältere ImageMagick-Version manuell auf dem Server installieren und über Install-Tool darauf referenzieren (bis die Ursache gefunden und gelöst wurde).
Ich hatte gestern bereits testhalber die aktuelle Version von ImageMagick (6.7.6-9) selber gebaut und per localconf.php eingebunden.
Die Tests im Install-Tool liefen damit alle problemlos (ebenso wie bei der vorinstallierten Version), die Thumbnails und sonstigen Bilder wurden aber auch dadurch nicht wiederhergestellt.
Eventuell ist wirklich eine ältere Version erforderlich, aber die Tatsache, dass von der Kommandozeile aus alle Versionen gleich gut zu funktionieren scheinen, lässt mich daran zweifeln.
Skyrock schrieb
Also ich hatte das Problem heute auch, das bei einem Kunden der seine Seite bei 1und1 hostet, das Scanning der Thumbs defekt war.
Da alle neue Konfigurationsversuche von ImageMagick keine Auswirkungen auf das Scaling Problem hatten, habe ich kurzerhand die Extension "JB GD Resize" als Workaround installiert. Diese benutzt die gdlib_2 zum Skalieren der Bilder. Und siehe da, alles erstmal wieder "Tutti".
Hallo, kann ich bestätigen - damit funktioniert es hier ebenfalls wieder.
1&1 hat das Problem gelöst - Zitat aus dem 1&1 Forum (forum.1und1.de):
1&1 Supportforum schrieb
ImageMagick (/usr/bin/convert) fordert für die Bildoperation zuviel Hauptspeicher an. Der Prozess bricht dann ab, dem PHP-Skript fehlt die Ergebnis-Bilddatei und es kommt zu einer Fehlermeldung bzw. das Bild wird nicht angezeigt.
....
Die alte Version von ImageMagick (6.2.4) hat wohl weniger Speicher verbraucht als die neue (6.6.0-4).
Für eine Reduzierung des Speicherverbrauches müssen Sie die Resource "thread" auf das Minimum setzen -- auf 1. Gleichbedeutend mit "thread" ist die environment varable MAGICK_THREAD_LIMIT.
Lösung: tragen Sie in das PHP-Skript die Zeile ein:
putenv('MAGICK_THREAD_LIMIT=1');
Bei anderen Skriptsprachen setzen Sie einfach die Umgebungsvariable MAGICK_THREAD_LIMIT auf 1.
Erläuterung: ImageMagick ist eine Software-Suite für Unix-Grafik-Workstations. Auch das Programm "convert" ist für die Verarbeitung sehr großer Datenmengen auf Computern mit entsprechend viel Hauptspeicher und Plattenspeicher ausgelegt. Als Hilfsprogramm im Rahmen einer Webanwendung, wo der Hauptspeicher oder die Prozessorleistung begrenzt sind, stößt es dann an gesetzte Grenzen. Vor allem beim Shared-Hosting ist die erwähnte Anpassungen nötig. Weiteres siehe http://www.imagemagick.org/script/architecture.php und http://www.imagemagick.org/script/resources.php.
Hab die Anweisung oben in die localconf.php eingetragen, Cache löschen und ging sofort wieder.
martinjursa schrieb
1&1 hat das Problem gelöst - Zitat aus dem 1&1 Forum (forum.1und1.de):
1&1 Supportforum schrieb
ImageMagick (/usr/bin/convert) fordert für die Bildoperation zuviel Hauptspeicher an. Der Prozess bricht dann ab, dem PHP-Skript fehlt die Ergebnis-Bilddatei und es kommt zu einer Fehlermeldung bzw. das Bild wird nicht angezeigt.
....
Die alte Version von ImageMagick (6.2.4) hat wohl weniger Speicher verbraucht als die neue (6.6.0-4).
Für eine Reduzierung des Speicherverbrauches müssen Sie die Resource "thread" auf das Minimum setzen -- auf 1. Gleichbedeutend mit "thread" ist die environment varable MAGICK_THREAD_LIMIT.
Lösung: tragen Sie in das PHP-Skript die Zeile ein:
putenv('MAGICK_THREAD_LIMIT=1');
Bei anderen Skriptsprachen setzen Sie einfach die Umgebungsvariable MAGICK_THREAD_LIMIT auf 1.
Erläuterung: ImageMagick ist eine Software-Suite für Unix-Grafik-Workstations. Auch das Programm "convert" ist für die Verarbeitung sehr großer Datenmengen auf Computern mit entsprechend viel Hauptspeicher und Plattenspeicher ausgelegt. Als Hilfsprogramm im Rahmen einer Webanwendung, wo der Hauptspeicher oder die Prozessorleistung begrenzt sind, stößt es dann an gesetzte Grenzen. Vor allem beim Shared-Hosting ist die erwähnte Anpassungen nötig. Weiteres siehe http://www.imagemagick.org/script/architecture.php und http://www.imagemagick.org/script/resources.php.
Hab die Anweisung oben in die localconf.php eingetragen, Cache löschen und ging sofort wieder.
Vielen Dank für die Info, jetzt funktioniert bei mir auch alles wieder und große Bilder, die vorher nicht skaliert werden konnten, gehen jetzt sogar auch!
martinjursa schrieb
putenv('MAGICK_THREAD_LIMIT=1');
Hab die Anweisung oben in die localconf.php eingetragen, Cache löschen und ging sofort wieder.
Wie bzw. wo hast du die Anweisung denn dort eingebunden? Soweit ich weiß liest Typo3 doch nur die Variablen aus der localconf.php aus und generiert dann eine eigene localconf Datei. Gehen manuelle Anweisungen dann nicht wieder verloren?
akonze schrieb
Wie bzw. wo hast du die Anweisung denn dort eingebunden? Soweit ich weiß liest Typo3 doch nur die Variablen aus der localconf.php aus und generiert dann eine eigene localconf Datei. Gehen manuelle Anweisungen dann nicht wieder verloren?
Nein, du musst nur nach der Änderung den Konfigurations-Cache leeren; kannst es auch händisch machen indem du die ganzen temp_CACHED_* Files im typo3conf Verzeichnis löschst.
Beim nächsten Aufruf werden dann die effektiv genutzten localconf's neu erzeugt.
Solltest deine Anweisung oberhalb des Kommentars
## INSTALL SCRIPT EDIT POINT TOKEN
platzieren.
Problem gelöst!
Danke, ich habe nämlich noch keine Antwort von 1&1.
Für alle die sich nicht so gut auskennen, hier nochmal die genaue Beschreibung:
Im Ordner /typo3conf/ die Datei localconf.php öffnen. In etwa nach der 11. Zeile den Befehl
putenv('MAGICK_THREAD_LIMIT=1');
eintragen und wieder speichern.
Das sieht dann in etwa so aus:
<?php
$TYPO3_CONF_VARS['SYS']['sitename'] = 'xxx';
// Default password is "xxx" :
$TYPO3_CONF_VARS['BE']['installToolPassword'] = 'xxx...';
$TYPO3_CONF_VARS['EXT']['extList'] = 'tsconfig_help,context_...';
$typo_db_extTableDef_script = 'extTables.php';
## INSTALL SCRIPT EDIT POINT TOKEN - all lines after this points may be changed by the install script!
putenv('MAGICK_THREAD_LIMIT=1');
$typo_db_username = 'xxx'; // Modified or inserted by TYPO3 Install Tool.
$typo_db_password = 'xxx'; // Modified or inserted by TYPO3 Install Tool.
Oft funktioniert das dann sofort wieder, ansonsten wie von "martinjursa" beschrieben den Cache löschen.
hi,
das muss *vor* den Kommentar, nicht dahinter!
Alles *nach* dem Kommentar kann vom Install-Tool überschrieben werden ( "all lines after this points may be changed by the install script" )
Diese Einstellung hilft, damit Thumbnails von PNG und JPG Dateien wieder korrekt generiert werden.
putenv('MAGICK_THREAD_LIMIT=1');
Allerdings lassen sich keine Thumbnails von GIF-Dateien generieren. Sobald diese skaliert werden müssen, klappt das nicht. Kann man auch im Install Tool beim GIF to GIF Test (Image Processing > Scaling images > GIF to GIF) sehen.
Habt ihr das gleiche Problem bzw. hat dafür schon jemand eine Lösung?
Die eingesetzte TYPO3 Version ist hier noch eine 4.4
Bei mir hat der Eintrag
putenv('MAGICK_THREAD_LIMIT=1');
zur Folge das die Grafiken im Frontend wieder angezeigt werden.
Im Backend funktioniert die Thumb Generierung bei mir aber nach wie vor nicht.
Verwendete Version ist 4.4
Also das gleiche Problem wie bei Chapi
Gleiches Problem hier.
Mein Provider hat am Server die Prozessanzahl von 64 auf 128 erhöht. Seither klappt es.
zabinetta schrieb
hab das Problem auch.
keine thumbnails, viele Bilder verschwunden. Gifbuilder-Sachen gehen nicht mehr
$TYPO3_CONF_VARS['GFX']['thumbnails_png'] = '1' //hatte auch 3 probiert, thumbs werden noch immer nicht gerendert
$TYPO3_CONF_VARS['GFX']['gif_compress'] = '0'
$TYPO3_CONF_VARS['GFX']['gdlib_png'] = '1'
$TYPO3_CONF_VARS['GFX']['jpg_quality'] = '100'
$TYPO3_CONF_VARS['GFX']['png_truecolor'] = '1'
danach hat er wieder skalierte Bilder gebracht, und die cron_csc_imgframes sind wieder gerendert worden. die Gifbuilder-Sache konnte ich mit einem angepassten imageframe lösen.
toll ist das natürlich nicht, auch daß 1und1 kein php 5.3 hat. Klar nicht der Typo3provider der Wahl, aber bei dem betroffenen Site heißt meine Perspektive erstmal abwarten, wenns nicht schlimmer wird, komm ich bei diesem Site klar.
Danke!
Diese Einstellungen haben bei mir geholfen. Und zwar ging es auch um ein GIFBUILDER Objekt, welches einen TEXT mit font und so als Grafik rendert, mit transparentem Hintergrund. Jedoch war hier der Hintergrund schwarz, ebenso im Test "scaling images" im install tool.
Nun passt das wieder.
Nochmals danke und viele Grüße
merzilla
Danke! Bei meinem Problem mit 1und1 dual basic hat mir folgendes geholfen:
putenv('MAGICK_THREAD_LIMIT=1');
gruß - alex
Seid heute werden bei mir wieder keine Thumbs generiert 🙁
putenv('MAGICK_THREAD_LIMIT=1');
Hatte bisher das Problem gelöst, aber seid heute Abend ca 16 Uhr gehts nicht mehr.
Haufenweise verschiedene Installationen betroffen an denen nichts an der Konfiguration geändert wurde ....
FabianX schrieb
Seid heute werden bei mir wieder keine Thumbs generiert 🙁
putenv('MAGICK_THREAD_LIMIT=1');
Hatte bisher das Problem gelöst, aber seid heute Abend ca 16 Uhr gehts nicht mehr.
Bitte nicht so viele Informationen auf einmal.
Typo3 Version?
Imagemagick Version?
Webhoster?
Hosting Paket?
localconf.php?
Was sagt der Hoster?
Was sagt das Typo3 Log?
usw...
Ja das war etwas kurz gefasst 🙂
Ich dachte hier wird explizit auf das Problem bei 1und1 eingegangen.
Typo3 4.5.22
Hoster ist 1und1.
Dedicated Managed Server
In der Localconf habe ich in den letzten Monaten keine Änderungen vorgenommen.
putenv('MAGICK_THREAD_LIMIT=1'); steht noch drin.
/usr/bin/ (6.6.0-4)
Hoster hat leider nicht geantwortet.
Typo3 Log beim anlegen:
Record '[No title]' (tt_content:931) was inserted on page 'beispeil' (236) (msg#1.1.10)
Alle Tests im Install Tool bei Image Processing sind erfolgreich.
Hat grad sonst noch jemand bei 1und1 Probleme mit der Thumbs-Generierung ?
Wenn ich die thumbs.php direkt mit dem Link aus dem Backend aufrufe bekomme ich folgende Fehlermeldung:
Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/.../typo3/typo3conf/localconf.php:1) in /www/htdocs/.../typo3/t3lib/thumbs.php on line 257