gspock

.... tu veux bien dire $DEFAULT_LANG='fr'; (au lieu de 'fre') ? P.S les films sont ok en français, mais j'arrive pas à avoir les séries en français, ça reste toujours dans la langue maudite ...

Salut, va jetter un coup d'oeil ici : Salut, non, ça n'est pas activé chez moi ; par contre, si le surveillance station tourne (même si toutes les caméras sont éteintes) alors il ne passe plus en veille, ce qu'il faisait en 4.0. S'il y a un disque externe e-sata, il ne passe plus en veille non plus, alors qu'il le faisait en 4.0 ...

Si ça peux t'aider, voici un lien dropbox avec la patch en question : http://db.tt/ds0mFly7 GS

.... sauf si un disque sata externe est connecté ... dans ce cas, je retombe sur le phénomène que le syno se met en veille puis se rallume directement .... pppfffff .... c'est à ne plus rien comprendre, car tout ça marchait nickel en 4.0 ....

... mais par contre, j'ai toujours le message suivant dans /var/log/messages : net_default_gateway_set.c:36 failed to set default gateway 192.168.1.1 (-1). :blink: Et depuis l'application du patch, il semble que quelque chose réveille la "bête" +/- toute les heures ... Sep 7 12:41:29 kernel: [ 1386.200000] ata1: wake up from deepsleep, reset link now Sep 7 12:41:36 kernel: [ 1393.230000] ata2: wake up from deepsleep, reset link now Sep 7 14:08:46 kernel: [ 3668.960000] ata1: wake up from deepsleep, reset link now Sep 7 14:08:53 kernel: [ 3675.990000] ata2: wake up from deepsleep, reset link now Sep 7 15:09:07 kernel: [ 7290.020000] ata1: wake up from deepsleep, reset link now Sep 7 15:09:14 kernel: [ 7297.050000] ata2: wake up from deepsleep, reset link now Sep 7 17:09:28 kernel: [14511.030000] ata1: wake up from deepsleep, reset link now Sep 7 17:09:35 kernel: [14518.060000] ata2: wake up from deepsleep, reset link now Sep 7 18:09:46 kernel: [18129.060000] ata1: wake up from deepsleep, reset link now Sep 7 18:09:53 kernel: [18136.090000] ata2: wake up from deepsleep, reset link now Sep 7 19:10:06 kernel: [21749.090000] ata1: wake up from deepsleep, reset link now Sep 7 19:10:13 kernel: [21756.120000] ata2: wake up from deepsleep, reset link now Sep 7 20:10:27 kernel: [25370.140000] ata1: wake up from deepsleep, reset link now Sep 7 20:10:34 kernel: [25377.170000] ata2: wake up from deepsleep, reset link now Sep 7 21:10:45 kernel: [28988.190000] ata1: wake up from deepsleep, reset link now Sep 7 21:10:52 kernel: [28995.230000] ata2: wake up from deepsleep, reset link now Sep 7 22:11:06 kernel: [32609.250000] ata1: wake up from deepsleep, reset link now Sep 7 22:11:13 kernel: [32616.280000] ata2: wake up from deepsleep, reset link now Sep 7 23:11:24 kernel: [36227.300000] ata1: wake up from deepsleep, reset link now Sep 7 23:11:31 kernel: [36234.330000] ata2: wake up from deepsleep, reset link now Sep 8 00:11:44 kernel: [39847.350000] ata1: wake up from deepsleep, reset link now Sep 8 00:11:51 kernel: [39854.380000] ata2: wake up from deepsleep, reset link now Sep 8 01:12:05 kernel: [43468.410000] ata1: wake up from deepsleep, reset link now Sep 8 01:12:12 kernel: [43475.440000] ata2: wake up from deepsleep, reset link now Sep 8 02:12:26 kernel: [47089.460000] ata1: wake up from deepsleep, reset link now Sep 8 02:12:33 kernel: [47096.490000] ata2: wake up from deepsleep, reset link now Sep 8 04:12:47 kernel: [54310.570000] ata1: wake up from deepsleep, reset link now Sep 8 04:12:54 kernel: [54317.600000] ata2: wake up from deepsleep, reset link now Sep 8 06:13:08 kernel: [61531.680000] ata1: wake up from deepsleep, reset link now Sep 8 06:13:15 kernel: [61538.710000] ata2: wake up from deepsleep, reset link now Sep 8 07:31:53 kernel: [66257.000000] ata1: wake up from deepsleep, reset link now Sep 8 07:32:00 kernel: [66264.030000] ata2: wake up from deepsleep, reset link now Sep 8 09:04:56 kernel: [71840.000000] ata1: wake up from deepsleep, reset link now Sep 8 09:05:14 kernel: [71847.030000] ata2: wake up from deepsleep, reset link now

