CoolRaoul

@StephB Un paquet WOL ("magic packet") est de type *broadcast* et n'est par conséquent visible que par les équipements connectés au même réseau. Les équipements connectés au sous-réseau du VPN (en général different du subnet LAN) sont les seuls qui vont voir passer la trame WOL et ceux-ci sont forcément déjà éveillés. Voila pourquoi j'ai indiqué la nécessité de disposer d'une box ou routeur faisant proxy WOL. Dans ce cas le paquet WOL unicast entrant sur la patte WAN est converti en paquet broadcast sur la patte LAN. Et ce n'est pas une règle de routage (avec une ip fixe en destination) qui résoudra le pb: un broadcast est obligatoire puisque la machine à réveiller n'a pas encore d'adresse IP tant qu'elle est dans cet état (à moins de bidouiller avec des entrées statiques permanentes dans la table ARP de la box mais là ça devient de la grande sorcellerie)

Petit retour d'expérience. Ma base Keepass de référence est stockée sur mon NAS dans un dossier géré également par Drive. J'y accède de diverse manière: en WebDav sur SSL depuis mon lieu de travail en SFTP depuis mon smartphone. en SMB depuis mon réseau local (PC et tablette) via le dossier partagé Drive sur le PC de ma mère (quand je passe faire du support informatique à domicile). Tout cela fonctionne et se synchronise sans problème dans tous les sens. Sachant que dans Keepass, que ce soit la version Windows que la version Android, la fonction "enregistrer" est en fait une synchronisation bi-directionnelle il n'y a pas trop de risque de perdre une modif. En outre, le fait que ma base soit stockée dans Syno Drive me fait implicitement bénéficier du versioning intégré ce qui permet un éventuel retour arrière rapide en cas de fausse manip.

Sur mon smartphone Android j'utilise cette appli qui me satisfait: https://play.google.com/store/apps/details?id=co.uk.mrwebb.wakeonlan Dans la mesure ou votre box sait faire du proxy Wake on LAN (ce qui est le cas de celles de Free) ça fonctionne également à distance. Et même plus besoin du paquet sur le NAS

Oui: toutes les modifications (ajouts et suppressions) de fichiers faites par des scripts ou en ligne de commande ne sont pas détectées par l'indexeur. Seul les modules/paquets natifs DSM (samba/ftp/webdav/... serveur, et autres filestation, cloud-bidule, etc etc ..., gèrent ce genre cette situation). Il faut donc utiliser la commande "synoindex" (/usr/syno/bin/synoindex) pour activer un rescan, total ou partiel. Son aide intégrée: Usage: synoindex [OPTIONS] Index Options: -h, --help this help text -A dirpath add a dir -a filepath add a file -D dirpath delete a dir -d filepath delete a file -N new_dirpath old_dirpath rename a dir -n new_filepath old_filepath rename a file -R [all|media|photo|music|video|thumb|dirpath] all: reindex all dirpath that registered in each package media: reindex dirpath that registered in MediaIndex package photo: reindex photo dirpath music: reindex music dirpath video: reindex video dirpath thumb: check converted video of each video file dirpath: reindex this specific dirpath -R user:{user_name} reindex personal photo dirpath -R share:{share_name} reindex share dirpath -R [type_music|type_video|type_photo] reindex dirpath that registered with specific type in MediaIndex Package Index Options: -P [MediaIndex|{package_name}] {index_option} index operation only apply on this package -p [MediaIndex|{package_name}] {index_option} index operation apply all packages except for this package File Index Options: -f {index_option} index operation apply on file index -U photo update photo images Dans le cas présent je pense qu'in "synoindex -R /chemin/du/dossier/modifié" devrait faire l'affaire NB: la commande rend la main immédiatement, c'est normal, ça envoie juste un message à gestionnaire d'indexation qui fait le boulot en tache de fond.

J'ai ce problème depuis des lustres. Je ne suis pas sur que le support Synology veuille traiter ce problème alors j'aimerais avoir votre avis Une tache programmée avec utilisateur *non root* se retrouve avec l'environnement suivant: MAILTO= SHELL=/bin/sh USER=root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin _=/bin/env PWD=/root HOME=/root SHLVL=2 LOGNAME=root Les valeurs de "USER", "LOGNAME" et "HOME" sont incorrectes. Bien entendu il est possible de forcer les bonnes valeurs en début de tache mais je suis étonné qu'une telle anomalie n'ait toujours pas été corrigée depuis le temps.

