CoolRaoul

J'ai un DS213j et je n'ai pas de probleme pour enregistrer les video, même en HD Et même je n'avais aucun probleme non plus avec mon DS210j précédent (je n'avais pas testé la HD sur celui-la par contre) Si le stick sait lire les chaines HD c'est oui Oui, avec le paquet video station Sous réserve d'avoir installé les bon codecs oui Le container est en .ts. Pour les formats j'ai analysé avec mediainfo deux enregistrements, un HD et un SD Le détail est ici: https://app.box.com/s/331gyxlg4snv0qthv9fd Oui pour la box, pour le WD je suppose aussi que c'est oui mais mieux attendre un propriétaire de cet appareil pour confirmation. Le seul problème que je rencontre est que les flux videotext (ceux qui contiennent les sous titres) ne sont pas enregistrés. Je ne suis pas parvenu a savoir si c'est un probleme de videostation ou de mon stick. J'ai posté à ce sujet dans le forum () mais le sujet n'a pas déchaîné l'enthousiasme des foules. A ce propos je découvre dans le résultat de mediainfo que les pistes de sous-titres sont bien présentes mais au format "DVB Subtitle" et pas videotext Va falloir creuser ça.

On peut rajouter pour la lecture de fichiers media (audio et video) toutes les applications compatible DLNA, comme par exemple et de façon non exaustive: BubbleUPNP, Archos Video Player, souvent aussi les lecteurs intégrés dans les surcouches constructeurs, et il doit y en avoir d'autre. Attention: DLNA est limité au réseau local (wifi donc).

Sur des postes windows me semble avoir constaté que "ping" n'utilisait pas la même résolution que d'autres commandes et que parfois ça ne marchait pas, à moins d'ajouter un "." final au nom de domaine. Vérifier (avec et sans le point): ping <host>.<domaine> ping <host>.<domaine>. nslookup <host>.<domaine> nslookup <host>.<domaine>. A priori, ajouter le "." final systématiquement semble être une solution, mais j'ai jamais eu le temps de bien cerner le truc et toutes les implications.

Ce que l'on met dans la config DHCP est celle qui est fournie au clients DHCP pour auto-configurer le serveur DNS qu'ils vont utiliser. Je suppose que tu parle de la liste d'ip entourée ci dessous: Pour que les clients DHCP se configurent pour utiliser le Syno comme relai DNS, il faut mettre l'IP du SYNO dans "DNS principal". On peux mettre un serveur de backup en secondaire (celui de son FAI) qui sera utilisé si le Syno est inaccessible provisoirement. De façon générale si on veut qu'un poste client utilise le service dnsmasq comme relai/cache DNS c'est sur le client qu'il faut configurer l'ip du Syno comme adresse de serveur DNS, ( à faire manuellement si on ne s'appuie pas sur l'auto configuration DHCP) et c'est sur le poste client qu'il faut faire les tests (ping ou autre). Le Syno, lui, continue à se référer au DNS externe.

Il y a déjà un fil sur le même sujet:

Pour comparer les caractéristiques de ces 3 modèles: http://www.synology.com/products/compare_spec.php?lang=fre&compare_list%5B%5D=DS213%2B&compare_list%5B%5D=DS213&compare_list%5B%5D=DS213j#compare_show_top

Tu veux dire qu’après la manip le process "synorcd" est *toujours* actif? J'ai du mal a comprendre comment c'est possible. Essaie de rebooter le NAS alors.

Voici l'étape que tu as loupée (il est vrai qu'on a oublié de l'indiquer explicitement): après avoir édité le fichier S96synorcd.sh faut arréter puis relancer le paquet Audiostation. Éventuellement en ligne de commande comme cela: /var/packages/AudioStation/target/scripts/S96synorcd.sh stop /var/packages/AudioStation/target/scripts/S96synorcd.sh start

En fait je n'ai pas plus d'info sur le fonctionnement de cette commande que l'aide en ligne que j'ai copié Faut expérimenter (me demande bien ce que font les arguments "--get" par exemple) Que le premier qui trouve de la doc la dessus poste ici, ça serait sympa.

Bien entendu, on ne propose pas de *tout* synchroniser. Quel que soit l'outil de synchro utilisé on peut choisir de ne synchroniser que certains dossiers bien identifiés.

Juste un truc: si l'idée est d'avoir une synchro de certains dossiers entre les deux NAS, peut être que la fonctionnalité "syncho de dossier partagé" de DSM est à envisager aussi. Je n'ai pas pratiqué le bidule, juste regardé l'aide en ligne. Cependant, au delà de 2 NAS à synchroniser j'ai l'impression que c'est moins trivial Voici ce que dit l'aide: "Synchro du dossier partagé est un service réseau qui permet aux utilisateurs de synchroniser des dossiers partagés entre DiskStations. À partir de DSM 4.1, Synchro du dossier partagé fournit la fonctionnalité Synchro du dossier partagé à source multiple, qui permet à plusieurs clients de synchroniser leurs dossiers partagés vers un DiskStation." A tester.

