Pourquoi ne pas mettre les pistes sur un NAS?
Parce que, entre autres, les mises à jour automatiques de la bibliothèque Jriver demandent que le système de l'ordinateur où est installé Jriver puisse surveiller en permanence le file system de l'ordinateur où sont les pistes.
Cela demande des softs spécifiques (comme quand on synchronize en permanence une Dropbox), et ce n'est pas prévu dans Jriver.
Une première indexations à distance avec pas loin d'un dizaine de de milliers d'albums prend un temps fou.
Quant à l'analyse audio des pistes à distance, cela prend déjà une bon bout de temps avec les pistes en local, cela prend un temps infini avec les pistes à distance.
Parce que la gapless, même bien programmé en UPNP avec identification de la piste suivante, n'est pas compatible avec la latence d'un NAS + réseau dès que les pistes sont brèves.
Parce qu'il faut un Switch de compétition entre le NAS, le lecteur réseau et le serveur Jriver pour ne pas avoir de coupures dès que l'on dépasse le 16/44.
Parce que dès que qqun d'autre utilise le NAS, on a des coupures.
Parce que transcoder les Flac en Wave ou les DSD en PCM n'est pas compatible avec la latence NAS + réseau et que l'on a des coupures.
J'ai 3 NAS, ils me servent de sauvegardes.
Maintenant, chacun son approche informatique. Mais je ne compte plus le nombre de systèmes que j'ai dépannés qui "coupent" juste parce que les pistes ne sont pas locales.
Est-ce qu'il viendrait à l'idée de qqun de mettre les fichiers utilisés par les serveurs d'un NAS sur un autre NAS?
PS: si les dossiers du NAS sont montés en NFS, je ne sais pas si la bibliothèque peut être mise à jour... En tout cas, entre file system OSX et file system NAS Synology, cela ,ne le fait pas.
Parce que, entre autres, les mises à jour automatiques de la bibliothèque Jriver demandent que le système de l'ordinateur où est installé Jriver puisse surveiller en permanence le file system de l'ordinateur où sont les pistes.
Cela demande des softs spécifiques (comme quand on synchronize en permanence une Dropbox), et ce n'est pas prévu dans Jriver.
Une première indexations à distance avec pas loin d'un dizaine de de milliers d'albums prend un temps fou.
Quant à l'analyse audio des pistes à distance, cela prend déjà une bon bout de temps avec les pistes en local, cela prend un temps infini avec les pistes à distance.
Parce que la gapless, même bien programmé en UPNP avec identification de la piste suivante, n'est pas compatible avec la latence d'un NAS + réseau dès que les pistes sont brèves.
Parce qu'il faut un Switch de compétition entre le NAS, le lecteur réseau et le serveur Jriver pour ne pas avoir de coupures dès que l'on dépasse le 16/44.
Parce que dès que qqun d'autre utilise le NAS, on a des coupures.
Parce que transcoder les Flac en Wave ou les DSD en PCM n'est pas compatible avec la latence NAS + réseau et que l'on a des coupures.
J'ai 3 NAS, ils me servent de sauvegardes.
Maintenant, chacun son approche informatique. Mais je ne compte plus le nombre de systèmes que j'ai dépannés qui "coupent" juste parce que les pistes ne sont pas locales.
Est-ce qu'il viendrait à l'idée de qqun de mettre les fichiers utilisés par les serveurs d'un NAS sur un autre NAS?
PS: si les dossiers du NAS sont montés en NFS, je ne sais pas si la bibliothèque peut être mise à jour... En tout cas, entre file system OSX et file system NAS Synology, cela ,ne le fait pas.