tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

stadros83 · Le 17/06/2011, à 08:45

Franchement ne t'excuses pas !! Tu nous aides énormément !!!

zootroopa · Le 19/06/2011, à 12:36

C'est clair. Extrême disponibilité, extrême réactivité.

Zakhar · Le 21/06/2011, à 21:11

21 juin 2011
Version 1.6.2

Crédit à zootroopa pour le debug et test sur Synology DS411+
Retrait du "process substitution" a profit d'une fonction avec un simple "pipe" davantage compatible avec d'autres Linux (comme busybox)

"Script compagnon" busyXtremMerge contenant les adaptations pour Busybox
Version 1.0.3

Vérification qu'on a au moins une version suffisante de tuXtremMerge, en l'occurrence pour cette 1.0.3 il faut la 1.6.2 au moins
Suite à simplification dans le md5sum du programme commun (suppression du "process substitution") on n'a plus besoin du contournement md5sum

@zootroopa à l'occasion peux-tu reprendre les scripts des posts 1 et 2 (tuXtremMerge et busyXtremMerge) et faire le test :
- avec seulement tuXtremMerge
- sur un fichier de taille supérieur à 4G
Donc commande du genre :

./tuXtremMerge -vtt Mon_Fichier_de_plus_de_4G_001.xtm

... en principe (de ce que je devine), tu ne devrais plus avoir besoin des "contournements" grâce au 'coreutils' qui a l'air vraiment tout à fait à jour (même plus récent que ceux de Lucid Lynx).
Et donc si c'est bien le cas, c'est une bonne nouvelle, ça veut dire que tu n'as plus besoin de busyXtremMerge (garde le quand même dans un coin au cas où !)

@stadros83 lorsque zootroopa aura fait le test, on verra pour le tien. Je vais faire un autre truc pour vérifier le niveau des utilitaires GNU installés.

Dernière modification par Zakhar (Le 21/06/2011, à 21:12)

zootroopa · Le 22/06/2011, à 10:30

Hello,

Il m'a fallu un peu de temps pour récupérer un nouveau gros pool de fichiers xtm (...) mais c'est maintenant chose faite.
Je te fais le test ce soir en rentrant du boulot.

zootroopa · Le 22/06/2011, à 17:49

Voilà voilà
Autant le dire tout de suite: CA MARCHE !
Encore bravo et merci !

DiskStation> ls -l 
total 6872532
-rw-rw-rw- 1 admin users 1047527528 Jun 22 00:20 BBPR.mkv.001.xtm
-rw-rw-rw- 1 admin users 1047527424 Jun 21 23:38 BBPR.mkv.002.xtm
-rw-rw-rw- 1 admin users 1047527424 Jun 21 23:37 BBPR.mkv.003.xtm
-rw-rw-rw- 1 admin users 1047527424 Jun 22 00:18 BBPR.mkv.004.xtm
-rw-rw-rw- 1 admin users 1047527424 Jun 22 00:16 BBPR.mkv.005.xtm
-rw-rw-rw- 1 admin users 1047527424 Jun 21 23:38 BBPR.mkv.006.xtm
-rw-rw-rw- 1 admin users  752204065 Jun 22 00:28 BBPR.mkv.007.xtm
-rwx--x--x 1 root  root        6206 Jun  2 08:29 _busyXtremMerge
-rwx--x--x 1 root  root       24450 May 28 18:26 _tuXtremMerge
-rwxr-xr-x 1 root  root        7564 Jun 21 21:51 busyXtremMerge
-rwxr-xr-x 1 root  root       24672 Jun 21 21:51 tuXtremMerge

