Bha d'autant plus que dans un serveur de lecture DCI, il n'y a aucun nom d'origine. C'est le principe de l'INGEST. Toutes les ressources sont indexées (une sorte d'annuaire) par leur UUID et les fichiers sont renommés par celui-ci. Evite d'ingester par exemple 2 fois le même DCP, pratique aussi pour la gestion des version-file. De plus toutes les CPL ingestés génèrent une PKL qui reprend les même ressource de ces même CPL ; pratique pour ingester une version de serveur à serveur. (ou pour export sur un disque dur)
Coeur noir à raison, c'est un bug du software. (en l’occurrence 2.6.4-). (y'en à d'autre)
Serveur GDC: Etiquette d'automatisation [FIRE-ALARM] |
- Messages : 820
- Enregistré le : mar. 11 mai 2010 - 13:33
- Localisation : Paris
- Messages : 3139
- Enregistré le : ven. 21 oct. 2011 - 13:17
- Localisation : entre les toilettes et la cabine suivant les pannes
Re: Serveur GDC: Etiquette d'automatisation [FIRE-ALARM]
c'est pourtant la seule différence que j'ai remarque dans les CPL entre un DCP qui bloque le son quand il est verrouillé et un DCP qui ne le bloque pas en étant aussi verrouillé 
- Messages : 4339
- Enregistré le : lun. 2 mars 2009 - 10:16
- Localisation : Maine et Loire - France
- Contact :
Re: Serveur GDC: Etiquette d'automatisation [FIRE-ALARM]
Le logiciel doremi considère probablement le . comme un caractère particulier, signifiant ?
Alors que sous linux le type d'un fichier n'est pas déterminé par son nom mais par son entête dans les metadata ( internes au fichier, quand elles existent ). Sous windows il sert à séparer le nom ( du fichier ) de son extension ( info de type ).
Et de toute façon dans le cadre DCI, voir la précision de DarkLover dont la rigueur est toujours appréciable
Alors que sous linux le type d'un fichier n'est pas déterminé par son nom mais par son entête dans les metadata ( internes au fichier, quand elles existent ). Sous windows il sert à séparer le nom ( du fichier ) de son extension ( info de type ).
Et de toute façon dans le cadre DCI, voir la précision de DarkLover dont la rigueur est toujours appréciable
- Messages : 618
- Enregistré le : lun. 10 déc. 2007 - 18:11
- Localisation : région parisienne
Re: Serveur GDC: Etiquette d'automatisation [FIRE-ALARM]
Bonjour à tous et Coeur Noir en particulier,
Bon, nous avons fini par identifier le problème. Effectivement, les serveurs GDC sont bien en cause. Ils généraient de manière aléatoire une étiquette [Fire-Alarm]qui mettait la séance en pause avec ré-allumage de la salle.
Cette étiquette existe depuis plusieurs années et est apparue lors d'une mise à jour GDC d'une visite annuelle de maintenance. Elle sert à arrêter la projection en urgence quand le contenu lu n'est plus valide. Le serveur GDC est performant ( trop ! ) sur ce plan là, il détecte toutes les anomalies même quand ils n'y en avaient pas ou non précisées !
Pour que le problème s'arrête, la fonction de commande [Fire-Alarm] a été désactivée.
Voilà, c'est tout bête. Mais cela a pris quand même 2 mois de recherche plus ou mois infructueuse ! Si cela peut servir aux autres qui ont des GDC.
Bon dimanche
Bon, nous avons fini par identifier le problème. Effectivement, les serveurs GDC sont bien en cause. Ils généraient de manière aléatoire une étiquette [Fire-Alarm]qui mettait la séance en pause avec ré-allumage de la salle.
Cette étiquette existe depuis plusieurs années et est apparue lors d'une mise à jour GDC d'une visite annuelle de maintenance. Elle sert à arrêter la projection en urgence quand le contenu lu n'est plus valide. Le serveur GDC est performant ( trop ! ) sur ce plan là, il détecte toutes les anomalies même quand ils n'y en avaient pas ou non précisées !
Pour que le problème s'arrête, la fonction de commande [Fire-Alarm] a été désactivée.
Voilà, c'est tout bête. Mais cela a pris quand même 2 mois de recherche plus ou mois infructueuse ! Si cela peut servir aux autres qui ont des GDC.
Bon dimanche