MotionEye OS est affreux, lent et très lourd, il ne marche pas très bien sur un RPi 0/1. Alors l’option que d’utiliser Motion est viable, je le fais actuellement et c’est très performant, mieux que FFMpeg.
Avec RPi0 v1 tu peux utiliser la dernières version (ou non), mais dans mes tests, j’utilise Motion fourni via le APT. De mon avis c’est plus stable, le GIT peux contenir des bugs fix, mais aussi des ajouts plus lourd pour prendre en compte le RPi4 par exemple. Alors je fais confiance a une version précompilé fournis par le OS.
Newer is not necessary better (oldversion.com)
Avant d’ajuster les paramètres de Motion, vaut mieux tester en mode simple, soi seulement capturer et streamer en RTSP/HTTP selon ton choix.
Après tests la capture d’image et fini par la capture vidéo
Fait a noter, si tu opte pour la capture d’image, configure bien ton dossier ou il seront stocké, j’ai pas mégarde ativé cette option sans configurer le dossier, et j’ai rempli ma carte SD en quelques heures, ce qui a bloqué le OS bien dur. De plus les images était dans le dossier système de Motion, ce qui a compliqué la suppression. Le trop grand nombre de fichier a fait en sorte que sudo rm *.jpg ne pouvait traiter la demande (dans le dossier), il a fallu faire une quantité limité par le « sting match » pour supprimer l’ensemble.
Le système de Motion ne vérifie pas l’espace disponible avant d’écrire.
Ceci me dit que ton problème est au niveau de ta carte SD, il semble ne pas être en mesure d’écrire. Test sans sauvegarde (stream seulement) et en théorie tu n’auras pas ce problème. Après coup, si le problème est toujours la, tu as un problème très précis. Quand tu as un problème de ce genre c’est 3 choses qui sont impliqué; le CPU, la RAM et la carte SD.
En stream, seul le CPU et la RAM sont sollicité, alors si tu n’as pas de plantage, le CPU et la RAM ne sont pas en cause (et encore moins le logiciel, qui réside dans les deux). Si tu as quand même ce problème, alors c’est que ton CPU est surchargé, soit la RAM a un problème. Mais un problème en RAM n’est pas « permanent » car le système devrait être en mesure d’isoler les secteur problématique et continuer.
Sur la carte SD, si le problème a lieu, c’est que tu as atteint la limite lecture/écriture, soit des secteurs sont défectueux ou que la carte SD est de mauvaise qualité. Le plus simple est de faire une analyse de la carte, avec HWtest ou une analyse de surface avec Gparted (qui est moins profond, mais qui peut aider).
Petite histoire…
J’ai un serveur sous Debian qui est pour mes services réseau (torrents, partage de fichiers réseau, ASF, etc…) et j’ai eu le disque principal qui est mort.
Cependant je m’en suis rendu compte vraiment très tard après. Vu que l’ensemble du OS est chargé dans la RAM et utilise le CPU, peut d’interactions avec le disque dur ont lieux. Mes services utilisant ce disque dur sont tombé « planté »’ comme les torrents, car des problèmes d’écriture. Le système était lent vu le nombre d’erreur qui générais avec un disque dur principal « monté » mais « n’est plus présent ». Alors j’avais des erreurs de I/O a la volé. Le SSH ne marhait pas, vu son incapacité de charger le dossier à la connexion et de valider le user/pass. Le système était partiellement opérationnel, vu que j’ai Webmin de chargé. J’ai été en mesure de faire une ou deux actions avant que tout plante. Sur l’écran connecté, des erreurs en série apparaissait.
Si je relancais le système (reboot), j’avais des erreurs mais le système chargeait. J’ai eu un avertissement SMART (qui est absent du RPi), sur la fin du disque dur. Certains secteur pouvait être utiliser, mais clairement le système était instable.
J’ai du reconfigurer sur un nouveau HDD, et après quelques démarrage sur l’ancien disque dur, il nous a quitté pour de bon.
Ce qui est différent est que le serveur a plus de RAM, plus de puissance CPU, ce qui fait qu’une grande partie des applications sont donc chargé en mémoire et la lecture sur disque est minime. La lecture des torrents a fait en sorte que c’est le premier service qui a planté, vu qui doit lire les packet sur le HDD, après les autres services ont planté un après l’autre dès qu’il était sollicité, car justement ils ont besoin du disque dur pour certains éléments (identification, affichage de dossier, scripts…)
Vu que Webmin charge plusieurs modules en mémoire, j’ai été en mesure de l’utiliser, mais dès que je suis entré dans des sections ou l’usage du HDD était nécessaire, des erreurs sont survenu.
J’explique cette histoire car un unité de stockage quand il meurt, ne meurt pas d’un coup, il va commencer par avoir des secteurs défectueux et le tout grandi assez vite. Il peu avoir aucun problème a lire, mais écrire lui causera problème. Et tout dépend ou il va écrire. Alors par exemple le log du boot s’enregistre sur une section et la capture vidéo sur une autre e comble de (mal)chance, c’est sur un secteur défectueux.
Par exemple les carte chinoise SD peuvent être de faible qualité, il existe des clones Kingston et Sandisk, et par exemple, j’avais acheté 2 cartes SD Kingston 32GB de Chine, après des tests, seul les 8GB en début de carte existait vraiment, le resterait n’était que du « fake », pour visualiser la chose; ils ont surement changé le « header ID » de la carte pour ce faire passer pour une 32GB quand c’était une 8GB. Je ne dis pas que ta carte est un clone. Mais une carte avec une (grande) section morte peut quand même donner l’impression de marcher.
Il faut savoir que l’écriture de données ne suit pas une logique « humaine », le OS peut selon la demande aller porter les donner sur un espace vide ou l’entasser dans les premiers secteurs. Si il tombe sur un secteur défectueux, il va tenter de déplacer les données sur un autre secteur. Mais si il accumule les mauvais secteur, sont usage d’écriture monopolisera le système. C’est un peu comme si je te demande de rentrer un livre dans une bibliothèque, si tu prend le livre et arrive a le placer « sans trop y penser » dans un espace libre sans problème, ttu serais en mesure de continuer de me parler, mais si après 3-4 tentatives tu n’arriverais pas à entrer le livre sur la tablette de la bibliothèque, tu me demanderais surement de me la fermer pour tenter de résoudre ce problème, résultat; le SSH et autres services ne répondent plus parce que tu tente de compléter la demande de placement du livre qui te génère des problèmes.
Sarieux, faudrait je résume mieux mes idées, je sort toujours des romans, désolé 
