Nvidia Shield Android TV 2015/2017

» 13 Juil 2016 10:06

Salut la compagnie,

Je debarque mais concernant le debat entre NFS et SMB, chacun de ces protocoles dispose d'avantages et d'inconvenients, SMB est plus universelle même si légerement moins rapide, NFS est plus veloce mais reste cantoné aux systemes UNIX dont Linux ....
NFS est parfait pour Kodi/SMPC mais SMB est utilisé par Windows, KOdi/SMPC, Plexmediaserver (version shield), Archos video....
Personnellement je trouve que la configuration NFS est plus simple que SMB notamment depuis la 4.4 qui ne permet plus l'authentification "SHARE" mais ça fonctionne parfaitement ...

» 13 Juil 2016 11:21

Non arkim c'est pas un débat et justement on l'a précisé, pas de NFS vs SMB.
Ils n'ont plus rien à prouver !

Juste une petite précision que j'ai dit dans mes derniers com, c'est à chacun d'y trouver son bonheur et pour mon cas c'est:
SMB => serveur sous Windows @110 mo/s constant, rapide, aucun plantage (ma config perso, donc avis personnel).

Si un protocole déconne on teste l'autre c'est tout, maintenant c'est normalement bien géré depuis le temps !

Bienvenu et au plaisir @+ :wink:

» 13 Juil 2016 11:23

@Poilut66
Oui j'avais suivi les instructions de costaud, afin d'appliquer correctement les conseils de configuration de Koying concernant SPMC,
et en effet la qualité d'image s'en est améliorée avec l'ajout du fichier advancesettings.xml (donc pas trop envie de l'enlever pour essayer).
Là c'est un souci (inconstant) de fluidité que j’essaie d'améliorer.
Je dis "inconstant" car sur les différentes films testés, j'ai quant même l'impression que la majorité passent bien, et que le souci n'apparait
que sur quelques titres (le rip m2ts sans compression du BR Monstres Academy par exp).

Ayant testé je pense toutes les combinaisons de configuration possibles entre TV et Shield, je suis revenu à celle de base conseillée qui
finalement fonctionne bien, dans le sens où au moins, je suis pratiquement certain qu'elle n'accentue pas le souci (quand il est présent) :
4K60 - plage dynamique Auto - 4:2:0