bash-3.2# bash ./tuXtremMerge -vtt BBPR.mkv.001.xtm
18:44:42.256975000
*** Vérification d'existence du premier fichier source...
*** Premier fichier source trouvé : BBPR.mkv.001.xtm
*** Vérification d'existence du dernier fichier source...
*** Dernier fichier source trouvé: BBPR.mkv.007.xtm
*** Tailles premier et dernier fichier cohérentes.
*** Détermination de l'emplacement du résultat...
*** Emplacement du résultat : 1993 Beaucoup de Bruit pour Rien 1080p.mkv
*** Vérification de la possibilité d'écrire le résultat : existence, autorisation d'écriture, espace disponible, etc...
*** 0 fichiers déjà traités.
*** Vérifications pour le fichier résultat terminées.
18:44:42.356764000
Traitement optimisé des 7 fichiers
==================================
Traitement de BBPR.mkv.001.xtm ...  OK
18:45:13.513175000
Traitement de BBPR.mkv.002.xtm ...  OK
18:45:42.019575000
Traitement de BBPR.mkv.003.xtm ...  OK
18:46:10.567697000
Traitement de BBPR.mkv.004.xtm ...  OK
18:46:41.218760000
Traitement de BBPR.mkv.005.xtm ...  OK
18:47:10.533359000
Traitement de BBPR.mkv.006.xtm ...  OK
18:47:39.381993000
Traitement de BBPR.mkv.007.xtm ...  OK
18:48:05.209988000
==================================================
Toutes les opérations sont terminées avec succès !
18:48:05.263189000

Zakhar · Le 22/06/2011, à 19:05

Parfait !..