Étrange alors qu'apache n'ait pas redémarré lors du premier reboot après la mise à jour. Bon, le principal étant que maintenant ça marche.

Vérifie que le service web est bien activé alors, sinon au prochain reboot tu risque d'avoir le même gag:

En complément, sous DSM, les commandes à utiliser pour cela sont respectivement "synouser -add" et "synogroup -add" (dans /usr/syno/sbin/, à mettre dans le PATH sinon donner le chemin complet): fserv> synouser Copyright (c) 2003-2012 Synology Inc. All rights reserved. Usage: synouser (Version 3776) --help --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})} --enum {local|domain|ldap|all|domain_used} --enumpre {local|domain|all|domain_used} prefix Caseless{0|1} --enumsub {local|domain|all|domain_used} substr Caseless{0|1} --get username --getuid UID --add [username pwd "full name" expired{0|1} mail privilege] --modify username "full name" expired{0|1} mail --rename old_username new_username --setpw username newpasswd --del username1 username2 ... --login username pwd --dbopen2 username --filesetpw filename --create_homes {domain|ldap} fserv> synogroup Copyright (c) 2003-2012 Synology Inc. All rights reserved. Usage: synogroup (Version 3776) --help --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})} --enum [{local|domain|ldap|all}] --enumpre {local|domain|all} prefix Caseless{0|1} --enumsub {local|domain|all} substr Caseless{0|1} --get groupname --getgid GID --descget groupname --descset groupname ["New Descritions"] --add groupname username1 username2 ... --rename old_groupname new_groupname --member groupname username1 username2 ... --del groupname1 groupname2 ... --dbopen2 groupname

La mise a jour DSM entraine un *reboot* du NAS. Donc je ne vois pas comment il a été possible que apache ne se relance pas!

Oui, enfin de la à parler de "trou béant" . D'autant plus que si les postes clients ne sont pas des antiquités, ce sont les methodes d'authentification les plus solides qui vont être négociées entres eux et le serveur samba de DSM. Ensuite, tous les protocoles de ce genre (voir NFS par exemple) ont des vulnérabilités qui sont corrigées en général assez rapidement Si il ne fallait utiliser que ceux n'ayant jamais eu de faille ne resterait plus que la remise via support externe de la main à la main. Par contre, je reconnais bien volontiers que CIFS n'est pas forcément le plus adapté aux acces de type WAN (NFS pas trop non plus d'ailleurs). Webdav me semble plus approprié et serait d'ailleurs possible en compilant et installant le module "davs" (ça a été abordé dans le forum) permettant faire un montage distant, mais AMHA ça reste de l'ordre du bricolage (d'autant plus que les informations d'authentifications sont fournies lors du mount et donc sont commune à tous les utilisateurs) Maintenant la question est, est-il vraiment utile que les Synos se voient entre eux? Si chaque poste client a directement accès aux différents NAS (en utilisant webdav pour les serveur distants) qu'apporte de plus l'acces inter NAS via filestation?

KeyPassX necessite mono, tres probablement X11. Avant de porter tout ça sous DSM c'est pas gagné à mon avis (d'autant plus qu'une appli X11 sur un syno j'ai du mal a en imaginer une utilisation triviale) En plus, je suppose que c'est un outil avec une interface web qu'il recherche, donc la voie php me semble plus appropriée.

Peut-être ceci (pas testé): http://sourceforge.net/projects/ppma/

Non: quasiment aucun détail n'étant donné, impossible de faire le moindre diagnostic. Faudrait au minimum la sortie de la commande: /usr/syno/etc/rc.d/S97apache-user.sh restart

Tiens je n'étais pas au courant Tu pourrais nous communiquer des sources détaillées de l'info stp?

C'est par ici: http://www.topachat.com/pages/detail2_cat_est_reseau_puis_rubrique_est_w_nas_puis_ref_est_in10063497.html

C'est possible mais pas en shell, Un petit script perl ferait l'affaire Avec par exemple la commande "utime" (http://perldoc.perl.org/functions/utime.html)

Ah, en effet, il semble que le "touch" de busybox ne soit pas toujours compilé avec l'option -d implémentée: https://forum.openwrt.org/viewtopic.php?id=36502 Va falloir trouver une solution alternative

Peux-tu nous dire ce que donne: stp?

DSM est basé sur busybox, est c'est donc le "touch" de busybox qui est dispo: fserv> touch --help BusyBox v1.16.1 (2013-08-17 02:36:47 CST) multi-call binary. Usage: touch [-c] [-d DATE] FILE [FILE]... Update the last-modified date on the given FILE Options: -c Don't create files -d DT Date/time to use Et les formats de date acceptés sont détaillés ici: http://lists.busybox.net/pipermail/busybox/2011-January/074368.html