Relancer un script au démarrage... qui n'a pas démarré!

Bonjours à tous et toutes !

Voila mon petit problème :

J’ai un script qui se lance automatique sur des raspberry. Pour faire simple il doit se connecter à un NAS, et lancer en boucle et en plein écran les vidéos qui si trouvent.

Le script marche parfaitement une fois lancé.
Cependant à peu près 1 fois sur 10 les videos ne ce lancent pas.

Vu que j’ai 7 écrans qui on chacun un Raspberry au fesse avec chacun le même script qui ce connecte au même NAS, il y en a souvent un qui ne marche pas. Bien évidement c’est jamais le même.

J’aimerai donc rajouter à mon script un système de contrôle qui detecte si les vidéo n’ont pas été lancé et relancer le script.

J’ai rien trouvé sur le forum où sur internet, a moin que si mais trop compliqué pour que j’ai remarqué la solution…

Le script de base avait été fait il y a 2 ans avec Nabla ici même :

Hello,

Regarde avec healthchecks.io

C’est simple et efficace et tu peux être notifié de pleins de façons. Tu peux aussi y installer sur un serveur local

Merci pour le lien.

Cependant je ne comprend pas exactement le fonctionnement. A la fin de mon script je rajoute

curl --retry #

Avec « # » un chiffre/nombre en seconde.
En gros, si le scripte ne fonctionne pas il attend # secondes avant de le relancer c’est ça ? J’ai rien d’autre à rajouter à la suite du scripte ?

Sinon je n’ai pas besoin de notification car le systeme fonctionne dans un magasin et on le voie de suite si cela n’a pas fonctionné, Je veut juste automatiser la relance du scripte.

Hello !

Alors non, le lien te permets juste de savoir si le job est passé ou non :smiley:

J’avais lu en diagonale ta demande désolé.

Il faudrait rajouter un controle dans ton script mais je passe mon tour pour cette partie désolé

Salut @Shaitan,

Je pense que le souci vient d’une mauvaise connectivité réseau.
Donc, une idée en marge.

Je sais que tu es sur NAS.
Mais on pourrait imaginer un truc.

Tu gères tes vidéos sur le NAS pour centraliser (plus simple pour toi)
Mais tu envoies les fichiers du NAS vers chaque Rpi de manière régulière avec un rsync (et option --delete pour supprimer des Rpi ce que tu as supprimé du NAS)

Comme ça, chaque Rpi est le contrôleur de lui-même et ça fonctionnera même si petit souci de réseau.
Non ?

Sinon, on ne peut pas demander au Rpi de patienter et d’attendre le réseau afin de démarrer de manière « sûre » ?

++

hello,

si tu utilises omxplayer et si lorsque la vidéo se plante, ça reste planté ( ça fait beaucoup de « si » :roll_eyes: ) cette option devrait arrêter l’exécution et je suppose passer à la suivante. ( et ce, si comme le suggère Nabla c’est un problème réseau, jusqu’à ce que celui ci soit plus dispo ! )

 --timeout     n         Timeout for stalled file/network operations (default 10s)

encore faut il trouver la bonne valeur de timeout …

source :
man omxplayer

Bonjour @Nabla, comment vas tu ?

Oui au début j’avais un problème de connection qui était assez récurrent, je l’ai corrigé au moment du boot du raspberry. Donc à présent, le Boot se poursuivra que si il est connecté au réseaux, d’un échec sur 3 je suis passé à 1/10. Beaucoup mieux.

Je suis partant pour rsync. Donc dès qu’il y aura une modification dans le dossier video du NAS, il le vera et modifiera aussi dans le pi. Est-ce bien cela ? Que cela soit une nouvelle video ou une suppression ? Si oui cela serai pas mal.

Comment on utilise rsync ?

Bonjour @bof.

Je ne sais pas quand le script plante. mais se qui est sur c’est qu’aucune video ne sais lancé. Je n’ai pas eu le cas où les vidéos on commencé et d’un coup sa plante.

je me suis mal exprimé ; j’aurais du dire :« quand les vidéos ne démarrent pas »…
ce qui est probable c’est que si trop de Rpi demandent une vidéo le serveur NAS ( ou le réseau ) sature !
en mettant un timeout le programme de lecture devrait arrêter d’essayer de charger la video au bout d’un nombre de secondes a déterminer ( si j’ai bien compris si le programme ne reçois plus de données pendant 10 secondes ( valeur par défaut ) - c’est la notion de « stalle » - il doit s’arrêter et passer a la commande suivante de ton script ) ce qui devrait permettre de récupérer moins de fichiers « vérolés » qui doivent planter le lecteur…

