4images Forum & Community
4images Issues / Ausgaben => Discussion & Troubleshooting => Topic started by: polarfuchs on May 20, 2009, 09:23:19 AM
-
Hallo, seit ca. 2-3 Wochen habe ich ein Problem mit meiner Galerie:
es häufen sich die Beschwerden meiner registrierten Besucher, daß sie gezippte Dateien entweder gar nicht mehr (Download bricht ab) oder nur "corrupt" oder mit der Meldung "archive is not complete" (=via WinRAR) erhalten, wenn der Download doch mal startet. Nachdem das in meiner 4jährigen 4images Laufzeit noch nie dagewesen ist, bin ich ziemlich ratlos, wo ich nach der Fehlerquelle suchen soll. Bei mir? Bei der Software meiner Besucher?
Meine Dateien sind natürlich vollständig, wenn ich sie via FTP als Zip-Dateien auf meinen Server (Strato) hochlade. Strato hat mir ebenso versichert, sie hätten keinerlei Limit in Bezug auf die Größe der Dateien bei meinem Paket.
Auch die timeout session im ACP habe ich gecheckt, die steht bei 60 Minuten.
Der Witz an der Sache ist, daß ich, wenn ich mich als Testuser (nicht als Admin) einlogge, alle Dateien problemlos und vollständig herunterladen kann. Erst dachte ich, daß einige meiner Besucher vielleicht nur Probleme mit großen Dateien (20 - 70MB) haben, aber jetzt bekomme ich das Feedback, daß dies auch wesentlich kleinere Dateien betrifft.
Jetzt habe ich in diesem Post hier etwas über RESUME CAPABILITY gelesen - könnte das eventuell auch bei mir zutreffen?
http://www.4homepages.de/forum/index.php?topic=24733.0
Ich bitte dringend um einen Fingerzeig, wo ich hier ansetzen muß, um das wieder in den Griff zu kriegen.
Chris
-
Hallo,
gehe mal ins ACP -> Allgemein -> Einstellungen, und setze den GZip Kommressionslevel auf 0
Hatte auch das Problem, seiher ist es weg.
Das hängt auch mit der übertragung zusammen, da werden immer paar Byte ausgelassen.
nobby
-
Hallo nobby - vielen Dank für deinen Tip, aber das ist es nicht. GZip-compression hatte ich noch nie aktiviert und steht seit eh und jeh auf "0".
Ich habe seit ca. 1/2 Jahr die Vers. 1.7.6 am laufen und seit dem Update die Settings im ACP nicht mehr angerührt, weil ja alles prima funktioniert hat. Bis jetzt.
Problematik:
Ich habe weder an der Art und Weise, wie ich meine Files zu Zip-Dateien packe und auf meinen Space bei Strato hochlade, noch an den Settings im ACP irgendetwas verändert.
ICH als eingeloggter Test-User kann alle Zip-Files einwandfrei runterladen.
Aber etliche meiner registrierten User*) sagen mir, sie laden entweder kaputte Files runter (WinRAR= "file is corrupt" oder "archive is not complete"), bzw. oft geht es gar nicht, der Download bräche ab... aber auf anderen Seiten im Netz könnten sie "noch viel größere Dateien ruckizucki downloaden"...
*) nicht alle!! aber in den letzten Tagen kommen immer mehr mit diesem Problem auf mich zu - das ist vielleicht wichtig
Diese User suchen den Fehler natürlich auf meiner Seite, bzw. bei meiner Galerie. Aber wenn er überhaupt hier zu suchen ist, dann wo??
Hat sowas denn noch nie jemand erlebt, der mir sagen könnte, wo er angesetzt hat, damit es wieder funktioniert?
-
wenn Du nichts geändert hast, kann es nur noch an Strato liegen.
-
Strato meint, ich könnt' sie totschlagen (darüber sollte ich vielleicht noch mal ernsthaft nachdenken...), aber sie hätten absolut nix an meinem Space geändert und sie wären total unschuldig.
Und wie erklärst du dir, daß ICH als Test-User einwandfrei in der Galerie zugange sein kann, aber andere reg. User reklamieren mit den vorstehend beschriebenen Aussagen??
DAS ist ja gerade der springende Punkt den ich irgendwie in den Griff kriegen muss.
-
Sag mal, kann es sein, das ein paar der Bilder gar nicht bei dir, in der Galerie, sondern auf einem anderen Server, bei anderen Anbietern sind??
Die als zip-File herunter zu laden wird dann für 4images nicht einfach, um nicht zu sagen, das geht nicht!
Bei einem Detail hat sich sofort der Fremdserver angemeldet, aber ich hab nicht weiter getestet!
-
@honda
Fremdserver? Nein, ich hoste alle gezippten Dateien, die für die registrierten User bestimmt sind, bei Strato.
Es gibt allerdings auch einen Freebie-Bereich für unregistrierte Besucher, aber dessen Dateien sind nur durch einen vollständig ausgeschriebenen Link unterhalb des Detail Images downloadbar (4shared). Aber diese Dateien betrifft es auch nicht. Es geht nur um die, die meinen registrierten Nutzern via Strato zur Verfügung stehen.
Könntest du mir das mit dem Fremdserver nochmal genauer erläutern bitte?
-
Ich hab wahllos 5 Bilder geladen, alle gingen!
Versuch mal rauszufinden, welche Dateien (Bilder) es betrifft!
Eventuell sehr große (kb) so das nicht gezipt werden konnte!
-
Hi honda,
danke erst mal fürs testen. Aber du hast aus dem Freebie Bereich runtergeladen, diese Dateien betrifft es nicht. Nur die, die ausschließlich registrierten Usern zur Verfügung stehen und da komischerweise wirklich meistens nur die großen Dateien (ab 20MB aufwärts bis 70MB). Und zippen tu ich selber vor dem Raufladen mit WinRAR, das macht nicht 4images.
Ich kapier halt nur nicht, wieso ich als eingeloggter und registrierter Testuser alles einwandfrei runterlade, aber andere registr. User Probleme haben. Man sollte doch meinen, Datei und Download ist immer gleich für jeden...
Könnte so ein Fehler auch von irgendeiner Browsereinstellung beim User kommen? Auch dachte ich zeitweise, vielleicht hat der ISP bei dem einen oder anderen User die Downloadmenge, bzw. -geschwindigkeit irgendwie beschränkt, deshalb der vorzeitige Abbruch bei großen Dateien. Aber die User versichern mir, sie laden woanders noch viel größere Dateien runter und alles problemlos.
-
Das kann am packen selber, natürlich aber auch am download liegen!
Man müsste das wirklich genau austesten!
z.b. kan bei langsamen Übertragungsgeschwindigkeiten eine Zeitüberschreitung den Download unterbrechen. Merkt der User aber gar nicht, siehts dann nur am Ergebnis: fehlerhafte Datei
-
danke schön für die Zeit, die du dir nimmst.
Kann ich das so verstehen, daß du auch der Meinung bist, daß dieses Problem aus der User Ecke herrührt? Mal immer davon ausgegangen, daß meine Zips ok sind, und das sind sie - alle auf Herz und Nieren getestet. Was sollte man da auch viel falsch machen können? Immerhin läuft meine Galerie schon ein paar Jahre und erst kürzlich gabs die ersten Komplikationen.
Ich habe übrigens gestern das Statement des technischen Supports bei Strato bekommen: Sie haben alles getestet und melden: Alles paletti mit meiner Galerie/Datenbank und den Downloads. Keine Download Probleme.
Ich kann jetzt also nichts weiter tun, als meinen Usern einen Packen mögliche Fehlerbehebungsursachen (tolles Wort) an die Hand zu geben? Angefangen bei der erwähnten Zeitüberschreitung beim Download bis hin zum Browserwechsel? Und wenn's dann immer noch nicht geht, mich von diesem User verabschieden, weil keiner weiss, wo das Problem liegt?
Ich weiss, das ist ein sehr schwammiger Fehler, der da auftritt (aber er ist halt nun mal da), hinter dem alles mögliche liegen kann, aber dass man da so gar nicht den Finger drauflegen kann wo's hakt... Ich kann dem User ja schlecht empfehlen, eine komplette Neuinstallation seines Systems vorzunehmen (wie ich das in verschiedenen Foren bereits gelesen hatte!).
Sollte noch jemand eine Idee haben, wo ich (oder der User) suchen muss: ich bin für alle Tips dankbar!
-
HALT! STOP! NEUER SACHVERHALT!
Soeben bin ich der Fehlermeldung über ein Zip nachgegangen, das leer heruntergeladen wird. Ich habe mich als Admin eingeloggt, mir den kompletten Downloadstring in ein neues Browser Fenster kopiert und die Datei einwandfrei geholt auf diese Weise.
Danach habe ich mich als Testuser eingeloggt und nun über den Download Button versucht, das Zip zu laden, aber jetzt bekomme ich ebenfalls nur eine leere Datei, die im Bruchteil einer Sekunde runterläd!
Hilfe! Der Downloadlink ist doch via Button genau der gleiche wie der, den ich mit copy/paste eingegeben habe. Oder kann der Button irgendwas verhackstücken??
DAS ist doch jetzt was Konkretes, kann mir jetzt einer was dazu sagen bitte?
-
Hi, der Downloas-Zip-Button ist wie folgt definiert:
<a href="./download.php?action=zip&image_id=xxx"><img src="./templates/default/images/download_zip.gif" border="0" alt="" /></a>
Also: öffne die download.php im Root der Galerie und packe in zip das Bild Nr.xxx, dabei tue dies in dem du das Blid: templates/default/images/download_zip.gif anzeigst.
RICHTIG????
Eine download.php aus dem Root kannst du dir aber nicht anzeigen lassen und einzeln öffnen (nicht ohne weiteres)
In der download.php steht unter anderem, steuere die includes/zip.php an und komprimiere das entsprechende Bild. In der Datei steht aber auch: breche diesen Vorgang nach 120 sec. ab!
@set_time_limit(120); wenn der Server nicht reagiert!
Kann also php-Zip, das Bild nicht in dieser Zeit komprimieren, kommt ein fehlerhafter Ordner bei User an! Der kann aber auch vor diesen 120 sec Komprimierung beim User angekommen, wenn der Server die download- /includes/zip.php nicht fehlerfrei ausführt! Oder die beiden dateien das entsprechende Bild nicht fehlerfrei "verpacken" können!
-
Hallo Honda!
Den Download-ZIP-Button habe ich schon längst aus dem Template gelöscht (meine Dateien liegen ja alle schon fertig gezippt auf dem Server). Es gibt nur noch den normalen Download-Button. Trifft auf den auch dieses 120 sec. Timeout zu? Und wenn ja, wäre das dann eine einleuchtende Erklärung, warum etliche User, die meinethalben noch mit Modem unterwegs sind, verhackstückte Dateien runterladen?
Übrigens habe ich festgestellt, daß immer wieder mal die Unterstriche "_" in den Dateinamen verschwinden - einfach so. Dort steht dann ein Leerschritt. Der Dateiname "PT_alpha_racing.zip" sieht dann z.B. so aus "PT_alpha racing.zip". Das ist natürlich auch ein Grund, warum man die Datei nicht mehr runterladen kann. Wie kann sowas passieren? Und nein, ich habe die Unterstriche nicht vergessen bei der Angabe der Download-Adresse, ich bin pingelig und kontrolliere alles doppelt und dreifach.
Eine download.php aus dem Root kannst du dir aber nicht anzeigen lassen und einzeln öffnen (nicht ohne weiteres)
na Gott sei dank :wink:
-
Ich kann dir natürlich nicht sagen, warum der Unterstrich verschwindet und sozusagen, die FALSCHE Datei herunter geladen wird. Aber, ich kann dir sagen, was beim Klicken auf den "normalen" Download-Button passiert.
<a href="./download.php?image_id=xxx"><img src="./templates/<dein-template-Ordner/images/download.gif" border="0" alt="" /></a>
...reicht dir die Antwort??
-
ob mir die Antwort reicht? ähem... nö... :oops: ich bin ja leider, leider nicht das, was man einen php-Durchblicker nennen könnte. Aber sei versichert, ich bin dir wirklich sehr, sehr dankbar, daß du dir die Zeit nimmst und mir zu helfen versuchst.
Sollte der gepostete String jetzt nur aufzeigen, beim 'normalen' Download Button gibt es kein lustiges Timeout, Download hier ohne Einschränkung seitens der php?
Übrigens hab ich mal eine Durchsicht aller 'gerügten' Dateien vorgenommen; so wie's aussieht betrifft es immer nur große Dateien, also über 25MB. Jetzt wär's natürlich genial gewesen, wenn ich die Info hätte, auch bei diesem DL-Button gibts ein Timeout und das wäre dann die Erklärung (die Hoffnung stirbt zuletzt...)
Das mit dem ZIP-DL-Button und dessen Timeout wäre ja schon was richtig Handfestes gewesen, wo man hätte ansetzen können (nur leider gibts den bei mir nicht). Wenn man jetzt sowas 'Handfestes' auch für die normalen Downloads auftun könnte... Wie gesagt, ich hab jetzt wirklich alles abgecheckt: meine Dateien und alles was dranhängt, hab Strato rund gemacht und deren technischen Support alles durchchecken lassen, hab meinen verfügbaren Space bei Strato verdoppeln lassen - und letzte Instanz seid halt jetzt ihr hier, in der Hoffnung, von euch Gurus kommt ein genialer Fingerzeig. Denn ich armes Würstchen weiss nicht mehr, welchen Stein ich noch hochheben muß, um was drunter zu finden.
-
Hi!
zeig mal die phpinfo.
mfg Andi
-
Wir haben doch 3 grundlegende Dinge festgestellt:
1. alle dateien super, nichts kaputt
2. Webserver super
3. es passiert nur bei sehr großen Dateien (MB) und nur manchmal
Wenn die upload bei 120 Schluss macht, wenn die daten nicht geladen sind, der user also ne langsame Übertragung hat, egal ob analog oder DSL, bekommt er eben, wie wo anders auch, ne defekte datei, das ist eben leider so!
Lediglich haben wir nicht herausgefunden, warum der name sich hin und wieder ändert, also der Unterstrich "verschwindet"!
-
ne defekte datei, das ist eben leider so!
@Honda
da muss ich Dir leider wiedersprechen. Alles hat ein Grund :|
Ich habe das problem selber mal gehabt, und es wurde durch meinen Sohn bereinigt.
Nur leider ereiche ich ihn momentan nicht, sonst wären wir weiter.
nobby
-
Du willst mir doch nicht glaubhaft versichern, das 4images beim herunterladen vom Server, über den Befehl: download, einen Zip-File der per FTP herauf geladen wurde, umbenennt!!??
Von mir aus, wenn die Orginale Datei ohne Unterstrich war, und der File angepasst wurde!
Aber wenn 4images so selbsständig und schlau wäre, wäre das der Inbegriff von Inteligenz!
Sicher ist ein Fehler vorhanden, aber keine in 4images, in einer PHP-Datei, sondern es liegt mal wie so oft, am Bediener, das heist an uns, dem Browser, dem Rechner, aber mit nichten an 4images!
-
Du musst mal richtig lesen was ich Zietiert habe, oder weisst Du nicht mehr was Du geschrieben hast?
Was hat die Fehler Aussage "ist mal eben so" mit dem Unterstrich zu tun.
Du als Dienstleister müsstest eigendlich wissen das jeder Fehler auch eine Ursachen hat, und den Gilt es halt
herrauszufinden. Das hat erst mal nichts mit 4images zu tun.
-
Also,
1. bin ich kein Dienstleister
2. hat eine defekte oder umbenannte Datei nichts mit 4images zu tun!
Der TO hat diese Aussage von Seitens seines Hosters sogar schriftlich!
Desweiteren wurde der Download-Zip-Button entfernt, dafür der Download-Button mit selbst erstellen Zips (per FTP) gefüttert! Nochdazu sind die Dateien oft größer als 25 MB!
Wo wollen wir anfangen??
Beim Zip-Programm?
Bei der Übertragung per FTP?
Bei der Namensvergabe des Bildes und des Zip-Fils?
Bei den Clienteinstellungen der USER?
Bei den Browsereinstellungen?
Bei der Internetverbindung der User?
Beim falschen Ansprechen der download.php?
Sonst ist ja alles paletti!
-
Hi!
...2. hat eine defekte oder umbenannte Datei nichts mit 4images zu tun!...
defekt nicht aber 4images benennt dateien schon um, z.b. wenn sonderzeichen im namen enthalten sind.
aber sowas passiert eigentlich schon beim "neue bilder checken", und nicht erst beim download.
das gleiche tun auch FTP programme, dort kommt es auf die einstellungen an.
ich warte immer noch auf die phpinfo vom TO, den dann wissen wir mehr.
bei so große datein was der TO zum download anbietet bin ich schon sehr skeptisch was die einstellungen der php.ini betrifft.
mfg Andi
-
hi Rembrandt,
defekt nicht aber 4images benennt dateien schon um, z.b. wenn sonderzeichen im namen enthalten sind.
aber sowas passiert eigentlich schon beim "neue bilder checken", und nicht erst beim download.
muss ich wiedersprechen... ;)
Dies passiert nur in der extended Version vom V@no
[EDIT]
zeile mit "neue bilder checken" zugefügt, da dies beim V@no's MOD passiert
-
Richtig!
(also beide Vorredner!)
-
Hi!
...Dies passiert nur in der extended Version vom V@no...
hm.. in der originalen habe ich gar nicht nachgeschaut, wobei ich diese funktion aber für sinnvoll halte...wie auch immer...
@nicky,weil wir gerade beim debuging sind, was sagst du dazu:
http://www.4homepages.de/forum/index.php?topic=21017.msg135686#msg135686
wie ich in diesen thread schon angemerkt habe besteht der fehler schon länger und noch immer.
mfg Andi
-
WOW! Hier ist ja richtig was abgegangen! Typisch: kaum dreht man sich mal um... :wink:
Also ich kann da noch folgendes dazusteuern, um vielleicht noch mehr von der Adminseite her ausschließen zu können:
Ich verwende die Galerie jetzt seit 2005 und zwar seit eh und je (problemlos) immer auf die gleiche Art und Weise:
Ich zippe meine Files mit WinRAR, bevor ich sie via FTP hochlade.
Sobald sie auf dem Server sind, teste ich den kompletten String, ob der Download funktioniert, denn auch ich mache mal Typos. Bis jetzt sind übrigens noch alle Unterstriche vorhanden.
Parallel lade ich per FTP unter "data/media" das Preview der jeweiligen Datei hoch.
Wenn der DL-String ok ist, gehe ich in mein ACP und rufe via "check new images" das neue Bild/Preview auf. Ich habe, seitdem ich die Vers. 1.7.6 verwende, Van@s Mod installiert (wie von euch schon angesprochen). Ok, dort erscheint nun der neue Bildname (noch ohne Thumbnail), den ich jetzt aktiviere.
Dann gehe ich via "edit images" in die entsprechende "data/media" Kategorie, wo meine Vorschau hingespeichert wurde, rufe mein Bild via "edit" auf und füge mit copy/paste unter "Download URL" den DL-String ein. Dann noch ein wenig Beschreibung und fertig.
Zum Schluß "clear cache" und Check auf der Galerieseite, ob das neue Bild angezeigt wird. Gleichzeitg nochmal Test des Downloads über den DL-Button, und zwar einmal als Admin eingeloggt und ein zweites Mal als simpler Tester eingeloggt. Funktionierts beide Male, bekommt das neue Bild mein OK.
Daß der Unterstrich verschwindet, passiert - soweit ich das erkennen kann - erst irgendwann danach, und dann auch nicht bei allen Dateien, nur bei manchen. Seltsam.
Da das Problem fast ausschließlich - oder eigentlich nur - bei großen Dateien auftritt, könnte schon darauf hindeuten, daß Honda recht hat mit der Zeitüberschreitung beim Download, wenn ein User per Modem oder mit einer langsamen Übertragung ins Netz geht. Und was noch dafür spricht ist, daß es nicht alle User betrifft - es ist nur eine Handvoll, die Probleme damit haben. Aber was mich irritiert hat, war die Aussage eines der Betroffenen, der mich wissen ließ, daß er "woanders" (z.B. bei 4shared) "noch viel viel größere Dateien mit null Problem" herunterlädt. Deshalb suche ich den Fehler natürlich bei mir und meiner Galerie, und nicht beim User. Vielleicht hat er geschwindelt? Ich weiß es nicht. Aber Fakt ist, daß es mehrere sind, die die gleiche Beschwerde vorbringen.
Und hier noch meine phpinfo.php - vielleicht kommt ihr damit jetzt einen Schritt weiter?
<?php
/**************************************************************************
* *
* 4images - A Web Based Image Gallery Management System *
* ---------------------------------------------------------------- *
* *
* File: backup.php *
* Copyright: (C) 2002 Jan Sorgalla *
* Email: jan@4homepages.de *
* Web: http://www.4homepages.de *
* Scriptversion: 1.7.6 *
* *
* Never released without support from: Nicky (http://www.nicky.net) *
* *
**************************************************************************
* *
* Dieses Script ist KEINE Freeware. Bitte lesen Sie die Lizenz- *
* bedingungen (Lizenz.txt) für weitere Informationen. *
* --------------------------------------------------------------- *
* This script is NOT freeware! Please read the Copyright Notice *
* (Licence.txt) for further information. *
* *
*************************************************************************/
$nozip = 1;
define('IN_CP', 1);
define('ROOT_PATH', './../');
require('admin_global.php');
phpinfo();
?>
-
hab noch was vergessen:
ich habe eingangs geschrieben, daß es auch bei kleineren Dateien passiert, aber das möchte ich korrigieren. Es sind hauptsächlich große Dateien, was ich halt als 'groß' bezeichnen würde - meist ab 20MB aufwärts.
-
Und hier noch meine phpinfo.php - vielleicht kommt ihr damit jetzt einen Schritt weiter?
<?php
/**************************************************************************
* *
* 4images - A Web Based Image Gallery Management System *
* ---------------------------------------------------------------- *
* *
* File: backup.php *
* Copyright: (C) 2002 Jan Sorgalla *
* Email: jan@4homepages.de *
* Web: http://www.4homepages.de *
* Scriptversion: 1.7.6 *
* *
* Never released without support from: Nicky (http://www.nicky.net) *
* *
**************************************************************************
* *
* Dieses Script ist KEINE Freeware. Bitte lesen Sie die Lizenz- *
* bedingungen (Lizenz.txt) für weitere Informationen. *
* --------------------------------------------------------------- *
* This script is NOT freeware! Please read the Copyright Notice *
* (Licence.txt) for further information. *
* *
*************************************************************************/
$nozip = 1;
define('IN_CP', 1);
define('ROOT_PATH', './../');
require('admin_global.php');
phpinfo();
?>
Das ist doch aber kein Ausdruck von der PHPINFO :) :)
-
Ach AUSDRUCK! Ich hab mich schon gewundert, was aus der Mini-Datei hier herausgelesen werden soll :lol: Aber als Klein-Hänschen fragt man nicht... :lol:
Ok, und wohin schicken? Wer will sich das antun?
-
schickst Du an Rembrandt :arrow: http://www.4homepages.de/forum/index.php?action=pm;sa=send;u=12998
Der kennt sich damit besser aus als ich :D
-
Hi!
...
Ok, und wohin schicken? Wer will sich das antun?
geh in ACP klicke dort auf phpinfo.php, das was dort aufgelistet wird kopier in eine txt datei.
die kannst du mir dann per mail schicken.
mfg Andi
-
phpinfo hab ich losgeschickt
vD
-
Hi!
sollte eigentlich ein klarer fall sein.
in deiner php.ini stehen folgende werte:
memory_limit 64M
post_max_size 10M
upload_max_file 10M
das ist in deinen fall eindeutig zu wenig.
in der regel sagt man das:
"memory_limit" soll größer sein als "post_max_size" größer als "upload_max_filesize".
ein 25MB bild hat unkomprimiert locker über 100MB, dein speicherlimit 64MB.
wenn jetzt ein bild z.b. per "$_post" oder "$_get" der "zip.php" übergeben wird, nehmen wir mal 100MB an,
tritt die nächste begrenzung in kraft, nämlich "post_max_size 10M".
und dann tritt der effekt auf das die *.zip leer sind.
versuche mal:
memory_limit 200M
post_max_size 150M
upload_max_file 50M
mfg Andi
-
Hi Andi,
ich hab dir noch ne Antwort-PM geschickt.
Aber mal unabhängig davon: Ich übergebe aber doch nix an eine zip.php, das läuft bei mir doch ein klein bisserl anders... meine Files sind ja alle bereits gezippt (von mir) und als fertige zip-Dateien auf den Server geladen (und im ACP als kompletter DL-String eingetragen). Durch Anstoß des normalen DL-Button wird doch nur die vorhandene URL angesprochen, hinter der die Zip-Dateil liegt, da wird nix mehr komprimiert, richtig? Der DL-Button sagt dem Server nur, hole mir diese oder jene fix und fertig gezippte Datei... oder hat da jemand den berühmten Schlauch ausgerollt, auf dem ich grad steh'?
Und wenn ich das richtig mitgekriegt habe, ist die zip.php doch die, die die 'einfachen' Bilder zum besseren Runterladen komprimiert, richtig? Also wenn ein Admin seine Bilder - so wie Gott sie schuf - auf den Server lädt und der User die dann via Zip-Download-Button (oder meinethalben via Lightbox) runterlädt... oder nicht?
Aber wie auch immer: meine hochgeladenen Zip-Dateien sind teilweise über 70, 80MB groß. Und um die problemlos runterzuholen, meinst du, daß eine Korrektur der Werte in der phpinfo auf
memory_limit 200M
post_max_size 150M
upload_max_file 50M
für meine Galerie ausreicht? Wenn ich das richig sehe, brauche ich den Wert in "upload_max_file" gar nicht (ändern), ich uploade ja nix, nur ein winziges 100kb großes Preview. Aber die anderen beiden Werte leuchten durchaus ein.
-
Hi!
das du die bilder vorher schon zipst habe ich wohl überlesen, da gebe ich dir in allen punkten recht.
die werte mußt du da natürlich anpassen.
die upload_maxfilesize kannst ja auch erhöhen.
mfg Andi
-
So, da bin ich wieder. Telefonat mit Strato ergab - wie nicht anders zu erwarten - folgendes:
Werte können nicht erhöht werden, habe bereits das Maximum mit 64M. Wenn sie die Werte für mich erhöhen würden, hieße das, diese neuen Werte hätten gleichzeitig auch alle anderen Kunden (??) und damit würde der Strato Server zu langsam (??). Mir kann man ja alles erzählen... Vorschlag von Strato: Umstieg auf einen virituellen Server, auf dem ich der alleinige Macher wäre mit allen Rechten und Pflichten (um Gottes Willen!!). Oder Zugang zu den gezippten Dateien über eine direkte FTP-Verbindung für den User, wofür der User aber ein FTP-Programm bräuchte (!!). :evil:
Sie wollen meine Bitte um Erhöhung des memory limits auf 200M nun "prüfen" (ich bin wohl etwas harsch geworden) und mir Bescheid geben. Aber da erwarte ich mir absolut nix von.
Ich dachte mir, diese Auskunft wäre vielleicht für alle anderen Strato-Nutzer interessant, die auch mal was geändert haben wollen an ihrem Strato Paket.
Jetzt steh ich da in meinem kurzen Hemd und bin soweit wie am Anfang. Einzige Möglichkeit, die Downloads halbwegs abbruchsicher anzubieten: Aufsplitten der Files in mehrere Teile?
-
Hi!
...
. Aber da erwarte ich mir absolut nix von.
Ich dachte mir, diese Auskunft wäre vielleicht für alle anderen Strato-Nutzer interessant, die auch mal was geändert haben wollen an ihrem Strato Paket.
Jetzt steh ich da in meinem kurzen Hemd und bin soweit wie am Anfang. Einzige Möglichkeit, die Downloads halbwegs abbruchsicher anzubieten: Aufsplitten der Files in mehrere Teile?
...oder den provider wechseln.
mfg Andi
-
und hast du ne gute Empfehlung? Wo gibts so einen Provider, der sowas für lau anbietet: zuverlässig, stabil, virenfrei, kundenfreundlich, nach oben alles offen...?
Interessant wäre ein Provider, der von sich aus auf seine Kunden zugeht und ihnen Neuerungen oder kostengünstigere Updates anbietet. Bei meinem Hosting-Paket, das da schon geraume Zeit am laufen ist, gabs gratis eine Verdoppelung des Speicherplatzes. Aber nicht glauben, daß Strato einen davon informiert!! Iwo, da muß man anrufen, um diese Info zu erhalten!
-
Hi!
ich bin bei all-inkl, mit dem plus paket (http://all-inkl.com/index.php?open=uebersicht&sek=webhosting&session_id=3bbf889cf370fce243229106205cebb8)
frag dort halt mal, der support dort ist m.M. perfekt.
mfg Andi
-
Bevor wir was überstürtzen noch mal das Szenario:
1. Download-Zip-Button ist entfernt
2. Download-Button öffnet /data/media/xxx.zip (per FTP vorher geladen) die Zip-Datei, richtig??
-
1. richtig
2. falsch - DL-Button öffnet eine NICHT im 4images root liegende Zip-Datei
-
Nein, nein, nein, er öffnet eine Datei die im Ordner: /data/media/ als xxx.zip liegt, oder?
-
ähm, doch, doch, doch - es ist schon so wie ich sage. Ins Verzeichnis /data/media lade dich nur meine Previews hoch, die eigentliche Zip-Datei liegt ganz weit weg irgendwo anders auf dem Server. Welche Funktion oder welcher Befehl in diesen DL-Button programmiert wurde, weiß ich nicht, aber auf jeden Fall holt er die gezippte Datei von da ab, wo ich im ACP in der Zeile 'Download-URL' meinen Pfad zur Zip angegeben habe.
-
Hat Deine Vorgehendsweise einen tieferen sinn?? Ist ungewöhnlich die unterschiedlichen orte.
-
Ungewöhnlich? Wieso? Dafür ist die Zeile "Download URL" in "Edit images" doch da, oder? Bei mir handelt es sich ja auch nicht um Bilder, sondern um komplexe Dateien. Ich hatte jedenfalls mit dieser Vorgehensweise seit 2005 noch nie Probleme, lief immer wie geschwuppt.
-
Ungewöhnlich? Wieso? Dafür ist die Zeile "Download URL" in "Edit images" doch da, oder? ...
ahhh.... die unendliche geschichte.
poste doch mal einen downloadlink, so wie er bei dir auf der webseite steht.
mfg Andi
-
jaja, die unendliche Geschichte... gab's da nicht auch einen 2. Teil? :wink: / Rembrandt erledigt
Übrigens kam heute die Antwort von Strato auf meine Bitte, das memory_limit in meiner php.ini von 64MB auf 200MB aufzustocken:
Innerhalb Ihres PowerPlus XL können die Werte für die post_max_size auf einen maximalen Wert von 8 MB und das memory_limit auf einen maximaler Wert von 64 MB durch das Hinterlegen einer eigenen php.ini auf Ihrem Webspace verändert werden.
Bitte beachten Sie, dass eine php.ini nicht in Unterverzeichnisse vererbt wird. Das bedeutet, dass in jedes Verzeichnis, wo die Einstellungen greifen sollen, eine eigene php.ini vorhanden sein muss.
Die für die Nutzung einer php.ini notwendigen Kenntnisse können wir jedoch nicht vermitteln. Für die Änderungen übernehmen Sie die Verantwortung, Support können wir dafür nicht leisten.
Die Nutzung einer php.ini erfolgt also komplett auf Ihre eigene Verantwortung. Bringen Sie nicht die notwenigen Kenntnisse mit, dann sollten Sie eine solche Manipulation nicht vornehmen.
Fehlfunktionen sind z.B. bei den STRATO \'CGI\' und beim \'Website Configurator\' zu erwarten. Treten in diesem Zusammenhang Probleme auf und es befindet sich eine php.ini auf dem Webspace, so können wir z.B. für die STRATO \'CGI\' und für den \'Website Configurator\' keinen Support leisten.
Es bleibt mir nun scheinbar wirklich nichts anderes übrig, als alle größeren Dateien zu zerschlagen und in Mini-Häppchen wieder hochzuladen. Oder der Wechsel zu einer anderen Form, die Downloads anzubieten, z.B. über einen Zen-Cart-Shop? Ob das was ändern würde?
P.S.: seufz, heute hab ich wieder (eine neue) Beschwerde bekommen, daß meine Downloads "...are all blank when them download" nicht funktionieren.
-
Genau das hab ich mir doch gedacht!
Was bitte hat dann Strato mit dem Fremdserver, auf dem die Zip-Dateien liegen, zu tun??
Genau wie 4images?
Kurz: NICHTS!
-
Moin Honda,
nur um Mißverständnisse auszuschließen: meine komplette Domain läuft über Strato. Es ist alles bei Strato gehostet: 4images und meine Dateien. Es gibt keinen anderen Provider, nur Strato.
-
@polarfuchs
hast Du schon mal in die LOG-Datei geschaut?
Jede Fehlermeldung wird doch im LOG Protokolliert. Vielleicht kommt man so auf den Fehler, weil es ist kurios.
-
Genau das hab ich mir doch gedacht!...
versteht aber jetzt keiner was du da meinst :?:
mfg Andi
-
@nobby
LOG-Datei finde ich wo?
-
Ich zitiere mal:
ähm, doch, doch, doch - es ist schon so wie ich sage. Ins Verzeichnis /data/media lade dich nur meine Previews hoch, die eigentliche Zip-Datei liegt ganz weit weg irgendwo anders auf dem Server. Welche Funktion oder welcher Befehl in diesen DL-Button programmiert wurde, weiß ich nicht, aber auf jeden Fall holt er die gezippte Datei von da ab, wo ich im ACP in der Zeile 'Download-URL' meinen Pfad zur Zip angegeben habe.
Ih hab zwar gedacht,mit ganz weit weg, war gemaint, auf einem anderen Hostplatz/Server
aber egal:
Die offizielle download.php von 4images ist nicht mehr im Spiel, oder kurz, wurde geändert. Denn mit der eigentlichen downoad.php würde das Bild von da geholt, wo es liegt!
Dennoch wurde die eigentliche Datei geändert, somit ist es kein 4images-Fehler.
-
@nobby
LOG-Datei finde ich wo?
auf der obersten ebene im Verzeichnis /log die Datei nennt sich error_log.x oder ähnlich.
die kann unter umständen sehr groß sein.
-
danke nobby, aber sowas gibts bei mir nicht, weder ein Verzeichnis /log noch eine datei error_log... vielleicht bei Strato? Sowas hab ich noch nie zu Gesicht bekommen, die hätte ich mir sonst schon längst mal angeschaut.
-
Dann hast Du nur kein Zugriff, schade :|
-
@nobby
Heutiges Telefonat mit Strato:
die memory_limit 64M hat nix mit meinen Downloads zu tun; die greift nur, wenn ein Script ausgeführt wird, aber nicht, wenn ein direkter DL-Pfad angesprochen wird. Man wird meine Angelegenheit bei Strato nochmal auf Herz und Nieren prüfen... mal abwarten... Übrigens konnte der Strato Techniker die größten Dateien (allerdings via FTP, nicht über den DL-Button, den haben wir nicht probiert) ebenfalls problemlos runterladen und bestätigt, daß es nicht an meinen Dateien liegt.
Könnte vielleicht innerhalb der download.php irgendwas stehen, was diesen Fehler verursachen könnte (nur mal angenommen!). Würde sich denn jemand erbarmen und meine download-php mal anschauen, ob dem so ist, bitte??
-
Falls Du an der Download.php nichts geändert hast, einfach mal das Original rüber kopieren.
-
Ich rede doch die ganze Zeit schon davon, das wir die download.php benötigen! Die wurde ja nun mal geändert! Sonst suchen wir ja in drei Jahren noch!
-
Ich rede doch die ganze Zeit schon davon, das wir die download.php benötigen! Die wurde ja nun mal geändert! Sonst suchen wir ja in drei Jahren noch!
ich habe ja x posts weiter oben schon geschrieben das der download mittlels $post oder $get der download.php übergeben wird.
wie auch immer, ich habe auf seinen server den download getestet, 27MB ohne probleme xmal.
mfg Andi
-
Genau, hatte ich ja auch, schon ganz am Anfang!
Ging zig mal, ohne jedes Problem!
-
Vielen Dank Jungs, daß ihr da mal reinschauen wollt.
Ich kann mich beim besten Willen nicht daran erinnern, an dieser Datei etwas verändert zu haben, wozu auch? Es gab ja nie ein Problem (bis jetzt halt). Aber ich kann meine Hand nicht dafür ins Feuer legen, daß ich im Rahmen irgendeines Mods, den ich eingebaut habe, nicht doch mal an der Datei eine Änderung vornehmen mußte. Hier ist sie:
<?php
/**************************************************************************
* *
* 4images - A Web Based Image Gallery Management System *
* ---------------------------------------------------------------- *
* *
* File: download.php *
* Copyright: (C) 2002 Jan Sorgalla *
* Email: jan@4homepages.de *
* Web: http://www.4homepages.de *
* Scriptversion: 1.7.6 *
* *
* Never released without support from: Nicky (http://www.nicky.net) *
* *
**************************************************************************
* *
* Dieses Script ist KEINE Freeware. Bitte lesen Sie die Lizenz- *
* bedingungen (Lizenz.txt) für weitere Informationen. *
* --------------------------------------------------------------- *
* This script is NOT freeware! Please read the Copyright Notice *
* (Licence.txt) for further information. *
* *
*************************************************************************/
$main_template = 0;
$nozip = 1;
define('GET_CACHES', 1);
define('ROOT_PATH', './');
include(ROOT_PATH.'global.php');
require(ROOT_PATH.'includes/sessions.php');
$user_access = get_permission();
if (!function_exists('file_get_contents')) {
function file_get_contents($filename, $incpath = false, $resource_context = null) {
if (false === $fh = fopen($filename, 'rb', $incpath)) {
user_error('file_get_contents() failed to open stream: No such file or directory', E_USER_WARNING);
return false;
}
clearstatcache();
if ($fsize = @filesize($filename)) {
$data = fread($fh, $fsize);
} else {
$data = '';
while (!feof($fh)) {
$data .= fread($fh, 8192);
}
}
fclose($fh);
return $data;
}
}
function fix_file_path($file_path) {
if (!is_remote_file($file_path) && !file_exists($file_path)) {
$file_path = preg_replace("/\/{2,}/", "/", get_document_root()."/".$file_path);
}
return $file_path;
}
function send_file($file_name, $file_path) {
@session_write_close();
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
if (get_user_os() == "MAC") {
header("Content-Type: application/x-unknown\n");
header("Content-Disposition: attachment; filename=\"".$file_name."\"\n");
}
elseif (get_browser_info() == "MSIE") {
$disposition = (!eregi("\.zip$", $file_name)) ? 'attachment' : 'inline';
header("Content-Disposition: $disposition; filename=\"".$file_name."\"\n");
header("Content-Type: application/x-ms-download\n");
}
else {
header("Content-Disposition: attachment; filename=\"".$file_name."\"\n");
header("Content-Type: application/octet-stream\n");
}
$file_path = fix_file_path($file_path);
if (!is_remote_file($file_path) && ($filesize = filesize($file_path)) > 0) {
header("Content-Length: ".$filesize."\n\n");
}
@readfile($file_path);
}
$file = array();
if ($action == "lightbox") {
if (empty($user_info['lightbox_image_ids']) || !function_exists("gzcompress") || !function_exists("crc32")) {
redirect("lightbox.php");
}
if (!check_download_token($user_info['lightbox_image_ids'])) {
redirect("lightbox.php");
}
$image_id_sql = str_replace(" ", ", ", trim($user_info['lightbox_image_ids']));
$image_ids = array();
$sql = "SELECT image_id, cat_id, image_media_file, image_download_url
FROM ".IMAGES_TABLE."
WHERE image_active = 1 AND image_id IN ($image_id_sql) AND cat_id NOT IN (".get_auth_cat_sql("auth_viewimage", "NOTIN").", ".get_auth_cat_sql("auth_viewcat", "NOTIN").", ".get_auth_cat_sql("auth_download", "NOTIN").")";
$result = $site_db->query($sql);
if ($result) {
include(ROOT_PATH."includes/zip.php");
$zipfile = new zipfile();
$file_added = 0;
while ($image_row = $site_db->fetch_array($result)) {
if (!empty($image_row['image_download_url'])) {
if (is_remote_file($image_row['image_download_url']) || is_local_file($image_row['image_download_url'])) {
$file_path = $image_row['image_download_url'];
$file_name = basename($image_row['image_download_url']);
}
}
elseif (is_remote($image_row['image_media_file'])) {
$file_path = $image_row['image_media_file'];
$file_name = get_basefile($image_row['image_media_file']);
}
else {
$file_path = MEDIA_PATH."/".$image_row['cat_id']."/".$image_row['image_media_file'];
$file_name = $image_row['image_media_file'];
}
if (!empty($file_path)) {
@set_time_limit(120);
$file_path = fix_file_path($file_path);
if (!$file_data = @file_get_contents($file_path)) {
continue;
}
$zipfile->add_file($file_data, $file_name);
$file_added = 1;
unset($file_data);
$image_ids[] = $image_row['image_id'];
}
}
if ($file_added) {
if ($user_info['user_level'] != ADMIN) {
$sql = "UPDATE ".IMAGES_TABLE."
SET image_downloads = image_downloads + 1
WHERE image_id IN (".trim(implode(", ", $image_ids)).")";
$site_db->query($sql);
}
$zipfile->send(time().".zip");
exit;
}
else {
redirect("lightbox.php?empty=1");
}
}
}
elseif ($image_id) {
if (isset($HTTP_GET_VARS['size']) || isset($HTTP_POST_VARS['size'])) {
$size = (isset($HTTP_GET_VARS['size'])) ? intval($HTTP_GET_VARS['size']) : intval($HTTP_POST_VARS['size']);
}
else {
$size = 0;
}
$sql = "SELECT image_id, cat_id, user_id, image_media_file, image_download_url, image_downloads
FROM ".IMAGES_TABLE."
WHERE image_id = $image_id AND image_active = 1";
$image_row = $site_db->query_firstrow($sql);
if (!$image_row || !check_permission("auth_viewcat", $image_row['cat_id']) || !check_permission("auth_viewimage", $image_row['cat_id'])) {
redirect($url);
}
else {
if (!check_permission("auth_download", $image_row['cat_id'])) {
redirect($url);
}
if (!check_download_token($image_row['image_id'])) {
echo "Hotlinking is not allowed";
exit;
redirect("index.php");
}
}
$remote_url = 0;
if (!empty($image_row['image_download_url'])) {
if (is_remote_file($image_row['image_download_url']) || is_local_file($image_row['image_download_url'])) {
ereg("(.+)\.(.+)", basename($image_row['image_download_url']), $regs);
$file_name = $regs[1];
$file_extension = $regs[2];
$file['file_name'] = $file_name.(($size) ? "_".$size : "").".".$file_extension;
$file['file_path'] = dirname($image_row['image_download_url'])."/".$file['file_name'];
}
else {
$file['file_path'] = $image_row['image_download_url'];
$remote_url = 1;
}
}
elseif (is_remote_file($image_row['image_media_file'])) {
ereg("(.+)\.(.+)", get_basefile($image_row['image_media_file']), $regs);
$file_name = $regs[1];
$file_extension = $regs[2];
$file['file_name'] = $file_name.(($size) ? "_".$size : "").".".$file_extension;
$file['file_path'] = dirname($image_row['image_media_file'])."/".$file['file_name'];
}
else {
ereg("(.+)\.(.+)", get_basefile($image_row['image_media_file']), $regs);
$file_name = $regs[1];
$file_extension = $regs[2];
$file['file_name'] = $file_name.(($size) ? "_".$size : "").".".$file_extension;
$file['file_path'] = (is_local_file($image_row['image_media_file'])) ? dirname($image_row['image_media_file'])."/".$file['file_name'] : MEDIA_PATH."/".$image_row['cat_id']."/".$file['file_name'];
}
if ($user_info['user_level'] != ADMIN) {
$sql = "UPDATE ".IMAGES_TABLE."
SET image_downloads = image_downloads + 1
WHERE image_id = $image_id";
$site_db->query($sql);
}
if (!empty($file['file_path'])) {
@set_time_limit(120);
if ($remote_url) {
redirect($file['file_path']);
}
if ($action == "zip" && !eregi("\.zip$", $file['file_name']) && function_exists("gzcompress") && function_exists("crc32")) {
include(ROOT_PATH."includes/zip.php");
$zipfile = new zipfile();
$zipfile->add_file(file_get_contents($file['file_path']), $file['file_name']);
$zipfile->send(get_file_name($file['file_name']).".zip");
} else {
send_file($file['file_name'], $file['file_path']);
}
exit;
}
else {
echo $lang['download_error']."\n<!-- EMPTY FILE PATH //-->";
exit;
}
}
else {
echo $lang['download_error']."\n<!-- NO ACTION SPECIFIED //-->";
exit;
}
exit;
?>
-
Freunde, schlagt mich nicht tot, aber:
1. gibts keine Schleife
2. wird an die download + (gegebenfalls) includes/zip.php übergeben
Kurz:
Klickt man den Download-Button, übergibt man an die download.php, die sagt:
lad das Bild und schicke es dem Client
Klickt man den Download-Zip-Button, übergibt man auch an die download.php, die sagt:
packe das Bild aus dem Ordner als ZIP-File.
Ich kann keine Schleife wie:
exestiert der File nicht, erstelle ihn
exestiert der File, dann nutze den auch
entdecken!
-
und das heißt jetzt was im Klartext? Alles so, wie's sein soll?
-
Also hat niemand mehr eine Idee, woran es liegen kann, daß verschiedene User korrupte oder beschädigte Zips runterladen, alle anderen aber nicht?
-
@polarfuchs
das ist auch nicht so Einfach, weil das bei Dir ein bisschen Kurios ist.
Also, geb uns noch ein wenig Zeit zu überlegen :roll: wir Arbeiten daran :wink:
nobby
-
@polarfuchs, hat sich das schon erledigt?
-
Hallo Polarfuchs,
ich habe ein Problem was vermutlich diesselbe Ursache hat. Bei mir werden dateien die auf dem Strato Server liegen ebenfalls nicht mehr korrekt übermittelt. Ich habe nun folgendes herausgefunden:
Der Strato Server komprimiert die Dateien die angefragt werden. Manchmal. Nicht immer. Vermutlich abhängig von seiner Auslastung. Dies führt dazu dass die Dateien mit dem gzip komprimiert werden. die dateien werden letzlich nicht wriklich komprimiert. Aber sie werden als komprimiert übermittelt. Quasi wie ein zip Archiv, das die Datei enthält, diese ist aber nicht komprimiert. Das hat aber zur Folge dass die Datei eingebettet ist in ein Zip Archiv, damit hat die datei mehr bytes als das original. Man kann dies übrigens testen, indem man so eine Datei in eine .zip Datei umbenennt und dann entpackt. Anschließend hat man dann die Datei im orignial.
man erkennt dies auch am Header der übermittelten Datei. Diese enthält dann den Hinweis auf gzip. Wenn ein Browser diese Datei abruft dann kann er damit normalerweise umgehen. Die Idee ist dass ein Webbrowser eine Datei anfragt z.B. ein html -Dokument, der Server antwortet indem er diese Datei komprimiert übermittelt, sie hat dann z.B. nur noch die halbe Größe und damit ist sie schneller übermittelt, und der browser entpackt sie einfach wieder.
Die wird angegeben durch die "content encoding". Leider wiess ich nicht ob es eine Einstellung gibt vielleicht über htaccess mit der man für die Dateien eines verzeichnisses auf dem Server diese Komprimierung unterdrücken kann.
Vielleciht weiss jemand von euch das. Vielen Dank und viele Grüße
Peter
PS: Traurig dasstrotz mehrfacher kontakaufnahmen zu strato keiner von den technikern mir diese info geben konnte und diese scheinbar auch gar nicht wissen dass sie seit einiger zeit diese Komprimierung verwenden.
-
Hallo Peter, hallo Team,
erst mal danke für die Nachricht von Peter - da fühlt man sich doch gleich nicht mehr so alleine mit seinem Problem. Das mit dem gzip klingt ja alles ganz nett, aber wie kann man das abstellen, so es denn wirklich die Ursache allen Übels sein sollte??
Und nein, es hat sich nicht erledigt, der Fehler tritt nach wie vor auf. Und immer mit großen Dateien (über 10MB).
Heute hat sich wieder ein Mitglied beschwert und die Mitgliedschaft gekündigt, weil sie nichts herunterladen kann. Sie hat mir einen Screenshot von ihrem Download Versuch übermittelt, auf dem zu sehen war, daß sie mit IE herunterlädt (obwohl ich ihr schon mehrfach empfohlen habe, FF zu probieren) und beim DL die Meldung erhält "Internet Explorer cannot download ... Content decoding has failed". DAS war zur Abwechslung mal wieder einen neue Fehlermeldung. Bisher kamen ja immer nur Fehlermeldungen bezüglich des Packens und Entpackens via WinRAR. Und es betraf wieder mal mehrere größere Dateien (ca. 24-50 MB). Dieses Mitglied ist (war) übrigens diejenige, die eigentlich immer Probleme hatte. Ein anderes Mitglied hat mir mitgeteilt, daß sie, nachdem sie von IE7 zu IE8 gewechselt ist, jetzt alles problemlos runterladen kann. Aber es melden sich halt auch FF-Benutzer, die auch Schwierigkeiten haben. Ich kann's echt nirgendwo festmachen.
Auf der Suche nach diesem "Content decoding has failed" bin ich auf ein anderes Forum gestoßen, wo auch jemand haarscharf die gleichen Probleme hat wie ich, allerdings innerhalb seines eigenen Forums, und dort auch mit den Downloads. Es wurden alle möglichen Vorschläge gemacht und schlussendlich dann irgendwas von chmod des Verzeichnisses ändern gemurmelt. Das bringt mich zu der Frage, welchen chmod mein Verzeichnis haben sollte, in dem die ZIP Dateien liegen?? Meine ZIP Verzeichnisse (auch die von früher, die alle reibungslos funktioniert haben, aber wesentlich kleine ZIPs enthalten) haben alle 755. Ist das ok?
Das ist das Forum und der entsprechende Thread:
http://www.simplemachines.org/community/index.php?topic=224627.0
Ich bin echt kurz davor, alles hinzuschmeissen und meine Galerie zu löschen, so nervt mich das. Wer will schon Mitglied in einer DL-Galerie werden, wo es vor "Hilfe, ich kann nichts runterladen" Kommentaren nur so wimmelt?!
-
Hallo Team!
Könnte mal jemand ein Statement dazu abgeben, ob diese korrupten zip Dateien auf der User Seite vielleicht auch daher rühren können, daß ich auf meiner Seite Vista64 und die neueste Version von WinRAR (64bit) zum zippen verwende, viele User aber noch mit Windows XP 32bit und möglicherweise alten Unzip Programmen (auch 32bit) runterladen und entpacken wollen - könnte da der Hase im Pfeffer liegen??
Vielleicht könnte DAS ja der springende Punkt sein? Es verdichten sich die Hinweise, daß diese korrupten Zip-Dateien vorwiegend bei Windows XP Usern auftreten.
Ich würde deshalb gerne mal versuchen, über mein Vista Dateien mit einem 32bit Zip Programm zu packen - kann mir jemand sagen, welches Zip Programm ich dafür nehmen soll?