(Avec les autres résolutions/framerates j'ai toujours un petit doute en fait. C'est pas facile à expliquer mais chaque fois que je l'ai ai testé,
j'ai eu l'impression sans que ce soit forcément très franc, que c'était un peu moins bien).

BrokenPanda a écrit:T'as plus besoin de te poser ce genre de question si tu montes ton NAS sur la Shield

Désolé mais pour le coup, je ne suis pas assez expert en réseau pour comprendre cette suggestion :oops:

Je ne sais ni ce que veux dire "monter le NAS sur la Shield" (et donc les avantages que ça peut présenter), ni comment le faire...

psygno a écrit:Franchement je vote sans aucun doute pour le NFS qui est la norme réseau natif de Linux, Android étant du Linux, le choix est vite fait !!!
Pour ceux qui ont un NAS de chez Synology suffit de suivre ce superbe tuto qui est très bien expliqué
http://kodi.wiki/view/NFS#Synology_DSM_5.1

C'est en effet grâce au contenu de ce lien que j'ai pu faire en sorte que le NFS soit accessible et fonctionnel sur la Shield.
Mais, comme dit à Poilut66, l'essai n'ayant pas amélioré le petit problèmes de fluidité que je rencontre, j'en ai conclu que ça n'était pas lié
à une question de débit et donc à la performance du protocole réseau choisit.

Ceci étant, vue que je peux donc prendre indifféremment l'un ou l'autre, j'aurais bien migré vers NFS, MAIS ayant mon scrap déjà effectué
en SMB sur quelques 2000 titres, avec les fiches toutes éditées à la main une par une, je n'ai pas trouvé comment changer le chemin réseau (SMB --> NFS)
de l'ensemble de mes fichiers sans que ça me relance un scan complet... et donc que ça me foute en l'air toutes mes modifs de fiches.

J'ai essayé d'éditer la source vidéo, en changeant simplement le chemin d'accès réseau, pour voir si ça allait être automatiquement appliqué
aux fiches de la médiathèque déjà créées, mais apparemment non. Au moment de valider en cliquant sur OK ça me propose de relancer
le scan. Et si je choisi "Non", c'est comme si je n'avais jamais scraper mes films, je vois les nom des fichiers, mais pas leur fiches.
Et si je vais sur mes fiches dans la mediathèque (créées via SMB) et que je clique sur un film, il ne le lance pas car il ne trouve plus le
chemin réseau (forcément vu que je suis passé sous NFS :hehe:

).

Donc si quelqu'un sait comment faire, je suis preneur bien sure ?!!

costaud a écrit:Es-tu en 4:4:4 ?

Non, comme expliqué plus haut à Poilut66, je suis revenu en 4K60 - Plage dynamique auto - 4:2:0
Mais passer en 4:4:4 a fait parti des config testées, et je n'ai constaté (sur la question de fluidité et de mes micros saccades/décrochages inconstants)
aucune amélioration particulière.

EN CONCLUSION, sur la base de mes nombreux essais, de vos réponses, et afin que vous ne nous preniez pas la tête inutilement, je ne suis pas
loin de penser que ce que j'observe est plus lié à un encodage de certains fichiers (qui rendrait la partie hardware plus chatouilleuse et ferait donc
apparaitre par moment ce souci de fluidité) plutôt qu'à un problème de matériel ou de mauvais réglages.

Par contre, si quelqu'un à la solution pour la migration vers NFS sans avoir à rescanner ma mediathèque (donc pour que ça modifie automatiquement
le chemin d'accès des fiches déjà existante), je veux bien ! :roll:

» 13 Juil 2016 11:25

Comment peut on lire dans l'état de la shield en 4:4:4 constant (10bits) ? cela ne fonctionne pas avec SPMC.

Merci

» 13 Juil 2016 11:36

kilicool a écrit:Comment peut on lire dans l'état de la shield en 4:4:4 constant (10bits) ? cela ne fonctionne pas avec SPMC.

Merci

C'est un problème d'API qui à changé et que les logiciels comme SPMC ne vont pas chercher du coup, il faut attendre que Nvidia patch ça, car ils ont créé un nouvel API pour la gestion du 23.976 mais si personne ne sait comment l'utiliser, ben ça va par servir à grand chose :ane:

Donc actuellement en 4:4:4 l'autoframe n'est pas fonctionnel et sous SPMC ça reste en RGB. (ça c'est peut être à koying de voir ce qui peut être fait ??? )

» 13 Juil 2016 11:55

Arkhnaten a écrit:Par contre, si quelqu'un à la solution pour la migration vers NFS sans avoir à rescanner ma mediathèque (donc pour que ça modifie automatiquement
le chemin d'accès des fiches déjà existante), je veux bien !

Tu passeras par un rescan sans que ce soit un soucis: L'idée, c'est que tu fasses d'abord un export de tes fiches, ce qui fera une fiche xml .nfo a coté de chaque films/série. C'est d'ailleurs pas une mauvaise idée de le faire pour backup... mais aussi ou pour éditer différemment que dans KODI (changement de masse, films non connu, ...)

Ensuite, tu rescan la bibliothèque, et comme il prendra en priorité l'info du NFO... tu récupères tes info. Tu pourras même tester avant de rescanner dans la shield en faisant un scan des fichiers via un KODI sur un PC.

Voici 2 liens utiles:
http://kodi.wiki/view/Import-export_library
http://kodi.wiki/view/HOW-TO:Backup_the_video_library

et meme une petite video
https://www.youtube.com/watch?v=ThdD6LQ4vsI

» 13 Juil 2016 12:00

Arkhnaten a écrit:
1) Je dis "inconstant" car sur les différentes films testés, j'ai quant même l'impression que la majorité passent bien, et que le souci n'apparait
que sur quelques titres (le rip m2ts sans compression du BR Monstres Academy par exp).

