CoolRaoul

me pose aussi la question: un home cinema sans entrée video n'est qu'un banal ampli audio dans ce cas, non?

DS Photo n'utilise pas les meme ports que DS Audio et DS File: http://www.synology.com/fr-fr/support/faq/299 possible que tu n'ais pas du redirigé tous les ports nécessaires dans ta box

IL y a beaucoup de chances que le problème soit coté TVIX et va donc falloir attendre l'avis de connaisseurs de cet appareil, ce qui ne cours pas forcément les rues, et peut également expliquer l'absence de réponse.

Aucune idée: vu que chez moi cette option a toujours été désactivée Te restes toujours l'option de redémarrer le NAS

Panneau de configuration -> Bibliothèque Multimédia -> Paramètres de conversion je pense

Ce sont *deux* produits différents ("Play" et "Live"), le modèle de base devrait être suffisant (la principale différence est qu'il ne gère que le protocole DLNA)

En complément, pour quelqu'un qui cherche un appareil simple et pas trop cher, la gamme Western Digital me semble appropriée (http://www.wdc.com/fr/products/homeentertainment/mediaplayers/) **edit** Ah j'ai oublié, pour encore moins cher il y a la solution chromecast, il est compatible videostation mais je ne suis moins sur pour la musique (audiostation). Uniquement WIFI par contre.

Jeter un oeil dans le moniteur de ressources, sections "processus" Trier sur la colonne "processeur" par ordre décroissant. Y a-t-il un process en particulier tres consommateur, si oui quel est son nom?

Ah, là ça va m'être difficile: je suis un "old timer" dans le domaine, et à l'époque ou, débutant, j'aurais eu l'occasion de fréquenter ce genre de site, internet existait à peine!

Je suppose que tu fais référence à Si le script "start-stop-status" du package respecte bien la norme de codage (pas toujours le cas avec certains packages tierce partie exotiques), il suffira de l'invoquer avec comme argument "status" et tester le code de retour. Autrement dit et par exemple dans le cas de DownloadStation: if /var/packages/DownloadStation/scripts/start-stop-status status ; then echo >&2 "Download station est actif" else echo >&2 "Download station est arrété" fi

le formalisme ">&2" sert à rediriger la sortie (de "echo" ici ) vers la sortie d'erreur plutôt que vers la sortie standard. C'est une bonne habitude à prendre de distinguer ainsi les messages d'info et de diagnostic des données. Par exemple, en adoptant cette approche, dans le cas d'un "pipe" les messages d'erreur resteront visibles à l'écran (ou dans le log dans le cas d'un batch) plutôt que se perdre dans le "tuyau".

Je n'ai pas trouvé ces options chez moi dans les propriétés des fichiers, ça ne serait pas exclusif à la version Windows 8 par hasard? (suis sous seven) **edit** par contre je peux choisir de synchroniser uniquement certains dossiers: C'est de ça qu'il est question?

Sous Photo Station, dans les propriétés de l'album, à "type de premissions" ne pas mettre "album public": Et, pour que les albums créés par la suite n'aient pas cet attribut, dans les propriétés générales de PhotoStation ne pas cocher cette case:

De mon coté il n'y a aucun doute, je peux également visualiser le traffic via tcpdump d'ailleurs et ça confirme mon analyse. Bien entendu et ça me semble normal. Étrange, moi je vois bien "en ligne". Ça passe "hors ligne" des que je met l'appareil hors tension (power off) ou si je force le client DScloud en "pause" (immédiatement dans le 1er cas et avec un petit délai dans le deuxième ) Testé à l'instant sur tablette et sur smartphone.

Je déterre ce vieux fil car je viens de m'apercevoir que par défaut, "strace" trace uniquement l'activité du *thread principal*. Pour avoir une vision complete faut le switch "-f" strace -f -p <pid> que j'avais sans doute oublié, ce qui explique mes observations. (j'étais persuadé que la seule fonction de "-f" était de tracer les process fils en suivant les "fork", je n'avais pas percuté qu'il y avait aussi un rapport avec les threads, mea culpa)

Salut à tous, Ca faisait longtemps que j'avais remarqué que mon NAS laissait entendre une activité disque à intervalles réguliers à toute heure du jour et de la nuit. J'ai enfin pris un peu de temps pour essayer de comprendre la cause du phénomène. Me suis cross compilé un exemplaire de inotify-tools et je pense avoir mis le doigt sur la source de ce comportement: fserv> inotifywait -m -r --timef "%H:%M:%S" --format "%T %f %e" /volume2/@cloudstation/@sync Setting up watches. Beware: since -r was given, this may take a while! Watches established. 09:38:12 syncfolder-db.sqlite ACCESS 09:38:17 syncfolder-db.sqlite ACCESS 09:38:22 syncfolder-db.sqlite ACCESS etc ... Et le coupable est ... fserv> lsof /volume2/@cloudstation/@sync/syncfolder-db.sqlite COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME syncd 11220 root 12u REG 9,3 4787200 1441796 /volume2/@cloudstation/@sync/syncfolder-db.sqlite On constate que le process syncd (fait partie de cloudstation) fait un acces à "syncfolder-db.sqlite" toutes les 5 secondes. En grattant un peu plus avant ça se confirme: fserv> strace -e read,access -fp 11220 Process 11220 attached with 8 threads [pid 21122] read(16, "273311", 5) = 5 [pid 21122] read(16, "35221022422334204Y24532n4222*B363K255I+246d=H23rS275?373333;O"..., 257) = 257 [pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory) [pid 21122] read(12, "00/w0022C00t220021223", 16) = 16 [pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-wal", F_OK) = -1 ENOENT (No such file or directory) [pid 21122] read(16, "273311", 5) = 5 [pid 21122] read(16, "n376^10230>210O;[Q362}25334Q<N266242200233y|360023521630427324C"..., 257) = 257 [pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory) [pid 21122] read(12, "00/w0022C00t220021223", 16) = 16 [pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-wal", F_OK) = -1 ENOENT (No such file or directory) [pid 21122] read(16, "273311", 5) = 5 [pid 21122] read(16, "331271ij257^R30627;33724'315'242fv_353DTt261352D246tK377250G"..., 257) = 257 [pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory) [pid 21122] read(12, "00/w0022C00t220021223", 16) = 16 [pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-wal", F_OK) = -1 ENOENT (No such file or directory) Je vous épargne les détails mais en continuant à creuser je me suis aperçu que la cause initiale était le client DSCloud de mon smartphone qui génère un traffic TCP avec le NAS (port 6690) toutes les 5 secondes (les "read" sur le FD 16 ci dessus). En mode nominal le traffic mesuré est de 262 octets (257+5) à chaque itération (au passage il y intérêt a configurer le client androïd en mode "synchro sur wifi uniquement" sinon bonjour le forfait data, ca fait quand même plus de 4MB/jour! ...). Des que je le met en "pause" tout se calme. Mis à part le fait que c'est un poil gonflant d'entendre régulièrement cet accès disque, je me demande si à la longue ça ne peut pas avoir une incidence négative sur la durée de vie du disque (j'imagine que ça correspond à une lecture répétitive du même bloc). Je n'ai pas activé l'hibernation pour maximiser la durée de vie de mes disques (de toutes façon je ne vois pas comment le NAS pourrait hiberner alors que le démon cloudstation se réveille toutes les 5 secondes) et donc je me dis ça serait un peu dommage que ce phénomène produise l'effet inverse. Qui aurait un avis sur tous ces points? Le comportement de DS Cloud vous semble-t-il normal? (ne serait-il pas possible qu'il soit prévenu de façon asynchrone des changements nécessitant une synchro, ce fonctionnement par "polling" me semble un peu artisanal)

Il y existe *déjà* un fil sur le même sujet ici: Il est tout récent en plus, comment avoir pu le louper?

Zut, je ne parviens pas à le reproduire J'ai ajouté cette règle en tête du firewall: et ensuite j'ai installé un package sans difficulté. Il faudrait, pour avoir le cœur net, décocher la case "activé" de la règle firewall et essayer d'installer un package dans cette configuration. Si ça ne marche toujours pas pour toi, faudra peut-être chercher ailleurs.

Etrange de commencer par écrire "je ne sais pas ..." puis donner la réponse juste après, à savoir ce message d'erreur (qui n'était pas indiqué dans le post initial, d'ou mon interrogation) Enfin, le principal et que je vais pouvoir essayer de reproduire le phénomène.

Mais c'est *exactement* ce que j'ai écrit, c'est le VPN *Serveur* (celui qui s'installe sous forme de package) au contraire qui ne sert pas à l'anonymat. Alors que toi, tu utilises le VPN *client* que tu as donc configuré comme ceci: Il va juste *essayer* de se rabattre sur la connexion existante, mais comme rien n'est redirigé dans ta box il sera de fait coupé du monde pour les connexions entrantes.

Un peu useless cette parano: ton provider a d'autre chats à fouetter que surveiller ce que tu télécharges. Enfin, la n'est pas la question; si il s'agit du VPN *serveur* (comme tu n'a toujours pas précisé, suis bien obligé de prendre en compte les deux hypothèses) , alors qu'il soit UP ou down n'a *strictement aucun* impact sur le téléchargement qui passera directement par ta box dans les deux cas. Si au contraire il s'agit du Package VPN *client* (avec tous les risques en terme de sécurité que j'ai tenté d'expliquer), si il tombe (à moins que si tu ais ouvert les ports torrent dans ta box vers le Syno, mais j'imagine pas que ce soit le cas: ca serait inutile et stupide en utilisant un client VPN) ton client bittorrent va simplement instantanément devenir invisible sur internet (puisqu'il ne sera pas capable d'accepter de connexion entrantes), c'est tout. En fait, j'ai l'impression que tu ne comprend pas très bien le fonctionnement du VPN et ne fait pas la distinction entre serveur et client. Je serai pas même étonné que tu ai cru qu'activer OpenVPN serveur sur le NAS permettrait de te rendre anonyme et invisible alors que ce n'est absolument pas le cas!