Je constate dans les logs des tentatives de connections échouées sur le VPN. Exemple: 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: responding to Main Mode from unknown peer 216.218.206.66 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: OAKLEY_CAST_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: no acceptable Oakley Transform 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: sending notification NO_PROPOSAL_CHOSEN to 216.218.206.66:14025 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: deleting state #30 (STATE_MAIN_R0) 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66: deleting connection "L2TP-PSK-NAT" [whackfd=4294967295] instance with peer 216.21 8.206.66 {isakmp=#0/ipsec=#0} Pourtant ça ne provoque pas de blocage d'IP. Aurais-je oublié une option?

Suffit de s'assurer qu'elle peut faire tourner une application comme VLC par exemple, le paquet embarque ses propres codecs https://play.google.com/store/apps/details?id=org.videolan.vlc "All formats are supported, including MKV, MP4, AVI, MOV, Ogg, FLAC, TS, M2TS, Wv and AAC. All codecs are included with no separate downloads. It supports subtitles, Teletext and Closed Captions." A partir du moment ou c'est un appareil Android ca ne devrait pas poser de problème.

Ceci est juste un lien vers un article comparant les différentes versions de Chromecast. En aucune façon ca ne peut démontrer que la doc présentée dans ta video est une doc officielle Chromecast. La preuve que ca ne peut pas être le cas est que cette dernière ne gère pas Miracast (et encore moins Airplay !!) contrairement à ce qui est visible à l'offset 0:14 Mais il n'installe pas les codecs sur la Chromecast (ce qui reviendrai à en modifier le firmware), il utilise ceux du téléphone (ou d'autres ajoutés par l'appli elle meme). C'est ce qui lui permet de transcoder à la volée. C'est d'ailleurs clairement expliqué dans l'aide intégrée à BubbleUPNP (section "transcodage Chromecast") Suffit de faire le test que j'ai détaillé pour se rendre compte que dès que le téléphone n'est plus disponible le flux est interrompu dans le cas de vidéos non compatibles (pas la peine de mettre hors tension le téléphone, suffit de le basculer en mode avion). Ce test est trivial à faire, je l'ai refait ce matin avant de poster pour m'assurer de ne pas dire de bêtises. Je l'ai reproduit à plusieurs reprise avec deux sources sur mon NAS (une compatible et l'autre non) ,et c'est systématique et reproductible à volonté. NB: Pour vérifier si une video est compatible Chromecast il suffit d'essayer de la caster via DS Video, dans le cas de video non compatible on se retrouve avec cette erreur: Et la même video castée via Bubble sera transcodée à la volée. Ca ne dépend pas du container (que ce soit mkv, avi, mp4 ou autre) mais de *l'encodage* utilisé pour les flux audio et video inclus. Et c'est pas la Chromecast qu'on doit éteindre pour valider le test mais le téléphone, bien entendu (mais j'imagine que c'est une faute d'inattention)

Un deal sur la Box Xiaomi qui tombe à point: https://www.dealabs.com/bons-plans/box-tv-xiaomi-mi-3-international-entrepot-france-5eur-en-superpoints-4199eur-avec-le-code-soldes849-1454201

La doc montrée dans cette vidée n'est pas la doc de la Chromecast officielle mais celle d'un dongle qui implémente la fonction Chromecast (et Miracast au passage). Probablement un truc dans le genre de ceci ou cela

J'ai pris sur mon temps pour un peu creuser la question et il s'avère cela est exact *uniquement* dans les cas où la vidéo utilise un codec nativement supporté par la Chromecast. Dans les autres, Bubble effectue un transcodage à la volée sur le téléphone (ce qui est bien gourmand en ressources au passage) ou éventuellement sur le NAS (sous réserve d'installer le paquet BubbleUPnP Server sur ce dernier. Mais la aussi ça va demander du CPU ce qui peut-être également problématique sur un Syno d'entrée de gamme). En plus il est codé en Java ce qui m'incite à penser que la consommation mémoire va en prendre un coup aussi. Tout cela est documenté dans l'aide intégrée : paramètres -> "transcodage chromecast" - > bouton aide ("?") : "Chromecast can natively play only these media formats: audio: MP3, AAC, Vorbis, Opus, FLAC, WAV video: H.264, VP8 (+ HEVC and VP9 for Chromecast Ultra). Audio must be AAC (stereo only), MP3, Opus BubbleUPnP can transcode non natively supported media whenever necessary to make it playable." C'est simple à vérifier d'ailleurs (je viens de le faire à l'instant): il suffit de lancer la lecture d'une vidéo de format non supporté par la clé puis arrêter le téléphone. La lecture stoppe peu après des que le buffer est vide. Le même test avec une vidéo utilisée utilisant un codec supporté et la lecture ne s'interrompt pas. Ce n'est bien que dans ce cas que le flux est direct entre NAS et Chromecast.

La video confirme ce que j'ai écrit: Bubble tourne ici sur un *smartphone*, et pour caster sur la Chromecast il fonctionne en *passerelle* entre le serveur DLNA et la Chromecast. Par suite, dans cette config, il n'y a pas de flux direct NAS => Chromecast. Pour que le flux ne soit pas interrompu il est nécessaire de laisser tourner Bubble sur le smartphone, au moins en tache de fond. Si on tient vraiment à utiliser une Chromecast on peut ici remplacer avec avantage Bubble par DS Video sur le smartphone (qui supporte nativement la Chomecast et activera un flux direct). Mais une fois de plus ce n'est pas l'objet de la demande initiale qui parlait explicitement de *box*.

Bubble UPNP ne fait pas *que* client DLNA. il permet aussi de caster sur Chromecast . En fait il fait "passerelle" entre un serveur DLNA et la chromecast, mais c'est une solution à mon avis un peu bricolée Et dans tous les cas il faut un appareil Android pour héberger Bubble, et donc autant une vrai box dédiée qu'un téléphone (d'autant plus que ça répond mieux à la question du fil: "Box pour connecter son synology")

Je ne pense pas non . Sinon, comme box TV je suggérerai de plutôt de regarder du coté de ceci: https://www.journaldugeek.com/test/test-xiaomi-mi-box-s/3/ Autre option, si tu veux en plus pouvoir jouer confortablement, l'incontournable Nvidia Shield (mais c'est plus cher). Sur ces box il sera possible d'installer DSVideo ou bien un player compatible DLNA comme VLC (parmi beaucoup d'autres)

Oui mais ça risque de devenir un peu compliqué à lire pour gérer fichiers et dossiers, faudrait falloir jongler avec des clauses "ou" ("-o") et des parenthèses dans le find (le "-empty" ne doit s'appliquer qu'aux dossiers, pas aux fichiers) Ca ne mange pas de pain et est plus lisible de faire ça en deux lignes. Les fichiers en premier et les dossiers vides ensuite : # purge des fichiers de plus de 2 mois find "/volume1/video/netatmo welcome" -type f -mtime +60 -delete # purges des dossiers vides find "/volume1/video/netatmo welcome" -mindepth 1 -depth -type d -empty -delete NB: le -mindepth 1 que j'ai ajouté a pour effet pour ne traiter que les dossier de niveau 1 et plus et donc pas "netatmo welcome" lui même pour ne pas l'effacer au cas ou si il se retrouve vide.

Tu peux aller au plus simple en effet: find /le/chemin/de/ton/dossier/video -depth -type d -empty -delete Note: le "-depth" est une astuce qui permet de supprimer les dossiers éventuellement pas vides mais qui ne contiennent que des sous-dossiers vides: supposons un chemin "a/b/c" où a , b et c ne contiennent rien d'autre que ces mêmes dossiers, sans le "-depth", seul "c" serait supprimé, alors qu'avec "a" et "a/b" sont également supprimés. Tu as écrit que "le chemin est: /volume1/video/netatmo welcome" Si il n'y pas d'erreur ici (c'est à dire qu'il y bien un un blanc entre "netatmo" et "welcome", autrement dit que le dossier cible se nomme "netatmo<espace>welcome"), alors, pour que ça marche, il faut entourer le tout de quotes, comme ceci: find "/volume1/video/netatmo welcome" etc ...

Je ne serais pas étonné que tu sois tombé sur la même erreur de copier/coller que celle rencontrée ici: https://www.nas-forum.com/forum/topic/38513-copie-automatique-du-disque-dur-freebox-vers-le-synology/?do=findComment&amp;comment=1319359828

Faut d'abord t'assurer que le paquet "perl" est installé dans le centre de paquet du syno. Ensuite je préconise de commencer par lancer le script dans une fenêtre terminal (putty ou équivalent) connectée au NAS sur le compte "admin" en ligne de commande shell: perl /chemin/de/wakeonlan.pl <parametres> ... C'est quand même plus facile pour la mise au point Ensuite tu pourra passer par le planificateur:

Ce script perl pourrait faire l'affaire: Source Perl de Wake-On-Lan NB: Je n'ai pas personnellement testé pour que ca fonctionne l'IP doit être celle du routeur derrière lequel se trouve le PC à réveiller et que celui-ci (le routeur) soit configuré pour faire proxy wake on LAN

Je n'avais pas compris qu'il était ici question de DSvideo sous Windows 10 (à vrai dire je découvre à cette occasion que ça existe). Je n'ai pas la moindre idée de réponse dans ce contexte.

J'ai trouvé ça au moment du renouvellement auto: $ grep builtin-dyn-syno-letsencrypt-syno-letsencrypt messages 2018-10-02T21:59:45+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:20 synoservice: reload [nginx]. 2018-10-02T21:59:52+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:46 synoservice: finish reload [nginx]. 2018-10-02T21:59:56+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:20 synoservice: reload [nginx]. 2018-10-02T22:00:05+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:46 synoservice: finish reload [nginx]. 2018-10-02T22:01:20+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:20 synoservice: reload [nginx]. 2018-10-02T22:01:25+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:46 synoservice: finish reload [nginx]. 2018-10-02T22:01:25+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:20 synoservice: reload [synorelayd]. 2018-10-02T22:01:25+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:46 synoservice: finish reload [synorelayd]. 2018-10-02T22:01:25+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:20 synoservice: reload [synorelayd]. 2018-10-02T22:01:25+02:00 fserv builtin-dyn-syno-letsencrypt-syno-letsencrypt - renew: service_reload.c:46 synoservice: finish reload [synorelayd]. C'est dans /var/log/messages

Ahrrghhh .. Une grosse partie du formatage des anciens messages saute dans la migration (en gros ne reste que les citations et les images) Avant: Apres: Et pour couronner le tout c'est à chaque utilisateur synchroniser son ancien compte, sinon aucun des anciens fils qu'il avait ouvert ne sera migré et tous resterons invisibles dans le nouveau forum

J'ai testé (c'est ici: https://community.synology.com/ ) et je suis effondré devant le nombre de regressions! lors de la migration une grande partie de mes posts est passé à l'as. Mon profil sur l'ancien forum m'affiche 560 posts. Le nouveau m'indique 16 au total et encore je n'en vois que 5 créés et 5 réponses. Je constate d'après d'autres commentaires que je ne suis pas seul dans ce cas. si on veut répondre à un commentaire en particulier, on perd au passage la possibilité de citer (quoter) et toute option de formatage (texte brut exclusivement). On peut bien entendu répondre en fil de fil (et heureusement qu'on dispose de la balise "blockquote" mais alors le flux message/réponse est cassé) tous mes abonnements (fils suivis) sont perdus impossible d'afficher les fils mis à jours (ne parlons pas d'ordre chronologique) etc... etc... (je ne saurais pas faire la liste j'en découvre sans arrêt) Ce forum-ci n'a rien à craindre de la comparaison! **EDIT** Un commentaire qui résume bien la situation: Hello and goodbye... **EDIT#2** A propose des 5 réponses par colonne, j'avais pas remarqué le minuscule bouton "suivant". Reste que je suis loin du compte il me semble.

Une fois de plus je m'aperçois que copiers/coller à partir du forum semblent merdouiller pour certains caractères (en particulier les "-") Ca me l'a fait la aussi. Copie la commande dans notepad et retape ces derniers (ca a fonctionner pour moi en pratiquant comme ça) avant de la copier dans la fenètre terminal DSM

Sont quand même forts chez Apple! Mais où vont-ils chercher tout ça?