2) J'ai essayé d'éditer la source vidéo, en changeant simplement le chemin d'accès réseau, pour voir si ça allait être automatiquement appliqué
aux fiches de la médiathèque déjà créées, mais apparemment non. Au moment de valider en cliquant sur OK ça me propose de relancer
le scan. Et si je choisi "Non", c'est comme si je n'avais jamais scraper mes films, je vois les nom des fichiers, mais pas leur fiches.
Et si je vais sur mes fiches dans la mediathèque (créées via SMB) et que je clique sur un film, il ne le lance pas car il ne trouve plus le
chemin réseau (forcément vu que je suis passé sous NFS ).

Donc si quelqu'un sait comment faire, je suis preneur bien sure ?!!

3) EN CONCLUSION, sur la base de mes nombreux essais, de vos réponses, et afin que vous ne nous preniez pas la tête inutilement, je ne suis pas loin de penser que ce que j'observe est plus lié à un encodage de certains fichiers (qui rendrait la partie hardware plus chatouilleuse et ferait donc apparaitre par moment ce souci de fluidité) plutôt qu'à un problème de matériel ou de mauvais réglages.

4) Par contre, si quelqu'un à la solution pour la migration vers NFS sans avoir à rescanner ma mediathèque (donc pour que ça modifie automatiquement le chemin d'accès des fiches déjà existante), je veux bien !

1) Le M2ts fait généralement chier la plupart des lecteurs (et nous aussi par la même occasion) et ne contient pas forcément les bonnes instructions de la vidéo pour une bonne la lecture sous des logiciels vidéo, donc un petit conseil:
Tu prends ton fichier M2ts et tu le balances dans MKVToolNix, puis lancer le Multiplexge (au passage si des pistes audio te font chier, tu décoches), très important, ta vidéo ne sera pas réencodée, elle changera juste de container, du .m2ts => .mkv (plus souple).
Fais déjà un test sur un fichier et tu lances la lecture.

2) C'est normalement la procédure me semble, cela dit le cache de SPMC qui contient les images, pochettes etc. contient dans son fichier tous les chemins, donc les anciens (SMB), idem pour la BD vidéo certainement, c'est pourquoi il veut scrapper.

3) c'est bien de ce prendre la tête :ane:

4) pour le moment reste en SMB et teste le 1

@+

» 13 Juil 2016 13:31

@Johannol

Super info et donc bonne nouvelle, merci !. Je ferai l'essai sur un fichier isolé pour vérifier, et si c'est bon et aussi simple que ça, je passerai surement le tout en NFS.

@Poilut66

C'est vrai que je me suis jamais vraiment posé la question du conteneur.
En fait comme les fichiers sont en m2ts en natif sur les BR, ça me semblait logique de conserver le fichier tel que pour ma mediabox...
Mais si tu me dis que le m2ts pose plus de problème aux box que le mkv, je vais tester sur un ou deux fichier pour voir.

Le truc qui me fait peur c'est que si ça améliore les choses, ça va me prendre trois plombes de ré-encapsuler tout mes m2ts (j'en ai 182, de 25 Go en moyenne chacun)

» 13 Juil 2016 13:54

Fais un test avec vlc en play, pause, avance rapide sur un m2ts et une fois convertis en .mkv, tu verras la différence.
Çà merdouille souvent (par expérience) après ce n'est pas forcément ton soucis, mais je testerais...

» 13 Juil 2016 14:36

Arkhnaten a écrit:@Johannol

Super info et donc bonne nouvelle, merci !. Je ferai l'essai sur un fichier isolé pour vérifier, et si c'est bon et aussi simple que ça, je passerai surement le tout en NFS.