Donc coreutils était une bonne chose (ce qu'il faut pour que le script marche du 1er coup).

Et c'est maintenant je m'explique pourquoi le premier qui a testé sur Synology (DS211+) ça avait marché sans "contournements". Probablement qu'il avait déjà précédemment installé les coreutils.

Maintenant je vais investiguer pour stadros83, si la version de coreutils pour son processeur est OK.

@zootroopa, garde quand même busyXtremMerge dans un coin, on ne sait jamais, on peut toujours tomber sur un cas de figure non encore vu. Mais donc à priori tu n'en as plus besoin vu que les "contournements" ralentissent quand même (pas grand chose mais un peu) le processus, il vaut mieux utiliser tuXtremMerge directement, comme sur Ubuntu.

Et je vois aussi que le temps du dernier fichier, avec le truc standard, et sur cet exemple ne semble pas trop aberrant par rapport aux autres. 24s au lieu d'une moyenne à 30, alors qu'il faut 3/4 de la taille des autres. Ca reste donc dans le bon ordre de grandeur.

Dernière modification par Zakhar (Le 22/06/2011, à 19:06)

Gajo22 · Le 28/07/2011, à 07:45

Tout d'abord, bravo pour ton travail !!

J'apporte ma très modeste contrib :
cela fonctionne sur synology DS209, cependant j'ai eu de très gros problème de lenteur, il recollait 1mo/S !!! En fait, j'avais installer le package textutils pour avoir od et tr, c'est à oublier il faut installer corutils !!
voila, bonne continuation,

Gajo22

Zakhar · Le 28/07/2011, à 08:20

Merci pour ta contribution.

Je rajouterai ton témoignage dans la liste à la prochaine version.

Et effectivement, avec zootroopa on avait fini par déduire que c'est bien coreutils qu'il faut installer (lequel contient les textutils) et non pas textutils qui semble être un version très très antique.

Et donc à ce jour nous avons le fonctionnement sur :

DS211j
DS1010+
DS411+
DS209

Pas mal.

P.S.: peux-tu me confirmer (ou pas) qu'avec les coreutils tu peux utiliser le script directement, sans avoir besoin des "contournements" dans busyXtremMerge ?

Gajo22 · Le 29/07/2011, à 07:59

Helas non !!
Il faut passer par busyXtremMerge !! et, même si je ne comprends pas pourquoi, il faut aussi enlever la première ligne du fichier (le #!/bin/bash) !!
Mais l'essentiel, c'est que ça marche au poil après :-D !!!

Voila,
Gajo22.

Zakhar · Le 29/07/2011, à 08:28

Ah je vois... probablement parce que tu n'as pas installé bash.

Il faut coreutils et bash

Une fois ceci fait, si ça ne fonctionne toujours pas sans busyXtremMerge, tu peux me mettre ce que ça te crache, que je jette un oeil.

... enfin de toute façon, c'est pas si dramatique non plus avec busyXtremMerge, le ralentissement est micro-chouiesque une fois que tu as mis les bons coreutils !..

J'ai fait un autre script pour downloader sur Free avec/sans la Freebox V6 (pas encore publié), et cette fois j'ai bien pris soin qu'il soit compatible dash (le moteur de script par défaut des Debian/Ubuntu) ce qui devrait aider pour ceux qui voudront le tester sur Synology. Mais hélas, je n'en étais pas encore là lorsque j'ai fait le tuXtremMerge, et certaines commandes nécessitent vraiment bash.

Dernière modification par Zakhar (Le 29/07/2011, à 08:31)

NiKo88 · Le 28/08/2011, à 12:33

Salut à toi Zakhar!

Tout d'abord je tiens à te remercier pour le sacré boulot que tu as fait et que tu continues à faire

Aprés avoir parcouru les 8 pages du topics, je peux maintenant apporter mon témoignage, POSITIF!!!

Je dispose d'un serveur NAS Synology DS211+ avec DSM 3.1 - 1748.

Aprés l'installation de bash et coreutils, j'ai récupéré les 2 scripts en page 1.

Ensuite, il est nécessaire de supprimer #!/bin/bash sur les deux scripts sinon ça fonctionne pas...

Et voilà aprés exécution de la commande bash busyXtremMerge [Source] [Destination] le fichier de 7,95Go est recollé avec succès

Encore merci pour le boulot que tu fais et j’espère que mon témoignage pour servir à d'autre

Zakhar · Le 28/08/2011, à 17:20

Merci pour ton témoignage, on avait déjà le DS211j, et donc maintenant aussi le DS211+

Je rajoute tout ça à la liste à la prochaine MàJ (là je suis encore en vacances pour un petit moment ).

Bizarre par contre que tu aies à retirer /bin/bash puisque tu as installé bash !.. Enfin, du moment que ça fonctionne ainsi, on ne va pas faire la fine bouche.

Bon "merge" de xtm !..

Zakhar · Le 01/09/2011, à 09:55

Alors pour l'histoire du bash... la réponse est au post 135... mais il est vrai qu'il y a "trop" d'info, va falloir que je résume sur le post #2 des NAS.

Donc sur Synology, les programmes supplémentaires comme bash sont installés dans /opt/bin et non pas dans /bin comme sur un linux standard. En effet, c'est considéré comme des "options" (d'où l'installation sous /opt).

Or le script appelle /bin/bash... et ne le trouve pas puisqu'il n'est pas là. En conséquence, il se replie sur le shell standard du système, en l'occurrence Ash pour les Synology. Par conséquent, installer bash sans le petit "correctif" indiqué au post 135 ne sert à rien, puisque c'est Ash qui sera pris !.. De même si on supprime la ligne /bin/bash au début du script.

Et donc pour "corriger" la chose et faire en sorte que le Synology ressemble le plus possible à un système Linux standard, il suffit de rajouter un lien symbolique comme ceci (en root) :

ln -s /opt/bin/bash /bin/bash

Ainsi le script standard, sans qu'il soit besoin de BusyXtremMerge et sans qu'il soit besoin de retirer la première ligne du script, devrait fonctionner.

the--jigsaw · Le 04/09/2011, à 22:26

http://doc.ubuntu-fr.org/gnome-split

gnome split fonctionne aussi pour le xtm

pouvez-vous faire des comparaison pour savoir le quel est le meilleur

Zakhar · Le 08/09/2011, à 08:00

Bonjour the--jigsaw.

Tout d'abord "le meilleur"... selon quel critère ?..

Mon but en écrivant le présent script n'était pas de faire "le meilleur" (ce qui dans l'absolu ne veut pas dire grand chose) programme pour gérer les .xtm, mais de répondre en premier à mon besoin, et éventuellement aider d'autres. Accessoirement c'était aussi une bonne occasion d'apprendre à maîtriser le script Linux : c'est toujours mieux quand on a un truc concret à faire plutôt que d'apprendre dans l'absolu sans but précis.

Si la comparaison avec Gnome-split devait se faire, ce serait plutôt avec l'autre développement (voir sur ce forum) qui est également un exécutable, donc de même nature.

Mon développement a des avantages uniques (ou probablement) par rapport à tous les autres développements existants :
- c'est du script, le plus portable possible, et ça fonctionne donc aussi sur des NAS (Synology), voir témoignages. (Aucun des autres développements ne fonctionne sur un NAS car il faudrait pour cela prendre la peine de le compiler spécifiquement)
- on utilise la puissance du script, notamment le parallélisme pour calculer les md5 en même temps qu'on fusionne. Mon script est donc probablement le plus rapide de tous les autres programmes, dans le cas évidemment où on vérifie aussi les md5.
- il sait faire une fusion partielle, ce qui est utile lorsqu'on télécharge des morceaux pour commencer la fusion partielle. A la fin de dernier morceau téléchargé, il ne reste donc plus qu'à coller ce dernier morceau et non pas l'ensemble.

Mon script a cependant des limitations :
- il ne fonctionne pas avec les "exécutables" xtm (pas implémenté) ([Edit du 24 Septembre 2011] Implémenté avec la 1.7.0)
- il ne fait que la fusion, pas le découpage (pas implémenté)
- les réfractaires de la ligne de commande apprécient peu ("front-end" graphique pas implémenté)

Je ne compte pas implémenter les choses marquées "pas implémenté" ci-dessus.

Donc c'est selon ton usage que tu choisiras l'une ou l'autre des solutions.

Si tu es un "geek" (raisonnablement) et que tu préfères la vitesse quitte à taper une ligne de commande, voire que tu veux fusionner directement sur ton NAS sans avoir à faire une double copie... mon script est fait pour toi.

Dans le cas contraire, ou si tu es dans une des limitations (non implémentées) citées ci-dessus, il te faudra utiliser une autre solution !..

P.S.: à l'époque où j'ai commencé ce script, j'avais testé Gnome-Split et je n'avais jamais réussi à le faire fonctionner pour les xtm... mais il est vrai que je n'ai pas insisté, et pas trop chercher le pourquoi

Dernière modification par Zakhar (Le 24/09/2011, à 14:42)

stadros83 · Le 08/09/2011, à 08:35

the--jigsaw a écrit :

http://doc.ubuntu-fr.org/gnome-split
gnome split fonctionne aussi pour le xtm
pouvez-vous faire des comparaison pour savoir le quel est le meilleur

Le script développé ici est déjà très rapide entre nous et la limitation se fait plutôt au niveau des disques durs . Il me semble que j'avais posté ici d'ailleurs la vitesse atteinte qui était sensiblement équivalente à la vitesse max possible chez moi ... donc parfait !!

D'ailleurs je remercie encore Zakhar !

Dernière modification par stadros83 (Le 08/09/2011, à 08:36)

Ypnose · Le 08/09/2011, à 10:43

Et puis Gnome Spit, il faut du Java pour compiler. Et Java c'est trop... lourd.
Je préfère un petit script. C'est bien mieux.

Zakhar · Le 10/09/2011, à 00:15

Merci les amis !

Alors quelques explications sur le fonctionnement "théorique" de Linux, des programmes tels XtremSplit (version originale) et la différence avec mon script.

J'ai fait des chronométrages avec un fichier de 2GB. C'est en fait un tout petit peu favorable vu que j'ai un PC avec 4GB de RAM et donc lorsqu'on lit et qu'on relit le même fichier, il est en principe tout en RAM. Cela est favorable à XtremSplit, pas trop à mon script qui est bien plus optimisé que ça... mais explication plus bas.

Donc la copie se fait :
- Source (lecture) un disque 2To à 5400RPM (Samsung Spinpoint F4). Fichier situé dans le premier quart du disque (c'est important pour la vitesse). Partition ext4.
- Destintation (écriture) le disque de mon PC Portable, un 5400 RPM. Fichier situé aussi dans le premier quart du disque. Partition ext4.
- MD5 mon processeur est un Corei7 de portable... mais ça dépote quand même pas mal !..

Alors voici les vitesses brutes des éléments séparés.
Pour cela on fait un cp (copie) de la RAM vers le disque (ecriture) ou du disque vers la RAM (lecture). Mon répertoire /tmp est monté en RAM, donc le fichier de 2GB y va pile poil.

Les vitesses brutes sont donc de :

- Lecture = 15,5sec [soit environ 128MB/s, ce qui est confirmé par Palimpsest]
- Ecriture = 19,5sec [soit environ 100MB/s]
- MD5 = 4,9sec [soit environ 400MB/s]
- Copie "à vide" RAM vers /dev/null = 0,4sec [c'est en quelque sorte l'overhead du cp et des filesystems divers]
- Copie disque à disque = 22,5 sec [soit environ 88MB/s, ce qui est cohérent avec l'affichage par exemple lors de copies similaires sous Nautilus]

Protocole de test... linux est super optimisé... si on se contente de faire un cp en mettant un timer avant et après, le résultat est faux. On le constate visuellement en voyant que le disque continue à tourner bien que la ligne de commande ait déjà rendu la main. Et le temps pendant lequel il fait ça n'est pas négligeable !.. En effet, par défaut l'écriture sur le disque est asynchrone. Donc lorsqu'on copie, la commande rend la main lorsque tout est dans le buffer de copie... mais pas encore sur disque. Les buffers pouvant monter à 2GB (facilement sur un système à 4GB), le résultat paraitraît bien plus optimiste si on ne "corrigeait" pas.
La correction consiste donc à placer après le cp des ordres qui vont faire que le système va attendre. Notamment on fait un move (mv) du fichier écrit sur un fichier existant (touch), et on rajoute surtout un sync (synchronisation des buffers)... pour la bonne mesure.
Les temps ci-dessus sont pris avec ces mesures correctrices bien sûr.

Un peut de théorie, on voit alors que Linux est quand même bien optimisé !..
L'overhead du cp n'est que de 2,5% du temps de lecture, mais c'est bien normal, puisque dans notre cas, l'essentiel du temps c'est des I/O, c'est à dire des lectures/ecritures sur disque.
On voit aussi que la copie, bien que j'aie pris la précaution de faire un sync, est très loin de faire la somme de l'écriture et de la lecture. En réalité, par le jeu des buffers, on n'attend pas d'avoir ecrit un bloc pour lire le suivant... on attend juste qu'il soit dans le buffer (sauf le sync final qui vide les buffers d'écriture en l'occurrence).

Alors la théorie, un programme "naïf" tel que l'original XtremSplit (version Windows) va faire la chose suivante :
- Lecture de la source = 15,5 sec
- MD5 = 4,9 sec
- Lecture de la source = 15,5 sec
- Écriture de la destination = 19,5 sec
----------------------------------
- Total théorique = 55,4 sec

Or en faisant tourner Xtremsplit... corrigé du "sync" (car il bénéficie, même si c'est un programme Windows, des mécanismes de bufferisation Linux !)... au mieux 54 sec, soit pas loin du temps théorique !..

Mon script n'utilise pas du tout une démarche aussi naïve et séquentielle, en réalité il fait presque comme une copie, et fait le MD5 en parallèle.
Ca donnerait plutôt :
- Lecture de la source / Ecriture bufferisée (comme un cp) / md5 en parallèle.

Et le résultat est que pour le même fichier, on est à 23,5 sec. On observe bien qu'il y a parallélisation car c'est à peine plus long qu'un cp standard (1 sec) et en tout cas moins long qu'un cp + md5, ce qui ferait 27,4 sec.

La comparaison des performances résumée donne donc :

- Xtremsplit = 54 sec
- Mon script= 23,5 sec
- Copie simple= 22,5 sec
- Copie + MD5= 27,4 sec

Et donc, the--jigsaw, comme te le disais Stavros83, l'essentiel de temps est de toute façon de la copie disque. En l'occurrence, le script met 23,5 sec, là où la copie simple met 22,5 sec. Or la copie simple, si l'on enlève son overhead mesuré plus haut à 0,4 sec, c'est donc à peu près 22 sec de travail sur disque.
On est donc, avec mon script, à 6,5% de calcul (dont le MD5 !) et à 93,5% d'accès disque.
Tu vois donc, et Stavros l'a bien compris, que même si j'écrivais le truc en C/C++, tout au plus tu peux gagner 1 seconde... pas la peine de se fatiguer et de perdre la portabilité du script !..

Franchement, au niveau performance, si tu trouves un truc qui met même pas 5% de plus qu'un cp tout bête, en faisant bien sûr le md5 au passage.... ben tu me fais signe !..

Sur NAS, le temps gagné est encore bien plus considérable. En effet, si tu n'as que l'utilitaire Windows, pour fusionner les fichiers tu dois les passer 2 fois au travers du réseau : lecture, puis écriture. Et donc, sur le cas d'exemple ci-dessus, en supposant que tu as un réseau optimisé 1GB, ça donne facilement 45sec de plus.
Conséquence, tu passes d'un Xtremsplit qui met alors 100 sec, à un script qui met toujours des 23,5 sec... soit cette fois 4 fois plus rapide (au lieu des 2 fois plus rapide standard).

Il en est de même d'un exécutable Linux... à moins de le compiler spécialement pour les NAS.

J'espère que ces quelques mesures t'auront éclairé.

Tu peux bien sûr refaire les mêmes mesures avec les autres programmes, et comparer avec les temps bruts de :
- La copie
- La copie + md5

... et là je pense que niveau performances tu devrais être convaincu !..

(Après il reste bien sûr les limitations de mon script que j'ai énoncées plus haut).

P.S. : bien sûr, la copie avec source et destination sur le même disque physique donne des résultats bien plus mauvais puisqu'à cause des déplacements des têtes dès qu'on passe de lecture à écriture, le processus global est bien plus lent. Quel que soit le programme utilisé, il est donc toujours conseillé de mettre des xtm sur un disque physique, et de faire la fusion sur une destination appartenant à une autre disque physique.

Dernière modification par Zakhar (Le 10/09/2011, à 00:25)

Hizoka · Le 22/09/2011, à 03:06

je viens de recuperer des fichiers xtm mais le 1er fichier est un exe qui contient un logiciel pour recoller les fichiers.

malheureusement le script ne semble pas capable de recoller les fichiers.

y a -t-il un moyen de contourner ca ?

Respawner · Le 22/09/2011, à 08:41

De mémoire (car je l'ai fait pour GNOME Split), tu peux ignorer les 305704 premiers octets du fichier en .exe. Ces premiers octets sont en fait le programme de recollage intégré au fichier, le reste après est au format Xtremsplit classique. Donc en coupant les 305704 premiers octets tu te retrouvera avec un fichier .xtm classique que le script devrait pouvoir recoller.

Hizoka · Le 22/09/2011, à 15:13

et comment je fais pour les couper ?

Respawner · Le 22/09/2011, à 16:53

Peut-être un

dd if=fichier.001.exe of=fichier.001.xtm skip=305704

Hizoka · Le 22/09/2011, à 17:02

ca me cree bien un fichier mais tuxtremmerge me renvoie une erreur...

Zakhar · Le 23/09/2011, à 18:34

Désolé Hizoka, je te confirme, le script ne gère pas les .exe en xtm puisque le format en est "obscur".

Si jamais il existait une documentation, il serait effectivement aisé d'adapter le script. Dans ce cas, fais moi signe ici, et je ferai la modif.

En attendant il faut utiliser les autres solutions : Wine + Xtremplit, ou l'exécutable objet de l'autre développement pour les XTM (voir le lien dans le premier post).

Respawner · Le 23/09/2011, à 20:09

@Zakhar : Si t'as pas peur du code Java, va jeter un coup d'oeil à GNOME Split. Il gère les .exe de Xtremsplit aussi.
http://respawner.fr/bzr/gnome-split/mai … split.java

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#176 Le 17/06/2011, à 08:45

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#177 Le 19/06/2011, à 12:36

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#178 Le 21/06/2011, à 21:11

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#179 Le 22/06/2011, à 10:30

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#180 Le 22/06/2011, à 17:49

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#181 Le 22/06/2011, à 19:05

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#182 Le 28/07/2011, à 07:45

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#183 Le 28/07/2011, à 08:20

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#184 Le 29/07/2011, à 07:59

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#185 Le 29/07/2011, à 08:28

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#186 Le 28/08/2011, à 12:33

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#187 Le 28/08/2011, à 17:20

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#188 Le 01/09/2011, à 09:55

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#189 Le 04/09/2011, à 22:26

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#190 Le 08/09/2011, à 08:00

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#191 Le 08/09/2011, à 08:35

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#192 Le 08/09/2011, à 10:43

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#193 Le 10/09/2011, à 00:15

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#194 Le 22/09/2011, à 03:06

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#195 Le 22/09/2011, à 08:41

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#196 Le 22/09/2011, à 15:13

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#197 Le 22/09/2011, à 16:53

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#198 Le 22/09/2011, à 17:02

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#199 Le 23/09/2011, à 18:34

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

#200 Le 23/09/2011, à 20:09

Re : tuXtremMerge (XtremSplit TURBO !) - Recoller vos fichier .xtm

Pied de page des forums