Impossible de télécharger plus de 8 Mo d'un coup (Page 1 sur 5)

Salut Marc,

Merci à toi d'utiliser AlBulles et de me complimenter .

Ce qui t'arrive est tout à fait normal je te rassure. Il se trouve que les hébergeurs limitent la quantité de mémoire vive utilisable pour un compte. En l'occurence pour toi, la taille mémoire que peut utiliser un de tes scripts est de 8Mo. Au delà, le script est arrêté et te donne l'erreur précédente. C'est pour cela que j'ai introduit dans le script une variable qui permet de limiter le nombre de fichiers dans le panier (changeable dans le fichier config.php). C'est à chaque utilisateur d'AlBulles de définir le nombre de fichiers max dans le panier en fonction de son hébergement et de la taille moyenne de ses fichiers.

Pour le moment je n'ai pas d'autre solution à proposer. J'étudie pour la version RC1 d'AlBulles la possibilité de limiter le panier non plus par nombre de fichier mais par taille de la future archive en fonction du quota autorisé par l'hébergeur. Je ne sais pas si je vais pouvoir arriver à mes fins mais je vais essayer .

Voilà, donc pour le moment, cela va être à toi d'adapter la limitation de fichiers dans le panier. Il sera bien évidemment impossible que cela soit 100% sans erreurs mais je n'ai pas mieux (il suffit de 4 images à 2Mo chacune et zou, l'erreur revient...). Tu peux toujours prévenir tes utilisateurs que s'ils ont l'erreur, c'est normal.

La version RC1 n'est pas pour tout de suite ; j'ai la version 0.6 à sortir avec les derniers correctifs et pour le moment j'ai trop de boulot avec mon taff pour m'y mettre. Mais je pense que j'aurais une version stable (1.0) au plus tard fin septembre.

Bonne soirée

Je t'en prie

Salut et merci

Par défaut, la configuration de la limitation de mémoire pour un script est à 8Mo (php.ini > memory_limit = 8M). En mettant des images aussi lourdes, cette limite est donc vite atteinte !

Est-ce que dans ton php.ini, le paramétrage des affichages d'erreurs est bien comme ce qui suit :

Sinon, si tu ne souhaites pas modifier ton php.ini, tu peux aussi mettre cette ligne de code dans ton fichier PHP :

error_reporting( E_ALL | E_NOTICE );

Ceci fait, retestes pour voir s'il affiche des erreurs.

Salut Olivier !

J'en suis le 1er désolé, crois le bien !

J'ai déjà longuement réfléchi à ce souci, et je n'arrive toujours pas à trouver de solution viable. C'est un problème complexe auquel je n'arrive toujours pas à répondre (bon, j'avoue, ça fait un moment que je n'y ai pas repensé). Dès lors qu'il faut ecrire des fichiers temporaires, la galère commence : accès concurrents à un même fichier, protection des accès, suppression des fichiers téléchargés, créer autant de fichiers que de sessions ouvertes mais risque de dépassement de quotas d'espace disque pour les hébergement limités, etc, etc, etc

La RAM evite tous ces problèmes, mais limite les paniers...Un jour peut être je trouverais la solution ultime !

Moi j'ai une solution mais elle est un peut couteuse pour une galerie photos : louer un serveur dédié et changer le bridage de PHP dans le php.ini !

Je suis déjà dehors ....

-----> []

hey hey, désolé, c'est de la déformation professionnelle, j'en oublie de définir les termes
J'entends par streaming l'idée d'envoyer les données au client au fur et à mesure de la création de ces données. Pour que ça soit faisable, il faut que le fichier que tu envoies soit "progressif", ie que tu sois capable de déterminer le début sans avoir processé toutes tes entrées.
Par exemple, si tu envoies un fichier dont les premiers octets indiquent la taille des données qui suivent, tu ne peux pas commencer à envoyer le fichier avant d'avoir toutes les données sous la main pour en calculer la taille.

L'avantage de faire du streaming est que tu n'as pas besoin d'avoir toutes les données en RAM, puisque tu t'en débarrasses au fur et à mesure => la limitation à 8MB pourrait devenir non-bloquante.
Mais pour ça, ZIP n'est pas approprié puisqu'il nécessite des tables en début/milieu/fin de fichier, avec des index sur les fichiers.
TAR est à ma connaissance plus approprié puisque c'est une concaténation de fichiers, sans compression, et sans tableau descripteur => le php peut donc envoyer un fichier avec l'extension tar, puis l'entête du fichier A, le contenu du fichier A, l'entête du fichier B, le contenu du fichier B, etc...
GZIP est progressif lui aussi, et permettrait si besoin de compresser le tar sus-généré.

eu... je suis en train de me dire que j'ai plus embrouillé les esprits qu'autre chose
Je vais me monter une démo chez moi, et on en reparle après

--
Pour les vidéos, j'ai XXX.jpg/gif/png , XXX.avi et XXX_lowres.avi : ca me permet d'avoir la miniature que je veux (autoresize + incrustation de l'icone "vidéo" automatique) + la vidéo en 2 versions

Salut !

Mes respects ! Ca a l'air de marcher nickel ton idée !

En fait pour être précis, je sais ce qu'est le streaming...Ce que je ne sais pas c'est comment le mettre en oeuvre Mais je pense que je vais pas tarder à le savoir

N'hésite pas à poster un 'tit bout de code pour que je puisse me faire une idée

ah! bah qu'est-ce que tu veux, on est ingénieur ou on l'est pas
Merci à tous les 2, en tous cas...

En gros, ça donne ça:

header( 'Content-type: application/x-tar');
// creation de l'objet du fichier tar
$oTar = new Tar( "php://output" ); // or stdout

Il y a aussi un calcul de taille avant ça, basé sur la même idée.
Tu veux que je te fournisse l'ensemble ?
Attention, je mets mon copyright

Ouep on est aussi ingé....:D Je te suis dehors kinou

tir au flanc....

Si ca peut te rassurer, je suis dans la téléphonie mobile, donc rien à voir avec PHP

Tu les veux, mes belles sources copyrightées ?

de la ... DOC ??
ckoica ?
on peut en discuter par contre si tu veux...