Bien que de moins en moins performant (pour des raisons de non disponibilité des sous-titres sur opensubtitle.org), ce script faire une première partie du travail.

Mais depuis plusieurs mois il ne fonctionne plus.

Pas de correction à attendre de l’auteur le script n’est plus maintenu et le site n’existe même plus (je peux héberger le script si vous êtes intéressés)

Ce problème provient du fait qu’opensubtitle.org à changé l’adresse web de son API, il faut donc corriger le script.

Dans le répertoire où vous avez installé / décompressé subdl, éditer le fichier subdl (qui est un script Python),  localiser la ligne suivante :

osdb_server = "http://www.opensubtitles.org/xml-rpc"

Et la modifier ainsi :

osdb_server = "http://api.opensubtitles.org/xml-rpc"

Remarque : cette correction supprime le problème systématique dû au changment d’URL de l’API opensubtitle.org, mais ce service reste très instable et pas très performant.

Sur 17 épisodes d’une même série (série de l’année 2009-2010, ayant fait parler d’elle), l’appel de subdl via :

ls *.avi | xargs -t -I {} python bin/subdl/subdl --lang=fre --existing=bypass {} #

m’a donnée :

• 11 erreurs « Error in XMLRPC SearchSubtitles call: [Errno 104] Connection reset by peer »
• 2 erreurs « Error in XMLRPC SearchSubtitles call: <ProtocolError for api.opensubtitles.org/xml-rpc: 503 Service Not Available> »
• 3 sous-titre non trouvés

Lors de la première exécution et

• 3 erreurs « Error in XMLRPC SearchSubtitles call: [Errno 104] Connection reset by peer »
• 14 sous-titre non trouvés

Lors de la deuxième exécution

Sources :

Fixing subdl 1.0.2

Image par aussiegall sous CC

Ce plugin est activable via l’administration web de Deluge.

Cependant depuis la version 1.2.x de Deluge il y a un bug et si on coche le plugin Blocklist, que l’on appui sur Apply/OK, lorsque l’on revient dans la fenêtre de configuration, le plugin est décôché.

Ce comportement est un bug d’affichage, le plugin est bel et bien activé dès lors qu’on l’a côché une fois.

Pour s’en assurer 2 solutions :

1/ Visualiser le fichier core.conf dans le répertoire .config/deluge du répertoire home de l’utilisateur lançant Deluge (/home/user/.config/deluge/core.conf), vous pourrez y voir ceci :

"enabled_plugins": [
"Blocklist"
],

Indiquant que le plugin est activé

2/ Démarrer le démon en mode debug via la commande

deluged -l /var/log/deluge/deluged.log -L debug

Et faire un grep de block sur le dit fichier de log :

cat /var/log/deluge/deluged.log | grep block

On y voit ceci

[DEBUG ] 14:42:36 rpcserver:376 Registering method: blocklist.check_import

[DEBUG   ] 14:42:36 rpcserver:376 Registering method: blocklist.get_config
[DEBUG   ] 14:42:36 rpcserver:376 Registering method: blocklist.get_status
[DEBUG   ] 14:42:36 rpcserver:376 Registering method: blocklist.set_config
[DEBUG   ] 14:42:36 configmanager:111 Getting config 'blocklist.conf'
[DEBUG   ] 14:42:36 config:374 Config /home/mon_user/.config/deluge/blocklist.conf
version: 1.1 loaded: {'check_after_days': 4, 'timeout': 180, u'file_type': u'gzmule', 'try_times': 3,
'list_size': 3191220, u'file_size': 3159720, u'listtype': u'gzmule', 'load_on_start': True, 'url': u'http://download.deluge-torrent.org/blocklist/nipfilter.dat.gz', u'file_date': u'Mon Nov  2 18:42:44 2009',
u'file_url': u'http://deluge-torrent.org/blocklist/nipfilter.dat.gz', 'last_update': 1266868384.6579671,
'list_type': u'Emule', 'list_compression': u'GZip'}
[DEBUG   ] 14:42:36 core:298 Importing using reader: <class 'blocklist.readers.EmuleReader'>

Indiquant que le plugin est chargé et la liste d’IP importé.

Autre « bug » de l’interface webUI, le plugin est activé mais il n’existe pas de « page » pour le configurer via le WebUI.

Seule solution, configurer Blocklist via le client lourd (GTK) et si votre serveur Deluge est headless (c’est à dire sans écran) il vous faut donc le configurer pour permettre un accès à distance via l’interface GTK.

Dans l’interface GTK, vous pourrez alors accéder à l’écran suivant  :

On peut alors indiquer l’adresse internet d’une liste d’IP à bloquer et la fréquence de vérification de la mise à jour de cette liste.

Pour info la seule liste utilisable pour l’instant est celle hébergée sur le site de Deluge mais malheureusement cette dernière est ancienne et pas du tout mise à jour…

Sources :

http://forum.deluge-torrent.org/viewtopic.php?f=7&t=27565

http://forum.deluge-torrent.org/viewtopic.php?f=9&t=26365&p=123925

1. ont changé de place, elles ne sont plus collées à la barre, ce qui est normal et voulu par Ubuntu
2. sont corrompues, elles affiche un carré de couleur avec des lignes ou des pointillés