... Voici mes constatations avec mon 212+: 1) le patch règle le problème 2) par contre le comportement du syno est différent sur les conditions pour se mettre en veille. Je m'explique : AVANT la 4.1, il se mettait en veille même si le surveillance station tournait, pour autant que les caméras soient coupées. En 4.1, il faut absolument que le package surveillance soit arrêté, sinon pas de veille mêmes si toutes les caméras sont coupées

Je viens d'appliquer le patch .... je vais voir ce qui se passe et ferai un retour tout à l'heure ....

... c'est ce que j'ai fait, et malgré cela, ça ne marche toujours pas ....

oui et oui ....

Bonjour Pascal et merci pour l'info. J'ai suivi la manip telle qu'indiquée sur le site US, mais ça ne marche pas chez moi, la bête refuse toujours de dormir .... GS

J'ai fait une demande officielle de support à Synology pour ce problème .... j'attends leur retour .... En effet, chez moi aussi le package s'est installé mais il n'est pas démarré !!! Dingue ça ... Comment fait-on pour le déinstaller ???

Je voudrai pouvoir activer l'hibernation prolongée des disques. (ce qu'il faisait tout seul avant l'upgrade à 4.1 ...) GS

Bonjour, Y-a-t il une commande en SSH pour forcer le syno a se mettre en veille ? Merci, GS

1) je n'ai pas constaté de problème pour changer les droits des utilisateurs 2) cela en effet te permets de donner accès à un utilisasteur à photostation par ex, au lieu de donner l'accès à tout via la console d'admin. Cela permet une meilleur "granularité" de qui peut avoir accès à quoi ....

J'ai désactivé le videostation et malgré cela, il ne repasse plus jammais en veille .... Face recognition, j'utilise pas !

... j'ai mis fre au lieu de fr, ça fonctionne mieux ....

Merci pour ta réponse ; l'indexation est finie (vérif faite en ssh par ps -ef) mais il reste "éveillé" ....

Salut, je pense que tout est dit dans le titre .... sauf que c'est la version 4.1 officielle que j'ai installé vendredi dernier .... avez-vous constaté la même chose ? GS

Salut, il y quelque chose qu m'échappe : j'utilise file station, audio station et ds cam en HTTPS sans aucun problème, et j'ai choisis des ports spécifiques pour chacun que je redirige bien sur au niveau de mon routeur netgear. Par contre, avec PhotoStation, que j'essaye HTTP ou HTTPS en renseignant des ports spécifiques (comme prévu sur la page paramètres du photostation) et en les redirigeant, rien ne fonctionne depuis l'extérieur. C'est comme si il y avait quelque chose qui essaye toujours de passer par le port ou le port 443 (ces deux là sont bloqués par defaut par mon ISP, et je n'ai pas envie de les débloquer). Une idée ? Merci, GS

... c'est également indispensable si tu veux utiliser le Cloustation à partir de ton entreprise, car alors toutes les informations seront stockées en clair dans les logs du firewall (y compris le username et le password, disponible facilement à n'importe quel admin.)

Oui, même problème avec mon nom sur dynalias.net

Salut, Je ne suis pas certain de bien comprendre ta question, si celle-ci est : peut-on joindre un fichier qui se trouve dans le répertoire de cloudstation dans un email, il n'y a pas de raison que ça ne marche pas ....

Salut, pourrais-tu aussi remonter l'infos d'avoir la possibilité de spécifier des paramètres "proxy" dans le setting de cloudstation? Cela me permettra de le faire fonctionner comme dropbox à partir de mon PC d'entreprise (où dropbox est accepté). Merci, GS P.S. Je dois dire que pour une version beta, c'est déjà franchement très très bon ....

6690, et pas moyen de le changer apparemment !