C'est exact, intervalle limité à une heure. Mais j'avoue aussi ne pas comprendre ce que tu veux faire. Je suis parti à la pêche aux informations et j'ai découvert que "transmission" était un client bittorrent (pourquoi ne pas utiliser celui intégré au Syno ?) En quoi peut-il être impacté par la présence ou pas du serveur VPN? Et si au contraire il s'agit du VPN *client*, à moins d'avoir redirigé les ports dans ta box, quand le lien VPN tombe le client bittorrent deviendra simplement inaccessible de l'extérieur, dans quel but l'arréter en plus?

Il est accessible par le panneau de configuration

oui s'

Je réalise soudain en relisant ma remarque, qu'en plus d'être HS, il est possible qu'elle ne s'applique pas ici si il est question du VPN "serveur" (et pas client) comme j'en ai le doute. Si c'est bien le cas, tu peux oublier donc ce que j'ai dit juste. Tu ne fais pas les choses a moitié dis-donc! (chmod +x suffit, juste ajouter le droit d'exécution) Tu as utilisé quel éditeur pour créer ce script? peux tu montrer le résultat des commandes: ls -l /usr/local/scripts/toto.sh head -1 /usr/local/scripts/toto.sh N'aurais-tu pas conservé l'espace (qui est présent dans ton message) entre "./" et "toto.sh" ?