CoolRaoul

Je n'ai pas eu l'occasion de faire les ouvertures de ports d'un routeur directement par DSM via la "configuration du routeur" (ma box n'est pas supportée) mais on peut penser, d’après la liste ci-dessus, que les ports requis (137,138,139,445) sont bien redirigés Faut juste espérer qu'ils ne sont pas ouverts sans restriction à tout l'internet sinon bonjour les tentatives d'intrusions (mais c'est un autre sujet). Serait utile de faire le test avec un autre PC pour distinguer si le problème est coté PC, ou coté NAS+Réseau (Je dis ça après être suis tombé sur avec la même erreur ou c'est la réinstallation du PC qui à résolu le problème)

Rien d'étonnant la dedans: la détection des mises à jour sur les NAS Syno s'appuie sur un tache crontab ("/usr/syno/sbin/synoupgrade --fetch-all") programmée pour s'éxécuter 2 fois par semaine. Le jour et l'heure sont générés de façon pseudo-aléatoire afin d'être différents sur chaque appareil. Cela à pour effet d'automatiquement "lisser" la charge sur les serveurs de téléchargement sur une période de quelques jours. C'est évidemment moins sophistiqué qu'une infrastructure de diffusion basée sur des services de type Akamai mais c'est déjà mieux qui si tous les syno du monde, prévenus au même instant de la mise à disposition d'un un upgrade, se retrouvaient instantanément susceptibles de tenter un téléchargement dans les minutes qui suivent avec l'écroulement probable des serveurs de mise à jour.

Le serveur multimedia est un package à installer séparément (via le centre de packages). Ensuite on y accède via le menu principal.

C'est donc bien ce que je pensais, et je confirme que c'est franchement pas habituel d'utiliser ce genre de connexion via internet: tu auras du mal a trouver d'autre personnes avec la même config pouvant reproduire le problème à l'identique. Il serait plus judicieux d'envisager l'option "webdav" (même si c'est parfois un peu "touchy" à régler sous Windows), à voir plus tard éventuellement dans un autre fil Oui mais ici il s'agit d'une connexion réseau CIFS, les ports à rediriger sont 139 et 445 (cf ici) Et faut espérer que ton collègue à configuré le firewall du syno pour ne laisser passer que ton IP sur ces ports la (sous condition que tu ais une IP Fixe): quand qu'il sont ouverts ils sont très souvent attaqués.

Il s'agit d'une connexion de lecteur réseau Windows à distance par internet c'est bien ça? En général, à distance, soit on utilise webdav , soit un établit un VPN entre les deux NAS. Mais puisque il est question explicitement de "lecteur réseau" on peut deviner qu'il s'agit de CIFS (j'insiste: quasiment jamais utilisé à distance mais ça reste normalement techniquement possible) Quels sont les ports redirigés vers le NAS dans la box du collègue?

Il y a déjà ça:

Le partage "Photo" est spécial au niveau des droits. "It's by design" J'ai déjà posté de multiple messages sur le sujet pour expliquer, on doit pouvoir les retrouver sans trop de difficultés En résumé et pour ceux qui ont la flemme de chercher: soit on choisit de gèrer ses photos *exclusivement* par PhotoStation (qui a sa propre gestion des droits intégrée) sans passer par filetsation, les partages windows, ftp and co (donc en bloquant les acces non administrateurs au partage "photo"), soit on se passe de Photostation et on stocke ses photos dans un dossier partagé générique qui n'aura pas les limitations constatées. **edit** Déja évoqué aujourd'hui même:

Explication: PhotoStation est une application web qui accède aux fichiers du partage "photo" par l'intermédiaire du compte "http" (sous lequel tourne le serveur apache) Si il avait été laissé la possibilité de modifier librement (via filestation) les droits effectifs des fichiers et dossiers contenus dans le partage "photo" il pourrait arriver la situation ou PhotoStation lui-même n'a plus la possibilité d'écrire et/ou de lire certains de ces fichiers ce qui s'avérerait problématique pour son fonctionnement

Qu'en sais-tu vu que pour le moment, on ne nous a toujours pas dit de quel modèle il s'agit ? (Mon Sony W9 lit les .avi) **edit** Quelqu'un qui fait face à un probleme similaire: Ca semble plus lié a un bug de DSM5 qu'au fait que la télé soit une Sony Ne pas négliger l'option de bidouiller les parametres DLNA du serveur multimedia en suivant le lien que j'ai donné un peu plus haut, on ne sait jamais.

Je me demande d'ou peut venir cette information. Voici la liste des formats (codecs et containers) supportés par les modèles Sony récents (2013 et +) qui m'avait été communiquée par le support Sony, ça ne donne pas cette impression: http://pdf.crse.com/manuals/13HG900111/FR/codeclist.html#5 Moi-même possesseur d'un téléviseur de cette gamme je peux d'ailleurs confirmer que les formats supportés sont très variés. Pour répondre à la question initiale serait intéressant de vérifier si l'indexation est bien terminée. Ah moins que tous les fichiers video dans exception soit d'un format particulièrement exotique. Regarder aussi ce fil: (bien qu'il puisse être un peu dépassé)

Si ça ne l'était pas quelqu'un l'aurait très certainement déjà fait. Moi je ne saurais pas t'aider en tout cas: je ne connais même pas Asterisk, c'est dire