@bof j’ai 7 Rpi qui se connecte au même NAS, mais sur des dossiers différents (chacuns à sa playliste). Et sinon oui ils s’allume en même temps mais la pause est différente pour chacun afin qu’il y ai au moin 10s entre chaque execution :
Rpi1->10s->Rpi2->10s->Rpi3…

Salut @Shaitan

Ça roule, je te remercie.
Faudrait que je trouve le temps de passer te voir … :wink:

rsync est une base sous Linux.
C’est génial
En gros, ça fait une copie MAIS ça ne copie QUE ce qui a changé.
Exemple, le dossier de NAS du Rpi n°1 contient vidéo01, vidéo02 et vidéo03
Tu fait un rsync = les 3 vidéos sont copiées dans le Rpi n°1
Sur le dossier du NAS, tu vires vidéo01 mais ajoute vidéo04
Une fois rsync lancé, il voit que vidéo04 est ajouté = il l’ajoute … et si tu as l’option --delete alors, il vire vidéo01 du Rpi n°1 car ce fichier n’existe plus sur le NAS.

Mais attendons donc d’autres avis et d’autres pistes de réflexions avant de se lancer là dedans :wink:

++

dans ta logique de temporisation et si le plantage d’une de tes machines ne se produit qu’aux démarrages il suffirait, peut-être, d’en débrancher une puis deux puis n . jusqu-à ce que plus aucune ne se plante et de coller à n machines un délai plus long avant d’accéder au NAS…

@bof

L’ordre de demarage est toujours le même, avec la même temporisation. cependant il y a toujours un script d’un Rpi qui plante(1 fois sur 10) mais jamais le même : des fois Rpi1, le lendemain peu etre Rpi6, le suivant surement Rpi3 etc…

C’est pour cela qu’une commande qui relance le scripte en cas d’échec serait pas mal. Sachant que el script est bien lancé par le Rpi# car les premières instrutions sont bien executé (cacher la sourie, etc…)

@Nabla
Rsync à l’air pas mal, tu me vend du reve là ! :smile:

quel est l’inconveniant ?

Yo @Shaitan

A mon avis aucun inconvénient.
Sauf de faire une erreur lors de la frappe de la commande mais le souci est alors « la couche 8 » :smiley: et non rsync

En grso, je ne vois pas d’inconvénient.
Si la commande est bonne et qu’elle est inscrite en tache cron, ça te simplifie la vie (en espérant que çale résolve le souci d’affichage).

++

c’est possible avec lxde ( le bureau de debian « buster » ) c’est la notion d’autostart
il faut mettre un lien dans le fichier /etc/xdg/lxsession/LXDE-pi/autostart du style :

@/usr/bin/python /home/pi/example.py
ou
@/home/pi/example.py si ton fichier est executable

le @ devant devrait faire redémarrer le programme en cas de plantage.

@bof … Sauf que si l’affichage dynamique est avec OMXplayer sur un Raspbian Lite, ça ne fonctionne pas :wink:

Et j’avoue que je ne sais plus qu’elle version est en route chez @Shaitan puisque j’avais, à l’époque, fait un tuto en graphique et un en Lite … :relaxed:

@Shaitan : version graphique ou pas ?

++

@bof @nabla Oui en version graphique… dsl

Re,

Dans mon tuto du 26/12/2018, je lis " un sudo nano /etc/xdg/lxsession/LXDE-pi/autostart pour modifier la séquence de démarrage"

Dans l’article du 30/12/2018, je lis "modification du programme de démarrage avec sudo nano /etc/rc.local pour ajouter la ligne sudo bash /home/pi/script-lecture-automatique.sh"

Je ne sais plus ce que tu avais fait en réalité.
Ton script se lance comment actuellement ?
Tu pourras regarder sur un des Rpi ?
Il suffit de faire

sudo nano /etc/rc.local

et

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

pour vérifier où est le script.

++

Voici le script tournant actuellement :

#!/bin/sh

# On temporise le temps que la connection Wifi ce fasse

sleep 5


# On déplace la souris pour cacher la barre du menu démarrer (avant: sudo apt-get install xautomation)

xte 'mousermove +10000 +10000'


# On monte le dossier du NAS dans /home/pi/Partage

sudo mount -a


# On efface le curseur de la souris de l'écran

setterm -cursor off



# On définit le chemin de stockage des vidéos

VIDEOPATH="/home/pi/Partage"



# On définit le service à utiliser, ici OMXPLAYER

SERVICE="omxplayer"



# On scanne en boucle le dossier

while true; do

    if ps ax | grep -v grep | grep $SERVICE > /dev/null

    then

    # le script plante parfois si la pause n'est pas assez longue

    sleep 150; 

else

    for entry in $VIDEOPATH/*

    do

            clear

            omxplayer -b $entry > /dev/null

    done

fi

done