Desintegr a écrit :Ils conseillent de supprimer
~/.xine/catalog.cache et de lancer la commande :
En effet, ça a fonctionné. Xine re-fonctionne.
Desintegr a écrit :Sinon, que renvoie :
Code : Tout sélectionner
objdump -T /usr/lib/xine/plugins/1.29/xineplug_inp_cdda.so | grep homedir
Cela n'a rien de très surprenant :
Code : Tout sélectionner
$objdump -T /usr/lib/xine/plugins/1.29/xineplug_inp_cdda.so | grep homedir
00000000 DF *UND* 00000000 xine_get_homedir
À mon avis cette fonction "fantôme" doit être appelée lors de la lecture du fichier. Ça ne résout donc pas le problème, mais ça permet de le contourner. Merci.
benjarobin a écrit :
Quel est ton PC : Processeur... ? Comment lances tu KDE ? As tu tenter avec un nouveau profil, nouvel utilisateur ?
J'ai fait la même tête quand je l'ai découvert.
Bon mon PC c'est pas une bête de course, mais il tient la route : EeePC 1005HA avec un processeur Atom à 1.6 GHz. Et je lance KDE via mon rc.conf :
Code : Tout sélectionner
DAEMONS=(hwclock syslog-ng @crond @mysqld @sshd dbus @networkmanager kdm)
Quand je disais que j'avais 20% du CPU, je parlais d'amarok tout seul (lisant un MP3), et réduit dans le tray (pas de fenêtre donc).
Mais maintenant que xine remarche, j'ai retrouvé mon amarok avec à peine 7% du CPU dans top. Et le changement de morceau est bien plus fluide qu'avec VLC/GStreamer. C'est un vrai plaisir.
Je n'ai par contre pas tenté avec un nouveau profil/nouvel utilisateur. Mais maintenant que ça va mieux, je pense ne pas aller chercher plus loin.
benjarobin a écrit :Et je suis désolé mais il va falloir changer de backend, Xine n'est plus maintenu et rend instable KDE, surtout lors de l'extinction...
Je sais qu'il n'est plus maintenu et donc qu'il ne faut pas attendre de mise à jour ou de correction de bug, mais pour l'instant il est plus performant et stable que les autres, donc je le garde. Quand VLC ou GStreamer se seront améliorés et stabilisés, je reverrai sans doute mon jugement. Merci quand même.