L’agrégation de liens (sujet récurrent dans le forum) n'a de sens que dans un contexte "pro" avec de nombreux équipements clients connectés au NAS et effectuant des transferts intensifs et simultanés. Pour streamer de la video (même en Full HD) sur 3 TV comme ici, c'est inutile. Un flux de streaming de fichier HD est de l'ordre de 10Mbits (facile à calculer: diviser la taille en bytes du mkv par sa durée en secondes et multiplier par 10 donne grosso/modo le débit nécessaire en bits/sec) . Autrement dit, le NAS étant relié à un switch gigabit, il en faudrait un paquet de TVs DLNA connectées dessus avant qu'il soit largué.

Commence par te renseigner pour savoir si quelqu'un a déjà pu intégrer ce moteur TTS sous le DSM du Synology. Si tu ne trouves pas de référence, à mon avis, c'est franchement mal parti. Au passage, l'option chroot Debian impliquerait probablement l'utilisation d'une version Debian de Asterix aussi en lieu et place du package Syno. Pas simple non plus.

La réponse a été donnée ici même dans le forum. Dans l'immédiat, je n'ai pas le lien sous la main mais avec les bon mot clés pas de raison de ne pas trouver. ***edit** Voila trouvé: m'a fallu a peine 5 mn

Il serait peut-être utile de communiquer ici quelle a été la réponse de Synology a ces demandes? D'autre part, si il est confirmé qu'il s'agit bien d'un bug Java ne serait-il pas utile de le signaler également chez Oracle ?

Même si tu parviens à installer optware (ce que décrit le tuto dont du cite le lien) sur le syno tu n'est pas prés d'avoir apt-get qui est une commande des distribs Linux Debian ou basées dessus (comme Ubuntu par exemple) Pour cela faudrait partir sur un chroot debian (voir les posts à ce sujet sur le forum), mais c'est pas un truc franchement trivial pour un newbie.

Oui, enfin, j'ai mis "putty" car je n'avais pas percuté (mea culpa) que tu étais sur Mac, suffit de remplacer par l'outil de connexion ssh que tu utilises. Mais les symptomes que tu as décris correspondent exactement à la séquence: <poste de travail> -> outil ssh natif (quel qu'il soit) connecté sur le compte "admin" du syno -> ssh natif du syno connecté au syno sur le compte root Et pour faire ça c'est simple, une fois connecté au compte "admin" du syno en ssh a partir du Mac, suffit de taper "ssh root@<ip_ou_addresse_du_syno>" (par exemple en se croyant toujours dans le terminal du Mac)

Aussi bien Video Station que DS Video savent en effet générer les srt externes. J'ai juste rebondis sur la proposition d'incorporer les sous-titres dans le flux en suggérant une autre approche, qui a, en plus, l'avantage de pouvoir supporter les sous-titres même dans le cas d'un acces DLNA mais cela ne se voulait pas une réponse au message initial.

J'ai comme l'impression qu'il se connecte sur le syno avec le compte "admin" et, de là, rebondit sur le syno avec le compte root: PC -> putty(admin@syno) -> ssh(root@syno)

Ca ("incorporer les sous-titres dans le flux") implique un transcodage à la volée ce qui est une opération *très* gourmande en CPU. PLEX le fait mais ne supporte pas tous les modèles Syno (entre autre pour ce problème de puissance requise) La meilleure solution est d'opter les formats de containers vidéo supportant les flux de sous-titres intégrés (tels que mkv). Pour la conversion ( video + srt ) vers mkv, mkvtoolnix est l'outil idéal (et rapide puisqu'il n'y a pas de transcodage dans ce cas)

Pourquoi, ça marchait pas sans ça?

J'imagine que tu as d'abord posé ta question à la source ? Si la-bas personne n'a pu te proposer de solution, j'ai bien peur qu'il y ait peu d'espoir ici. Bonne chance quand même.

Normalement le "net use" ne devrait pas être obligatoire: devrait être suffisant, dans la boite de dialogue "connecter un disque réseau", de cocher la case "se reconnecter à l'ouverture de session". Sinon, a partir du moment ou les mots de passes syno et windows sont les mêmes, il est encore plus simple à partir des PC d'utiliser la notation dite "UNC" pour accéder aux dossiers syno C'est la forme: DiskStation<nom_de_partage> On peut également sous windows créer des liens (.lnk) dont la cible est un chemin utilisant cette syntaxe.

Il est facile de comprendre qu'un certificat auto signé, par principe, n'est *forcément* pas approuvé (ça serait comme un carte d'identité fabriquée et délivrée par toi-même, elle non plus ne serait pas considérée comme valide par la police) Ta manip pourrait peut-être marcher (mais s'appliquera uniquement en navigant à partir de ton PC) , en choisissant un magasin contenant des certificats racine. au lieu de laisser la sélection automatique sélectionner du magasin. Mais tous les autres navigateurs auront le warning. Cela dit, si ça marche la seule chose que tu gagnera, sera de ne plus avoir l'avertissement de sécurité dans ton navigateur, comme ci dessous: Mais le flux sera quand même crypté SSL au final. Et ce n'est que ça qui tintéresse à priori. Donc est-ce si important?