Bonjour,
J’ai un server scenari 5 installé en suivant cette documentation : doc
Je lui ai ajouté les modèles Opale 3.8 et Webmedia 3.1, et migré tout notre contenu qui était précédemment sur un chain4.2
Je rencontre des soucis avec l’utilisation de Webmedia, à partir du moment où l’on lance la vidéo pour compléter une segmentation :
les menus contextuels ne restent pas affichés (juste un clignotement)
les images déposés dans des fragments ne sont pas enregistrées
parfois les images s’insèrent bien, mais leur aperçu n’est pas présent (Cf. copie d’écran)
Ces bugs n’arrivent qu’à partir du moment où on a lancé la vidéo.
Je penchais donc pour un soucis de RAM ou de bande passante, mais pourtant il n’y a aucune surcharge apparente du serveur…
Je précise que ces bugs n’apparaissent absolument pas avec le même atelier en local sur scChain5 et webmedia3.1
Effectivement, j’ai l’impression de rencontrer le même type de problèmes.
Tant que je n’ai pas lu la vidéo, je peux insérer des images sans soucis dans mes fragments.
Par contre, dès que j’ai lancé la lecture, l’explorateur ne m’affiche plus rien
tant que je n’ai pas lancé la vidéo tout va bien, mais dès que je fais un clique sur la timeline de la vidéo… l’explorateur de fichier ne répond plus correctement
Dans quel contexte réseau êtes-vous (à domicile, environnement pro…) ?
Tout porte à croire qu’une seule connexion vers le serveur Scenari n’est autorisé simultanément. Comme la video en cours de consultation consomme une connexion en continu, les autres seraient alors en attente.
le server est hébergé sur un serveur dédié chez OVH. Il a une VM qui lui est réservé.
Par contre on a bien pris la conf de nginx proposée dans la doc. Du coup qu’est-ce qui pourrait restreindre le nombre de connexions ?
votre réseau coté client limite les connexions : le comportement est-il le même de votre domicile et de votre environnement de travail (s’ils sont différents…) ?
Nous avons écarté ces 3 hypothèses, et réaugmenté la RAM (8Go pour la VM). Rien n’y fait, toujours le même bug.
Je vous mets ci-dessous notre config ngnix :
jetty.http.idleTimeout=60000 as été test ? si oui l’erreur est maintenant à 60000ms dans les logs si elle existe encore ?
Plein de header en double dans la config proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
sont déjà inclus dans include proxy_params;
On a 8Go sur le VM et 3 pour Jetty, donc on est bien dans les ratios recommandés.
On a aussi testé d’augmenter le Timeout à 300000 mais sans succès.
On a supprimé les header en double…
Une chose me paraît surprenante.
On arrive pas à supprimer des données. Je me demande si cela peut avoir un rapport.
J’ai de nombreuses vidéos (Webmedia). Quand je les supprime, elles ne libèrent pas d’espace sur le disk… Du coup là je suis à 93% occupé alors qu’en théorie je devrais être autour de 60%…
La corbeille des ateliers est bien vide. Est-ce qu’il y a une corbeille pour les ressources ? Edit : J’ai trouvé la corbeille des ressources
Bonjour,
J’ai finalement libéré 50Go d’espace disque sur notre VM. Mais toujours pas de succès.
Pouvez-vous me dire si une prestation de service est envisageable pour un audit de notre paramétrage serveur ? De notre côté, tout a été essayé…
D’avance merci pour votre réponse
Le problème se situe en fait à deux niveaux : votre vidéo n’est pas optimisée pour le stream et cela pose problème à l’implémentation http2 du client lourd .
Une première façon de résoudre le problème est de désactiver l’usage de http2 dans le client. Pour cela, il faut ouvrir la fenêtre de configuration avancé avec Ctrl+Maj+K, passer la propriété network.http.spdy.enabled.http2 à false et redémarrer l’application.
La seconde solution, que je recommande, est d’optimiser la vidéo pour le stream (cad activer le faststart). Cela peut se faire en réencodant la vidéo en cochant « Optimiser pour le web » dans HandBrake ou en utilisant l’extension de transcodage de WM. L’utilitaire qt-faststart de ffmpeg permet cette activation sans réencodage.