En vert…

Ou en mauve ….

Cela est dû à la méthode d’accélération pour Xorg (le serveur graphique) qui pour un certain nombre de carte  à été changé de EXA à XAA par défaut.

En effet XAA bien que moins récent est plus performant que EXA pour certaines vieilles cartes graphiques.

2 solutions pour résoudre se problème sont possibles désactiver XAA ou  l’accélération matériel.

J’ai testé les 2, la première (désactivation de XXA au profit de EXA) a eu pour conséquence (chez moi) de dégrader considérablement les performances de mon ordinateur (CPU grimpant souvent à 100%), la deuxième est en place depuis hier soir, je n’ai pas encore assez de recul pour juger.

Dans les 2 cas il faut éditer le fichier xorg.conf qui se trouve dans /etc/X11.

Si votre fichier Xorg.conf est vide ou si il ne contient pas de section « Device », « Screen » et « Monitor », il va falloir l’initialiser.

Initialisation du fichier xorg.conf

Avant toute chose, je vous conseille de lire un peu de documentation sur le sujet, je ne vais ici que survoler le vaste sujet du xorg.conf.

La modification visant à rétablir/réparer le notification se fait dans le section « Device » qui permet le paramétrage de la carte graphique.

Cette section seule ne sert a rien elle doit être associé à une section « Monitor » réalisant le paramétrage de l’écran.

L’association des sections « Monitor » et « Device » se fait au sein d’une section « Screen », il faut donc que l’on ajoute ceci (a minima) dans le fichier xorg.conf :

Section "Monitor"
        Identifier      "Moniteur1"
EndSection
 
Section "Device"
        Identifier      "CarteGraphique1"
EndSection
 
Section "Screen"
        Identifier      "Screen1"
        Device          "CarteGraphique1"
        Monitor         "Moniteur1"
EndSection

Les entrées Identifier contiennent une chaine de caractères (pouvant contenir des espaces) identifiant la section.

On a ainsi constitué le squelette minimal de notre fichier xorg.conf en vue de paramétrer notre carte graphique.

Solution 1 : désactivation de XAA au profit de EXA

Pour désactiver XAA, on active EXA et cela se fait en ajoutant l’option suivante dans la section Device du fichier xorg.conf :

        Option      "AccelMethod"     "EXA"

Ré-démarrer (un re-démarrage de Xorg uniquement par CTRL+ALT+BACKSPACE, devrait suffir) et la configuration sera prise en compte 

Solution 2 : désactivation de l’accélération matériel

Pour désactiver l’accélération matériel la ligne à ajouter à la section Device est :

        Option      "RenderAccel"     "off"

Idem précédemment un re-démarrage et voici normalement les notifications de retour :

Remarque :

La solution1 est en complète contre-indication avec la solution visant à diminuer l’usage de la CPU mentionné dans Problème de CPU sous Jaunty avec Radéon 7500.

On a donc le choix entre :

• Notification KO et CPU OK en laissant XAA d’activé
• Notification OK et CPU KO en activant EXA

A moins que la solution XAA sans accélération matériel soit le bon compromis, à voir à l’usage.

Sources :

http://ubuntuforums.org/showpost.php?p=8290592&postcount=7

2 bugs existent concernant ce problème :

https://bugs.freedesktop.org/show_bug.cgi?id=22055

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/416001

La consommation CPU

En effet en usage courant (surf sur internet, nautilus, etc.) j’étais constamment entre 20 et 80 % de CPU, autant dire mon PC était un vrai escargot.

Htop m’a permis de trouver le process coupable :

/usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm:0Xauth -nolisten tcp vt7

Voici les tests effectués pour résoudre le problème :

• Comme cela semblait avoir attrait avec le serveur X, j’ai tout d’abord désactivé tous les effets graphique, aucune amélioration.
• Puis j’ai installé un window manager plus léger que Gnome, XFCE4 mais même problème.
• J’ai ensuite installé Firefox 3.5 (alors en béta 4), idem.

Après quelques recherche sur Internet, je me suis orienté vers un bug qui semble affecter certaine carte graphique (en l’occurrence chez moi un ATI Radeon 7500) :

Bug 473115 – Slow performance with Radeon 7500 and Fedora 10

ATI Radeon M6 LY on Jaunty = poor performance [Archive] – Ubuntu Forums

Bug #363238 in xserver-xorg-video-ati (Ubuntu): “very poor Xorg performance on various older graphics HW – XAA solves this”

J’ai donc suivi les conseils et ajouté le bloc suivant dans /etc/X11/xorg.conf :

Section "Device"
 Identifier "Configured Video Device"
 Option "RenderAccel" "on"
 Option "AccelMethod" "XAA"
 Option "AGPMode" "4"
EndSection

Et la miracle le problème semble résolu, j’ai bien une CPU beaucoup plus active que quand j’étais sous XP (peut être est-ce simplement dû à un mode de mesure différent) mais mon PC est de nouveau utilisable.

Edit 14/01/2010 : lors du passage sous Karmic cette modification n’est plus nécessaire puisque XAA est activé par défaut, cependant XAA corrompt les nouvelles notifications système, voir Résoudre le problème des notifications corrompues