CoolRaoul

Finalement Damien

Non, tu prend le fichier dont je donne le lien comme départ et tu y ajoute les lignes "defname" correspondant aux chaines que tu as ajouté dans ton channel.con Je ne vois pas vraiment comment je peux être plus détaillé que dans mes explications du premier post Et attention a utiliser un éditeur supportant l'UTF8 (meme notepad de windows sait faire mais mieux vaut utiliser notepad++) A propos, de quelle "mise à jour" parles-tu ?

http://fr.wikipedia.org/wiki/XMLTV Non: VideoStation va récupérer l'EPG dans le flux TNT mais on n'a pas la maîtrise de la fréquence de cette opération. En outre l'EPG intégré au flux TNT est (du moins en France) assez limité (2 ou 3 jours d'avance il me semble). D'ou l’intérêt de mon script. Non plus, et tout le monde se plaint de ce défaut (ainsi que de l'impossibilité de pouvoir modifier les enregistrements programmés). Je pense que Synology intégrera ces fonction dans une future version (fait prendre en compte du fait que que VideoStation est un composant relativement jeune )

Eviter OpenPhoto sur un NAS entrée et milieu de gamme, c'est un gouffre en perfs! (testé et désapprouvé pour ma part)

Attention: je ne propose rien du tout, je me contente d'essayer expliquer comment DSM gère les droits de façon différentes, sur le dossier partage d'une part, et pour pour les accès via PhotoStation de l'autre. Il faut aussi savoir que PhotoStation nécessite que le compte unix utilisé par apache "nobody" (ou le groupe eponyme) ait accès complet (rwx donc, au sens droits unix) aux dossier "photos" et, pour encore compliquer les choses, que DSM ne permet pas d'utiliser les ACL sur ce partage. (Personnellement, je n'utilise pas PhotoStation, je m'y suis juste un peu intéressé pour répondre à des questions sur ce forum).-

Les droits d’accès via l'application photostation en http sont complètement indépendants des droits du partage "photo" (je sais, au premier abord, ça surprend) J'en ai parlé ici: Donc tu peux restreindre les droits du partage "photo" en les mettant aussi restrictifs que tu veux (uniquement "admin" si tu le souhaite) et pourra toujours gérer séparément les acces pour les utilisateurs utilisant photostation.

Ben c'est expliqué dans le (paragraphe "Notes au sujet du fichier "xml2epg.conf")

moi aussi Si on n'utilise pas l'infra SPKSRC jusqu'au bout (génération du spk) faut d'abord rassembler les libraries dépendantes (je suppose dans ../gnutls/work-88f6281/install/, etc ...) et ensuite soit les mettre dans le bon répertoire à l'arrivée soit passer par un LD_LIBRARY_PATH. J'ai eu la flemme... Tant qu'a faire "crade", j'ai utilisé mes petits scripts perso qui, sur mon nas, mettent tout dans /site/(local|bin|lib|etc...) (/site est un "mount -bind" vers un répertoire de /volume1, "à la optware"), je génère un .tar avec des chemins relatifs que j'extrait sur mon syno) et ainsi je mutualise les .so à l'arrivée C'est pas tres industriel (c'est pourquoi je garde mes scripts pour moi) mais ça fonctionne .

A la lecture de ce fil je me pose une question: pourquoi est-t-il si difficile (en tout cas je n'y suis pas parvenu) en partant de la page "produits" du site officiel Synology de savoir quel CPU

Ah non, j'ai pas eu le temps Justepus compiler un wget fonctionnel pour mon archi avec mes propres scripts, mais faire un spk me faudra prendre un peu de temps

Dans ce cas suffit de désactiver/réactiver les fonctions correspondantes dans l'interface DSM et les lignes seront automatiquement régénérées.

et surtout (le cron DSM est tres sensible à ça) attention de séparer les champs par des tabulations et pas par des espaces!

Par principe tous les crontabs sont différents en fonction des sauvegardes programmées, des jobs timebackup, etc

Tu n'as pas de PC ? ***EDIT*** PS: Je dit ca parce que je suis toujours étonné du nombre de gens qui se compliquent la vie a vouloir absolument faire tourner sur de petits NAS des applications qui sont déjà disponible pour leur PC (Windows et/ou Linux) ou Mac et fonctionneront forcément bien plus lentement vu le ratio de puissance et de mémoire entre un PC de base et un NAS entrée ou milieu de gamme.

Tu es au courant qu'il n'y a pas de sortie video sur un syno? Donc quoi que l'on puisse trouver, ça ne peut être *équivalent*

Mon script ne génère rien: il ne fait que *convertir* le détail des programmes contenus dans le fichier xml qu'on lui donne en paramètre (ou celui contenu dans le .zip) dans le format (les fichiers epg.nnn) utilisé par Videostation. Tu peux d'ailleurs consulter le contenu du fichier xml avec n'importe quel éditeur. La liste des chaines est en début de ce dernier. Les programmes dont tu as pu constater la présence ont donc forcément étés générés par Videostation lui-même (plus exactement par l'outil "synodvbepg") à partir du contenu du flux TNT (le script ne supprime pas les fichiers epg déja présents dans le dossier EPG)

Je réalise un truc tout a coup: Tu a écris Il est normal que pour les chaines ajoutées, les programmes restent vident dans VideoStation, si ces chaïnes ne sont pas présentent dans le tnt_lite.zip! Mon script ne peut pas inventer les programmes de chaines qui ne sont pas dans le source xmltv!

Faut quand même bien inclure les librairies dont dépend wget dans le spk non? Sinon j'ai un doute pour que wget fonctionne a l'arrivée Voici ma liste de plist apres le make: work-88f6281/gmp.plist work-88f6281/gnutls.plist work-88f6281/nettle.plist work-88f6281/wget.plist A moins de faire un spk supplémentaire pour chaque librairie (gmp, gnutls, nettle), et les installer tous les 4?

Je vois mais au départ je cherchais un fichier nommé "PLIST" alors que ce sont bien des "*.plist" (plusieurs si il y a des dépendances: wget.plist, gnutls.plist, etc ... ...) qui sont générés On construit donc le "PLIST" final a partir d'eux (en élaguant ce qui n'est pas forcément indispensable comme les docs par exemple)

En effet, j'ai (encore) un peu merdé dans mon explication En fait, comme tu viens de nous dire que tu pouvais accéder a ton site distant en ssh, tu n'as plus besoin d'utiliser wget puisque rsync répond a ton besoin. Et comme rsync est natif sous DSM tu n'as pas besoin d'installer (à fortiori de compiler) quoi que ce soit pour faire ton miroir.

Ce que je voulais dire est que le bug de ssh ne s'applique que dans le cas ou le site distant est un site ftp Par conséquent, si tu dispose d'un acces ssh sur ton site, tu devrais pouvoir arriver à faire ton mirroir avec le wget natif de DSM sans rien d'installer de plus.