CoolRaoul

Donne nous simplement le résultat de chacune des commandes suivantes (sans chercher à décrire le résultat, fait simplement un copier/coller). (seul "cd" ne doit rien afficher, c'est normal). Et attention a bien respecter majuscules/minuscules: echo $HOME echo ~ id cd ls -l .profile

C'est echo $HOME qu'il faut faire pour voir la valeur de la variable! Regarde ce que donne cette commande. HOME est *prédéfini* lors de la création de chaque nouvelle session. Il n'est pas possible qu'il ne le soit pas. Je ne comprend pas ce que tu veux dire par "l'UTF-8 en français par défaut sur mon Syno" . Il n'y a pas vraiment de locale par défaut global sur un syno, chaque package ou service s’initialise comme il le souhaite à sa façon.. Les opérations décrites dans ce fil consistent à *ajouter* le support de l'utf 8 aux locales disponibles sous DSM. A aucun moment on ne parle de mettre quoi que ce soit *par défaut* (sauf pour les session interactives, mais je ne pense pas que tu en ai l'utilité en fait). Tu devrais plutôt décrire ce que tu constates et qui ne marche pas et expliquer ce que tu voudrais à la place. Voici la bonne approche pour décrire un problème si on veut avoir une chance d'avancer: je fais les manipulations suivantes (et là décrire *exactement* ce que l'on fait) je constate ceci (là aussi citer *exactement* ce qui est observé sans rien omettre, éventuellement un screenshot peut être utile) je souhaiterai constater ceci à la place (la aussi description excate et précise du résultat attendu) Ce n'est pas exactement l'approche que tu utilises. Pour ma part je suis complètement perdu, je ne comprend toujours pas ce que tu veux faire.

Que cherches-tu à faire en tapant "$HOME/" ? Tu débutes en unix/linux je suppose? Penses-tu avoir vraiment besoin de faire des manips manips en ligne de commande? Et lesquelles?

Bnn dans /etc/profile comme tu l'a fait Si ca marche pas pour un compte c'est que le profile du compte utilisateur que tu utilise redéfinit LANG Le profile individuel de chaque compte est dans $HOME/.profile Et il n'est pas normal que "HOME" ne soit pas défini. EN shell, tu peux toujours utiliser ~/.profile en lieu et place de $HOME/.profile

Ce n'est pas comme ça que ça fonctionne: "/etc/profile" est exécuté *uniquement* pas les process shell interactifs (typiquement les sessions SSH, telnet), pas par les démons/serveurs. C'est que la variable "HOME" n'est pas définie, ce qui est vraiment surprenant.Tu es bien sur le compte "root"? Faudrait peut-être ajouter la bonne définition de LANG *dans* le script de lancement de YAMJ (et la je ne peux pas t'aider je ne connais pas ce "yamj"). Au passage tu aura remarqué quele sujet de ce fil est owncloud, pas yamj. Pas sur que le support de l'UTF8 par yamj se configure par lintermédiaire de variables d'environnement.

Nb: dans la plupart des cas ne pas utiliser le compte "admin" en shell, il est essentiellement prévu pour l'administration DSM en http. Connais pas désolé. Ben celui que j'ai indiqué: ~/.profile ("$HOME/.profile" si tu préfère) Chaque compte a le sien propre. Nb: Ne pas utiliser le compte admin en shell, il est limité Que veux-tu faire exactement? Faut savoir que ce qui est définié dans les profiles ne s'applique qu'aux session interactives en ligne de commande

Tu es connecté sur quel compte lorsque tu tape la commande "locale"? N'y aurait-il pas une autre affectation a la variable LANG dans le profile du compte (~/.profile) qui écrase la définition globale (celle de /etc/profile)?

Lien vers la dernière version ajouté à la fin du 1er post du fil. Note: je rappelle qu'il est possible de spécifier où se trouve channels.conf sans modifier le script. Suffit de donner si nécessaire ce chemin en paramètre lors de l'appel, comme cela: xml2epg.pl -C <chemin du fichier channels.conf> <url du xml tv> De façon similaire, le chemin du répertoire EPG est aussi parametrable, switch "-d": xml2epg.pl -C <chemin du fichier channels.conf> -d <dossier EPG> <url du xml tv>

Ok, j'ai trouvé étrange que ca s'applique uniquement aux liens recu en MP

Je me demande quel rôle peut bien jouer DS Audio sur Androïd dans cette configuration...

Je vais essayer de diffuser au plus tot, le 1er post du fil sera mis a jour et j'ajouterai les infos complémentaires ici.

Sur la page de DS Audio sur Google Play Store (https://play.google.com/store/apps/details?id=com.synology.DSaudio&hl=fr) dans la partie "nouveautés" on lit: "Gapless playback in streaming mode (to the Android device) as well as in USB streaming mode" Quelqu'un saurait-il expliquer en quoi consiste ce "USB streaming mode" ?

Le proxy de ton boulot doit probablement être un peu restrictif. (tu peux essayer aussi avec un autre navigateur que Chrome, le message d'erreur pourrait être plus explicite) Tu devrais essayer de mettre en place un reverse proxy (ou utiliser haproxy) de façon à pouvoir te connecter sur les port et 443 à la place. Cherche dans le forum les deux methodes sont expliqués

Ce process ne tourne que lorsque le moniteur de ressources est actif dans l'interface web, donc la plupart du temps quasi jamais. Par contre si tu l'observe aussi en faisant un "top" en connexion ligne de commande (ssh ou telnet) la c'est moins normal. Est-ce le cas?

Comme cela:

Si la box est compatible gigabit et le PC aussi ça suffit pour tester! Quand j'ai demandé "est-ce que les autres équipements reliés à la Livebox se synchronisent bien en gigabit de leur coté?", c'est justement au PC que je pensais comme "autre équipement" . J'imaginais alors que tu allais vérifier sur celui-ci dans les propriétés de son interface qu'elle se synchronisait en gigabit, histoire de déterminer si le problème était coté NAS ou coté box. Ta réponse "Je ne sais pas si les autres équipements reliés à la LiveBox se synchronisent en gigabit" m'a ensuite mis le doute: pas de PC connecté à la livebox alors??? Plus curieux la en effet, peut-être aurait-il fallu redémarrer le PC?

Pourquoi nous avoir dit que tu n'avais "que le décodeur TV en plus" connecté sur la livebox lorsque je t'ai demandé de vérifier si les autres équipements (je pensais au PC justement) reliés à la Livebox se synchronisaient bien en gigabit eux?

Lien vers script modifié envoyé en MP aussi On continue les echanges en MP pour tester si c'est OK et une fois confirmé je diffuse cette version.

Déjà commencer par activer le blocage d'IP. Ca va déjà bien calmer les choses (d'ailleurs ça devrait a mon avis systématiquement être activé des qu'un NAS est accessible de l'extérieur) Une autre approche (pas exclusive de la première) est aussi d'utiliser un autre port que le 22 pour ssh. Pour que Timebackup en tienne compte (de la modification du No de port) il y a une manip à faire dont je ne me souviens plus dans l'immédiat mais je sais que ça a été abordé dans le forum. Enfin, Un autre approche encore plus radicale (mais plus simple à implémenter) est, dans le firewall du NAS B, d'ajouter une règle autorisant les connexion sur le port 22 pour l'IP du NAS A suivie d'une règle interdisant les connexion sur ce même port pour toutes les IP. Le NAS du site B n'acceptera que les connexions SSH venant du site A.

Un lien recu en MP, bien que visuellement tout a fait innocent (même en le survolant à la souris) se retrouve transformé en quelque chose du genre: http://api.viglink.com/api/click? format=xxxxxxxxxxxxxxxxx&key=xxxxxxxxxxxxxxxxx&loc=xxxxxxxxxxxxxxxxx&v=xxxxxxxxxxxxxxxxx&libId=xxxxxxxxxxxxxxxxx&out=xxxxxxxxxxxxxxxxx&ref=xxxxxxxxxxxxxxxxx&title=xxxxxxxxxxxxxxxxx&txt=xxxxxxxxxxxxxxxxx&jsonp=xxxxxxxxxxxxxxxxx quand je fais "copier l’adresse du lien" et que je le copie dans un notepad. (j'ai anonymisé le contenu avec des xxx) Ca me le fait avec chrome (ce qui pourrait laisser penser à une extension pourrave bien qu'également en mode "navigation privée", donc avec les extensions désactivée) ainsi qu'avec IE mais *pas* Firefox et uniquement sur le forum. Le même lien dans le message de notification recu par mail ("bidule"a créé une nouvelle conversation personnelle avec vous) n'a pas ce comportement. Perplexe je suis ...

Faudrait commencer par me donner un lien pour récupérer ce fichier "brut" plutôt que le copier/coller dans le message. Je verrai ensuite ce que je peux faire avec. Je suis étonné que tout tienne sur une ligne, mais c'est gérable.

En effet c'est devenu quasiment non mesurable maintenant.

Sur les DS213J penser à (re)patcher le script de démarrage de synorcd pour éviter une conso CPU inutile. Voir ici:

Apres l'upgrade 4.3 et, par suite, du package audiostation n'oubliez pas qu'il faut appliquer de nouveau le fix (bien que la conso de synorcd soit quand même redevenue plis raisonnable me semble-t-il)

J'ai peu d'espoir, le modèle de CPU utilisé par le DS213j est peu répandu et d'ailleurs même Synology ne semble pas prévoir de l'utiliser dans les gammes a venir (DS*14) d'apres ce qui a été annoncé.