CoolRaoul

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?

Dans le cas de rsync, les options longues ("files-from", "times",...) sont préfixées par des tirets *doubles* et les option mono-caractère ("v") par un tiret *simple*.

Non mais je suis tombé également sur cette même erreur après avoir copié collé la commande de la fenêtre du forum vers ma fenêtre de terminal sur le NAS, comme si un caractère bidon et invisible se retrouvait inséré dans l'opération. Essaie, même si c'est gonflant, de retaper intégralement la commande à la main. Au passage je trouve le délai de seulement une minute que tu sembles vouloir utiliser un peu short, mais c'est toi qui vois.

rsync est à mon avis perso la commande standard unix la plus touffue sinon ésotérique. Elle a des tas d'options dont une majorité que je n'ai jamais utilisées, d'autres dont j'oublie régulièrement le fonctionnement exact et très souvent, dès qu'on dépasse (comme ici) les chose basiques, je dois procéder par essais et échecs. **EDIT** Ah, j'oubliais: les fichiers transférés de cette manière ne sont pas indexés automatiquement par DSM et risquent d'être invisibles dans VideoStation par exemple Suffit d'ajouter une commande "synoindex" à la fin de la copie: synoindex -R /chemin/dossier/cible/ Idéalement faudrait le faire que lorsque des transferts ont effectivement eu lieu mais ca nous entraînerait un peu trop loin. Cependant l'indexeur est assez "smart" pour n'indexer que ce qu'il ne connait pas encore.

La page de manuel de rsync est ici: https://linux.die.net/man/1/rsync

m'a d'abord semblé contradictoire avec ce que tu as dis juste avant: Si les fichiers "actualisent en temps réel leur date/heure de modification", je me disais qu'ils ne devraient n'être capturés par le "find -mmin +60" qu'une heure *après* la fin de leur téléchargement. Mais, après vérification, comme le "find" capture aussi les *répertoires*, le "-r" (recursif) de rsync fait que leur contenu est transféré par rsync même si les fichiers contenus dans ces derniers, ont été exclus par la clause "mmin" dans le cas de ceux effectivement récemment modifiés Suffit donc de supprimer le "-r" de rsync, et tant qu'a faire, rajouter un "-type f" au find (rsync sait créer les répertoires intermédiaire si nécessaire) Ce qui donne: ( cd $RepFbx ; find . -type f -mmin +60 ) | rsync -v --files-from=- $RepFbx /chemin/dossier/cible/ Note: le -v ne sert qu'à tracer les transferts à l'affichage. **EDIT** Je m’aperçois qu'il est nécessaire d'ajouter "--times" au rsync sinon les fichiers sont re-transférés à chaque fois, donc: ( cd $RepFbx ; find . -type f -mmin +60 ) | rsync -v --files-from=- --times $RepFbx /chemin/dossier/cible/

Et en quoi c'est un problème?

Je ne vois pas à quoi on peut reconnaitre qu'un fichier n'est pas complètement transféré. A moins que le client torrent de la FreeBox (que je ne connais et n'utilise pas) utilise des noms temporaires bien identifiables. Sinon on peut essayer de filtrer sur la date de modification des fichiers (exclure ceux modifiés dans la dernière heure par exemple). A tester car certains systèmes ne mettent à jour la date-heure de dernière modification à jour qu'à la fermeture du fichier. Ca se ferait de cette manière: (attention c'est sur 2 lignes) RepFbx="/chemin/dossier/freebox/monté/" # le / final est important ( cd $RepFbx ; find . -mmin +60 ) | rsync -rv --files-from=- $RepFbx /chemin/dossier/cible/ "-mmin +60" ne sélectionne que ce qui n'a *pas* été modifié dans les dernières 60mn. A ajuster. Cela dit, maintenant que tu nous a dis qu'il s'agissait de torrents, je ne comprend pas pourquoi tu te compliques la vie à mettre en place cette usine à gaz avec le client torrent de la Freebox alors que DSM propose nativement un paquet de transfert de fichiers qui contient un client torrent: DownloadStation

Automatiquement non, périodiquement oui. Le plus simple est de déclarer dans le planificateur de DSM une tâche programmée : La planification de cette dernière étant à ajuster suivant le besoin. Le script se limitera à une simple commande "cp -u" ("-u": update pour ne pas copier deux fois le même fichier), dans ce genre: cp -v -u -r /chemin/dossier/freebox/monté/ /chemin/dossier/cible/ (à tester à la main avant de la planifier) Restera sans doute à penser à purger le contenu du disque dur Freebox.

Ca ne change rien au fait que quand on tape le chemin d'un exécutable inexistant ("/usr/syno/bin/wget" ici) , root ou pas root, c'est pourtant bien le message "No such file or directory" qui est affiché (alors que je n'avais pas le moindre doute j'ai quand même vérifié) Toute fois la ligne de commande me laisse perplexe: cd </volume2/PLEX-2/>/usr/syno/bin/wget -m --cut-dirs=1 -nH"ftp://mafreebox.freebox.fr/Freebox/Download/""--ftp-user=<freebox>" "--ftp-password=<monmotdepasse>" je ne comprend pas ce qui est cherché à faire avec ce "cd" suivi d'un chemin entre "<" et ">" Et en effet, si c'est bien ce qui à été tapé, le shell voit ">/usr/syno/bin/wget" qui s'interprète comme une *redirection* et dans ce cas le diagnostic ""Permission denied" s'explique **EDIT** J'ai compris: il y a mauvaise interprétation par @Mich Baffle de mon exemple: il tapé sur une ligne ce qui doit se faire en deux il a conservé tel quels les "<>" qui n'étaient qu'une convention d'écriture pour montrer ce qu'il fallait remplacer Donc il faut écrire textuellement: cd /volume2/PLEX-2/ wget -m --cut-dirs=1 -nH"ftp://mafreebox.freebox.fr/Freebox/Download/" "--ftp-user=<freebox>" "--ftp-password=<monmotdepasse>"  En bien entendu substituant <freebox> et <monmotdepasse> par les valeurs adéquates (sans les "<>"!!!) Mais bon, on doit pouvoir faire bien plus simple (un simple cp) maintenant que FileStation est capable de maintenir un montage permanent du partage de la FreeBox. **EDIT#2** J'ai testé sur ma Freebox Mini (c'est forcément identique sur V6). dans l'option "partage windows" de la Freebox, suffit d'activer le partage de fichiers. Ensuite dans Filestation on déclare un montage permanent: Et le répertoire de la freebox est directement accessible dans un script shell. Plus besoin de passer par un wget et du ftp: [root@fserv_~]$ df | grep free \\192.168.1.254\D2 38325228 10468992 27856236 28% /volume2/var/freebox/D2 Et pas besoin d'être root non plus. (

Tu réponds a un très vieux fil déjà (janvier 2014). Sur les version récentes de DSM, wget est désormais dans "/usr/bin" et plus dans "/usr/syno/bin/" Cela dit je ne m'explique pas l'erreur que tu rencontres, ce que tu aurais du recevoir en utilisant l'ancien chemin est celle ci: $ /usr/syno/bin/wget -ash: /usr/syno/bin/wget: No such file or directory et pas "Permission denied". wget n''est pas réservé à root, mais il faut bien entendu que le répertoire cible ("/volume2/PLEX-2" ici) soit accessible en écriture au compte utilisé.