Reprise du message précédent :

 
Joli morceau, il ne lui manque plus que le bec jaune et des petites ailes noires
Tu as prévu la peluche-pingouin j'espère

je ne les compte même plus depuis 15mois  
des mr igloo partout

p'tite question sur ripdvd : je viens d'en lancer 2 instances pour ripper 2 dvd. Je ne vois aucun fichier se créer dans le répertoire que j'ai donné?
 
où se mettent les fichiers temporaires?

Ouhla ... par contre, j'ai jamais essayé comme ça et je n'ai aucune garantie sur l'utilisation en mode "encodage double"
 
Pour les fichiers en sortie, ils se trouvent par défaut dans $HOME/ripdvd/, ou sinon dans le répertoire que tu as donné au niveau de la configuration.
 
Attention par contre, une fois la preview encodée et visualisée, le fichier temporaire de preview est effacé ... (je sais pas si c'est ta question )

Et bien en fait, j'ai mis --no-preview. Ce que je demande c'est si ripdvd fait des fichiers temporaires, car depuis que j'ai lancé les commandes, il y a 20minutes, rien n'a été créé dans le répertoire de destination que j'ai indiqué.

Tu as donné des titres à tes films ?
Sinon là, tes 2 sessions sont en train d'encoder sur le même fichier ".avi" (sans rien avant le "." ) qui est un fichier caché, donc invisible

D'ailleurs, ça devrait pas pouvoir fonctionner si tu ne donnes pas de titre

Et pour ta première question, pourquoi ça ne marcherait pas ... je ne dis pas que ça ne marche pas, mais que je n'ai jamais essayé et que je ne peux pas te dire si tout se passera bien ou pas, c'est tout.

Peux tu faire un copier/coller des commandes que tu as utilisé pour lancer l'encodage ?

j'ai mis un titre pour chacun (--title "blablaX" ), et je suis en console, donc j'ai pensé à vérifier les fichiers cachés
 

 
et

 
ça tourne (je le vois avec top), mais rien ne sort

Ok, quelques petits glitchs dans tes commandes, quand tu utilises --sub-id, tu n'a pas besoin d'utiliser --sub, même chose pour --aud-id et --aud, et --aud-format n'est pas nécessaire si tu choisis mp3 étant donné que c'est par défaut en mp3

Sinon le répertoire en sortie existe bien ? (j'ai un gros doute sur le fait qu'il soit créé ou que je vérifie son existence avant d'encoder )
Tu as bien les droits en accès/écriture dessus ?

Et si tu essayes d'encoder un par un au lieu des deux en même temps, ça donne quoi ?

j'ai corrigé ma ligne de commande 'mais le -h est pas très explicite à ce propos, si je puis me permettre)
 
j'ai essayé avec un seul à la fois. pareil.
 
Donc, grosse brut, j'ai rajouté un set -x au début de ton script et voilà ce qu'il me sort, sans jamais s'arrêter :

Ok, donc je fais bien la création du répertoire de destination
 
Qu'est-ce que tu ne trouve pas très explicite pour le -h ?  
Je le modifierais pour le rendre plus compréhensible en fonction de tes remarques

c'est l'option dest-dir qui marche pas
 
si je fais un ripdvd --configure en mettant comme répertoire par défaut celui que je met dans dest-dir, ça marche
 
pour le -h : ça ne dis pas que certaines options sont redondantes; pour le format audio, mp3 n'est pas indiqué comme étant l'option par défaut;
 
désolé, j'ai pas le temps de débugger moi-même le coup de dest-dir

Ok, je note ta remarque pour -h, ça sera dans la prochaine release
 
Pour l'option --dest-dir qui ne marche pas, je regarderais ça aussi, je crois avoir une idée ... j'ai du oublier de mettre la variable $DEST_DIR entre quotes
 
Merci en tout cas

bon, après 3 heures d'encodage, le résultat est... pas bon...

j'ai pas regardé la qualité d'image (vu que je suis pas sur mon pc), mais la taille demandée est 350Mo, la taille obtenue est pour l'un de 1014Mo et pour l'autre, 686Mo...

pas glop vais retester avec 350Mo comme taille par défaut

et c'est reparti pour 3 heures!

--edit--

la sortie de ripdvd donne ça:

gnarf
 
Tu utilises quelle version ?
 
Pour la taille, c'est pas normal, la plus grosse différence entre ce que j'avais demandé et ce que j'ai obtenu était de 63 Mo (fichier de 627 Mo au lieu de 700) pour une vidéo quasi monochrome noire (film très sombre avec peu de changement de couleur).
 
Pour ton pb, tu peux me poster ta table d'alias aussi stp ?  

le paquet debian de franceso, et viviblement il y a eu une maj ce matin : 1.7.0

--edit--
la table d'alias bash?

donc la 1.6.1 ?
La 1.7.0 est instable/testing, si c'est celle là que tu utilises, je suis en train de bosser dessus et elle peut donc occasionner des plantages
 
Voui, table d'alias bash ...

pour la version, c'est celle dans le paquet de franceso, donc 1.7.0
j'avais pas vu que c'était la version de dev, désolé

--edit--

au moins, ça te fait du reportbug

yep, c'est très bien, et tu seras cité dans le prochain Changelog
 
ok, je comprends pourquoi ça plante aussi ... tu as un alias "du" qui se nomme "du"
Pas bien du tout ça. Si c'est un alias que tu as fait, tu devrais le nommer "du<blabla>" mais pas du même nom que le programme d'origine ...

Oops ! J'ai oublié de poster hier pour dire que les paquets Debian sont disponibles. J'ai packagé les deux versions 1.6.1 et 1.7.0.

• Les deux paquets sont disponibles en téléchargement sur sourceforge : Téléchargement sur sourceforge
• Le paquet 1.7.0 est disponible sur mon dépot : deb http://francesco.ovh.org/debian/ packages/

Tu es tout pardonné, compte tenu de la qualité de tes paquets

 
bah oui mais non, les alias sont pas interprêtés par ton script hein... et encore heureux, sinon bonjour comment tu casses ton système
 
ou alors y'a un testicouilles dans la soupe aux choux

ben je crains bien qu'ils les interprète, justement
ripdvd est lancé depuis un shell en faisant appel à /bin/bash, et donc tes alias sont chargés dans le "pseudo shell" qui permet de faire tourner ripdvd, non ?
 
Mais après vérif, c'est pas le "du" qui pose pb, mais le "dh" ...

 
non, non, je viens de tester pour m'en assurer, mais un script shell ne charge pas les alias, qui ne sont valables que pour un shell interactif. de même manière que faire set -x puis ripdvd ne donne pas la même chose que rajouter set -x en en-tête de ripdvd
 
 

Ok, ben c'est noté alors

D'ailleurs, avec les histoires de branches stable et dev, je pense qu'on devrait clarifier un peu l'organisation de la page de téléchargement sur sourceforge.
 
pour l'instant, on a une organisation du type:

 
Ca manque de cohérence, et on a un aperçu de toutes les options possibles :
1- packager les deux versions et les releaser séparément mais dans le même groupe (ce que j'ai fait pour les paquets Debian).
Avantage: l'utilisateur choisit ce qu'il veut
Inconvénient: on ne voit pas trop la version stable, qui est cachée par la version de dev à cause de la numérotation
2- ne packager que la version stable (choix fait pour les packages Fedora)
Avantage: l'utilisateur ne peut pas se tromper
Inconvénient: on est obligé d'utiliser les sources pour avoir la version de dev et profiter des dernières améliorations
3- packager les deux versions et les releaser ensemble (ex: paquets Slack)
Avantages: l'utilisateur a le choix. les deux versions sont bien visibles
Inconvénient: comment fait-on si on sort la 1.7.1 alors que la 1.6.1 est toujours d'actualité ?
4- packager les deux versions et les releaser séparément dans des groupes différents (ex: sources)
Avantage: l'utilisateur a le choix. les versions sont bien visibles
Inconvénient: ca multiplie le nombre de groupes de téléchargements possibles
 
Chacune de ces méthodes a des avantages et des inconvénients, mais je pense qu'il faut décider d'en utiliser une de manière cohérente et de s'y tenir.
Voici les deux solutions auxquelles je pense:
1- packager les deux versions, les releaser séparément, faire un groupe de téléchargement pour chaque type d'environnement:

 
2- faire seulement deux groupes de téléchargements (stable et dev) et mettre dedans tous les types de paquets

 
On peut aussi imaginer des solutions intermédiaires...

Belle réflexion
J'étais en train de me dire un peu la même chose, mais en moins littéraire: "p'tain mais c'est le bordaÿl dans la section download !!!"

Ta solution 2 n'est pas terrible étant donné que la dernière release (.deb par exemple) masquera les autres

Pour la solution 1, j'y pensais aussi, mais ça fait d'autant plus de section à maintenir, et je suis pas certain qu'on y gagne en clarté

Par contre, on peut faire un mix comme tu le dis, je peux rajouter une section "binary dev" dans laquelle chaque release correspondrait à un type de paquet (.deb, .rpm, .tgz). De cette manière et étant donné que ce sont toujours les 3 dernières releases qui sont affichées, on aurait toujours sous les yeux le dernier paquet dev disponible pour sa distrib adorée, même si le fichier est masqué par un upload plus récent ... (euh, chuis clair )

Genre:

oui ? non ? autres idées ?

En fait, je pensais mettre tous les paquets binaires dans la même release. Le problème de ça, c'est s'il y a des sous-versions propres à chaque distrib à cause d'erreurs de packaging. Mais sinon, il n'y a pas de problème de "masquage" par le dernier paquet uploadé.
 

C'est ce qu'il me semble aussi
 

En gros, tu détailles les sections par distrib pour la version stable, la version de dev est distribuée dans une seule section de téléchargement. Ca me plait pas mal comme idée, mais pourquoi ne mélanges-tu pas tous les paquets binaires dans la même release ?
 
Genre:

D'accord avec ton premier point ...
 
Simplement parce que ça vous obligerait à me transmettre d'abord vos release pour que j'upload le tout par la suite, je trouve que c'est une contrainte pour vous
En imaginant que l'un d'entre vous soit absent pour une raison X ou Y, ça oblige à attendre qu'il soit rentré et qu'il ait fait le paquet. Ou inversement, si c'est moi qui suit absent, la diffusion ne pourra pas être faite non plus
 
On peut continuer à creuser pour essayer de trouver la meilleure solution

Ah bon ? Je pensais qu'on avait le droit d'éditer n'importe quelle release pour y ajouter / enlever des fichiers...

avec la version 1.6.1, j'obtient les mêmes tailles extravagantes

Je viens de modifier entièrement mon dépot de paquets Debian pour permettre le choix entre les versions stables et de dev de ripdvd. Maintenant, tout est fait de manière plus propre et semblable au dépôt officiel Debian.
 
L'ancien dépôt reste valide (du moins pendant quelques temps), mais vous pouvez déjà tester le nouveau :

 
N'hésitez pas à me signaler les erreurs d'apt s'il y en a...

Ah yes, je pensais pas à ça ... comme quoi    
 
Donc à creuser
 
PS: bonne idée le passage testing/sid pour ton dépot, ça sera plus clair pour les utilisateurs je pense  

 
 
Tu as essayé avec un autre dvd ?
Quel genre de film c'est ?

c'est un coffret d'une série, donc chaque titre correspond à un épisode
 
je testerais un autre dvd quand j'aurais le temps, je te tiens au courant

Salut à tous !!!

Je passe en coup de vent, juste pour vous dire qu'un tuto de ripdvd est disponible sur mon site : http://divxtutos.freezee.org/tutoriels/ripdvd.php

Et sera très prochainement disponible sur le site officiel de ripdvd : http://sourceforge.net/projects/ripdvd/

Si vous avez des remarques ou des suggestions pour le peaufiner, n'hésitez pas.

@+ fafane84

je viens de modifier mon sources.list et en faisant "sudo apt-get update" j'ai ce message d'erreur :

Merci à toi mister Fafane

Merci beaucoup
J'ai pas de suggestions : ton tuto est vraiment bien fait. Bravo !
 

C'est pas vraiment un message d'erreur. C'est juste que je signe mes paquets (pour prouver qu'ils viennent vraiment de moi) et que tu ne disposes pas de ma clé publique pour vérifier la signature (ce qui est normal parce que je n'ai pas encore envoyé ma clé sur un serveur de clé pour la diffuser). Je me renseigne, et je règle ça dès que possible.
 
Normalement, les dépots fonctionnent quand même, non ?

 
Oui, sans problème, ce serait juste bien d'uploader la clé publique (mode parano ON )

<mode parano>Ouais, mais qu'est-ce qui va te garantir que c'est bien à moi qu'elle appartient cette clé publique ?   </mode parano>
 
J'uploade ma clé ce soir et je vous tiens au courant

Faut la faire signer par d'autre personne