@Poilut66

C'est vrai que je me suis jamais vraiment posé la question du conteneur.
En fait comme les fichiers sont en m2ts en natif sur les BR, ça me semblait logique de conserver le fichier tel que pour ma mediabox...
Mais si tu me dis que le m2ts pose plus de problème aux box que le mkv, je vais tester sur un ou deux fichier pour voir.

Le truc qui me fait peur c'est que si ça améliore les choses, ça va me prendre trois plombes de ré-encapsuler tout mes m2ts (j'en ai 182, de 25 Go en moyenne chacun)

Comme t'as dit poilut66, fais un test avec un film qui te pose problème, dans mon cas j'ai autant de m2ts que toi et aucun soucis de ce genre

» 13 Juil 2016 15:19

Poilut66 a écrit:Fais un test avec vlc en play, pause, avance rapide sur un m2ts et une fois convertis en .mkv, tu verras la différence.
Çà merdouille souvent (par expérience) après ce n'est pas forcément ton soucis, mais je testerais...

Je pense qu'il est logique qu'un m2ts de 30 ou 40 go soit plus difficile à lire qu'un mkv (x264) de 8 - 10go.
Sauf erreur de ma part, le mkv est destructif ? Ca reviendrait à comparer du raw et du jpg en photo.

Quand je peux, je conserve mes films en m2ts et je n'ai jamais eu de problème de lecture (avec rpi2 ou rpi3). Par contre sur PC, il est vrai que VLC n'a pas les mêmes facilités de lecture, avance rapide etc... En m2ts parfois l'image fait des pavés.

» 13 Juil 2016 15:34

Alors non en fait, mkv n'est qu'un conteneur, et il est destructif uniquement si tu appliques un réencodage avec une compression
plus ou moins importante.
Mais tu peux tout à fait ré-encapsuler un m2ts en mkv sans le retoucher, auquel cas tu auras un fichier du même poids, avec
aucune modification des données.

» 13 Juil 2016 16:18

Arkhnaten a écrit:Alors non en fait, mkv n'est qu'un conteneur, et il es destructif uniquement si tu appliques un réencodage avec une compression
plus ou moins importante.
Mais tu peux tout à fait ré-encapsuler un m2ts en mkv sans le retoucher, auquel cas tu auras un fichier du même poids, avec
aucune modification des données.

Exactement

» 13 Juil 2016 19:43

Jacques56 a écrit:
Poilut66 a écrit:Fais un test avec vlc en play, pause, avance rapide sur un m2ts et une fois convertis en .mkv, tu verras la différence.
Çà merdouille souvent (par expérience) après ce n'est pas forcément ton soucis, mais je testerais...

Je pense qu'il est logique qu'un m2ts de 30 ou 40 go soit plus difficile à lire qu'un mkv (x264) de 8 - 10go.
Sauf erreur de ma part, le mkv est destructif ? Ca reviendrait à comparer du raw et du jpg en photo.

Quand je peux, je conserve mes films en m2ts et je n'ai jamais eu de problème de lecture (avec rpi2 ou rpi3). Par contre sur PC, il est vrai que VLC n'a pas les mêmes facilités de lecture, avance rapide etc... En m2ts parfois l'image fait des pavés.

Comme te l'ont dit Arkhnaten et Costaud si tu muxes sous "MKVtoolnix" par exemple c'est du 1:1, zéro perte, rien à voir avec un quelconque encodage.

Arkhnaten a écrit:

Pour le coup, ils n'ont pas de souci avec du M2ts ça devrait être pareil pour toi, donc çà ne devrait rien changer :-?

» 13 Juil 2016 21:01

Le changement de container est à tester tout de même. Assez souvent sur PC il faut passer un m2ts en ts ou inversément, en fonction du soft de lecture

.
On utlise tsmuxer pour cela, le principe étant le même qu'avec mkvtoolnix pour les MKV (simple changement de conteneur sans changer l'intérieur).