SCENARIchain-server 5 - webmedia

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 :

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

Merci d’avance pour vos idées

Salut, est-ce que tu as ces bogues quand tu édites via l’interface web ?

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

Étrange. Tu aurais un scar pour qu’on puisse constater le bogue ?
Ping @david_rivron

Voilà une ressource : WeTransfer
Mais franchement ça ne devrait pas venir de la ressource. Elle fonctionne très bien en local…

Voilà une vidéo qui illustre mon problème :

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 ?

2 pistes :

  • Votre VM est vraiment sous-dimensionnée : SCENARIchain-server 5.0 (Linux) (RAM en particulier)
  • 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…) ?

Bonjour,
Je m’arrache toujours les cheveux sur ce problème :cry:
ça ne semble pas être lié au deux pistes que vous évoquiez car :

  • aucune différence si je suis connecté directement à l’environnement
  • nous avons respecté les recommandations de la doc pour la RAM et nous ne constatons pas le moindre pic important de son utilisation…

Avez-vous les logs présents dans les logs SCENARI ?

Voilà les logs de scenari lors du déclenchement de nos bugs.

scstatic_2021-07-29.log (11,5 Ko)

Bonjour,

Les logs montre un problème de niveau réseau sur l’accès à la vidéo. Voici quelques pistes :

  • vérifier la présence de proxy_buffering off dans la configuration nginx
  • augmenter le idleTimeout de jetty en ajoutant jetty.http.idleTimeout=60000 dans /etc/jetty9/start.ini
  • vérifier qu’il n’y a pas de firewall ou antivirus qui entraverait la requête

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 :

ngnix.txt (2,5 Ko)

Bonjour,

vous avez bien augmenté la RAM pour Jetty ?
https://doc.scenari.software/SCENARIchain-server@5.0/linux/fr/#$0:jetty:zWg2NtWCOjjddBYXDPWsmg
Ne pas dépasser 50% de RAM de la machine pour la mémoire alloué à Jetty.

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;

Bonjour,

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

Bonjour,

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.

Merci beaucoup David !
Problème résolu en utilisant l’utilitaire de transcodage de WM :ok_hand: