Bonjour,

Après recherche sur ce site et ailleurs je n'ai pas trouvé de sujet correspondant à mon problème - si l'on pouvait donc m'en pointer ou échanger sur le sujet, cela me permettrait peut être d'optimiser mon gMusicbrowser très utile... :)
Et désolé si je n00be en n'ayant pas trouvé... :-/

Situation : sur réseau local ethernet 10/100
- Poste multimédia Intel Atom 1,8Ghz 3Gb RAM, SSD récent : exécute gMusicbrowser sous xUbuntu.
    Apparence : Listes de lecture, Bibliothèque et contexte (trop lourd ?)
- NAS réseau accédé avec cifs-utils (samba smbfs) over LAN ; 25 000 fichiers en bibliothèque.

Problème :
- Les recherches lors de la frappe dans le champs recherche sont extrêmement lentes, les caractères tapés s'affichent lentement, un par un, et le PC rame pendant ce temps, et gmusicbrowser est alors temporairement bloqué (de l'ordre de la dizaine de seconde à plusieurs dizaines).
- Tout rafraichissement des listes (artiste, album, piste) est très lent.
- L'init est lent et dépasse facilement l'ordre de la dizaine de secondes, mais ce n'est pas très grave et compréhensible.

Solutions ?
- La localisation des fichiers son sur un NAS provoque-t-elle les lenteurs ?
- Des fichiers d'index/liste/paramétrage sont-ils stockés et accédés dans les répertoires réseau "à côté" des fichiers eux-mêmes ?
- Peut-on désactiver la recherche "à la frappe" et ne la déclencher que par une "entrée" ?
- Suis-je trop exigent et dois-je mettre un layout moins gourmand ?

Merci +++ !
(gMusicbrowser roXXe)

D'abord, pour ce qui est du NAS, le seul problème possible est lors de l'ajout des fichiers, par défaut gmb ne fait d'estimation de la durée des mp3 et pour les mp3 qui n'ont pas d'entête VBR, cela veut dire lire tout le fichier, ce qui est déjà un peu long sur un disque local, et encore plus sur un NAS. Mais il devrait y avoir une barre de progression pendant cette phase, donc si elle n'est pas là, ça n'est probablement pas le problème.

Sinon, c'est très possible que ça soit juste trop lent. La recherche à la frappe peut être un peu gênante, même avec une machine plus rapide, ça dépend bien sûr beaucoup des paramètre de recherche et du nombre de chansons, j'ai pensé à ajouter une option pour changer le temps d'inactivité après lequel la recherche est faite. (Un problème pour ça, est que le délai actuel n'est pas le même lorsqu'il n'y a qu'1 ou 2 caractère), ou je devrais peut-être juste l'augmenter un peu. Pour info, pour l'instant (et ça serait difficile à changer) chaque recherche ne peut pas être interrompue,

On peut désactiver la recherche dans le menu d'option de la recherche : cliquer sur l'icône à gauche dans la barre de recherche, et désactiver "Filtre Automatique". Pour accélérer la recherche, on peut aussi, dans le même menu, dé-selectionner des champs.

Quote- Tout rafraichissement des listes (artiste, album, piste) est très lent.
Pour ça on peut pas y faire grand chose. Utiliser un SongTree au lieu d'un SongList peut changer les choses, le remplissage d'un SongList est un peu long, le SongTree est par contre plus lent pour rafraîchir la vue. Sinon enlever des colonnes ou réduire la taille de la vue peut aider.

Quote- Des fichiers d'index/liste/paramétrage sont-ils stockés et accédés dans les répertoires réseau "à côté" des fichiers eux-mêmes ?
non, tout est dans la mémoire/swap (et sauvegardé dans le fichier gmbrc), s'il n'y a pas assez de mémoire ça peut causer des ralentissements, 3Gb devrait largement suffire, mais bien sûr ça dépend des autres programmes.

Quote- Suis-je trop exigent et dois-je mettre un layout moins gourmand ?
Non je ne pense pas, les 3 FilterPanes au dessus de la liste de chansons peuvent peut-être ralentir la recherche un peu, il suffit de les mettre sur l'onglet "sauvegardé(e)" pour voir si ça fait une différence.

Quelqu'un d'autre s'est plaint de lenteurs dans la barre de recherche, et ça m'a donner envie d'essayer un truc. Et contrairement à ce que j'ai dit dans ma réponse précedente, faire des recherches interruptible n'était pas si dur que ça.
Donc bonne nouvelle ça marche bien et c'est dans la version git actuelle :)

Superbe !

Je voulais faire une réponse plus détaillée mais je n'en ai pas eu le temps.
Pour avoir testé, on gagné un poil de réactivité en limitant le nombre de vues complexes, mais ce n'est qu'une impression (vue latérale gauche Albums plus réactive que vue liste de lecture exhaustive)... C'est vraiment la recherche à la frappe qui fige, le problème de fond.

Donc good news ! Je vais regarder comment installer la version du Git, sauf si une màj officielle arrive bientôt (c'est aussi un serveur de dev/test, je ne peux pas prendre trop le risque de le pourrir :o).

Merci.

Il y aura une maj officielle dans quelques semaines.
Mais sinon il n'y a pas besoin d'installer la nouvelle version pour la tester, il suffit d'avoir les fichiers dans un répertoire (soit par git, soit en décompressant un snapshot) et de lancer le fichier gmusicbrowser.pl

Bonjour,

Avec un certain délai voici un feedback : la dernière version 1.1.12 est nettement plus réactive dans les recherches. Ca ne se fige plus, c'est fluide !
Merci ++ !!

En espérant que ce logiciel continue à vivre.