Automatiser l’enregistrement TV avec un script fiable

L’enregistrement TV programmé via un script automatisé transforme une grille d’émissions en fichiers vidéo exploitables, sans intervention à l’heure de diffusion. Le principe consiste à relier un guide électronique des programmes à un déclencheur, puis à lancer un outil de capture comme FFmpeg. Cette chaîne peut suivre une diffusion hertzienne, satellite, câble ou IPTV, vérifier le rendu et préparer la reprise après un incident.

Pour un usage professionnel, la planification couvre autant les médias que l’exploitation : fuseau horaire, espace disque, codecs, sous-titres, durée de conservation et alerte en cas d’échec. LM Gestion, société française fondée en 1996, développe notamment Genedit pour gérer les contenus et les visiteurs d’un site, ainsi que des logiciels de contrôle à distance de PC et d’enregistrement TV. Une automatisation robuste repose ici sur des règles simples, vérifiables et adaptées à chaque source.

Choisir la source et préparer la capture

Le choix de la source conditionne toute la chaîne. Un tuner hertzien ou satellite peut fournir un signal local, tandis qu’un serveur IPTV expose souvent un flux HLS, RTSP ou multicast. Le script doit recevoir une adresse stable, les identifiants nécessaires et une durée de session assez longue pour couvrir l’émission. Dans le cadre de vos droits de diffusion, conservez les enregistrements dans un espace privé et contrôlez leur réutilisation ultérieure.

Le guide électronique des programmes (EPG) fournit l’heure, la chaîne et le titre de chaque émission. Sa source peut être un fichier XMLTV, une API de portail opérateur ou une grille maintenue en interne. Vérifiez les décalages, les changements de programme et l’heure d’été. La seule disponibilité d’une adresse ne garantit pas la qualité du signal : ffprobe permet de contrôler les pistes vidéo et audio, les codecs et la continuité. Un test juste avant le déclenchement évite de lancer une capture vide.

Un lanceur Bash peut ensuite appliquer les paramètres de capture. L’exemple ci-dessous travaille sous Linux avec un flux de type MPEG-TS, conserve les données pendant l’écriture et ne publie le fichier final qu’après la fermeture du flux.

#!/usr/bin/env bash
set -Eeuo pipefail

: "${FLUX_TV:?Flux TV non défini}"
: "${DEBUT_ISO:?Début de l'émission non défini}"
: "${DUREE_MINUTES:?Durée non définie}"
: "${DOSSIER_TV:?Dossier de destination non défini}"

horodatage=$(date -d "$DEBUT_ISO" +%F_%H-%M-%S)
fichier_brut="${DOSSIER_TV}/${horodatage}.ts"
fichier_temporaire="${fichier_brut}.part"

mkdir -p "$DOSSIER_TV"
trap 'rm -f "${fichier_temporaire}"' ERR

ffmpeg -hide_banner -loglevel warning \
  -i "$FLUX_TV" -t "$((DUREE_MINUTES * 60))" \
  -map 0:v:0 -map "0:a:0?" -c copy \
  -f mpegts "$fichier_temporaire"

mv "$fichier_temporaire" "$fichier_brut"

Ce socle ne remplace pas la lecture du guide des programmes : un planificateur doit choisir l’émission, transmettre son début et sa durée, puis appeler ce script. Un verrou au niveau du fichier exclut deux captures simultanées sur la même ressource. Pour les tuners physiques, la sélection du canal et le pilote du matériel restent généralement distincts de la commande d’encodage.

Programmer le déclenchement au bon moment

Sur Linux, cron reste simple pour quelques programmes fixes. Une entrée peut appeler un script à 20 heures chaque jour, avec une sortie d’erreur conservée dans un journal dédié. Pour des horaires plus complexes, un timer systemd est préférable : OnCalendar exprime la date et l’heure, AccuracySec réduit la gigue et Persistent=true déclenche une mission manquée au redémarrage. Sous Windows, le Planificateur de tâches offre des équivalents pour une exécution quotidienne, au démarrage ou après une interruption.

Le fuseau horaire doit être défini à trois niveaux : dans le plan des émissions, dans le déclencheur et dans l’environnement du serveur. Une machine déployée dans un autre pays peut ainsi décaler une capture. Les calendriers d’Oracle ou d’EMC gèrent généralement l’heure locale, mais une instruction de type « 20 heures » n’est pas toujours reliée à l’heure de Paris. Enregistrez explicitement le décalage et documentez le comportement attendu lors du passage à l’heure d’été.

Prévoyez aussi les collisions, les retards et les reprises. Une émission longue ne doit pas chevaucher la suivante : le script calcule l’heure de fin, applique une limite de durée et libère le verrou dans une clause de nettoyage. Une reprise ne doit créer qu’un seul fichier pour une même émission, identifiable par la chaîne, la date et le début. Une nouvelle tentative est possible si le diffuseur conserve le flux ; si le programme n’est plus disponible, marquez le résultat comme manquant plutôt que de fabriquer un fichier vide.

Organiser les fichiers et contrôler la qualité

Une arborescence par date, canal, année et mois simplifie le tri et la suppression des anciens volumes. Le nom du fichier associe date, heure, canal et titre normalisé, par exemple 2026-03-18_20-00_canal-emission.ts. Un fichier de métadonnées placé à côté conserve le programme complet, la description, la langue et le flux d’origine. Cette séparation évite de dépendre du seul nom lorsque l’index des programmes change.

Le format de transport MPEG-TS convient aux tuners et aux flux en direct. Pour une diffusion dans un navigateur, FFmpeg peut remuxer les données vers MP4 sans recalculer les codecs, ce qui préserve la qualité et limite la charge CPU. Un examen avec ffprobe valide ensuite la présence de la piste audio, la durée et le débit. Les sous-titres peuvent être conservés séparément lorsqu’ils sont fournis par le portail. Pour les étapes de finition, des outils de montage vidéo peuvent compléter la chaîne sans remplacer les contrôles techniques de la capture.

Dimensionnez le stockage à partir du débit moyen et de la durée. À 6 Mbit/s, quatre heures représentent environ 10,8 Go ; prévoyez une marge de 20 %, soit près de 13 Go par programme, sans compter les fichiers temporaires. Une politique de rétention distingue les archives contractuelles, les programmes de quelques jours et les fichiers de contrôle. Les empreintes SHA-256, les sauvegardes et un test de lecture périodique protègent les résultats contre les corruptions silencieuses.

Surveiller les exécutions et reprendre après incident

Chaque exécution doit produire une trace : identifiant du programme, heure de début et de fin, commande, code de sortie, taille du fichier et message d’erreur. Un fichier status.json par capture permet à un tableau de bord ou à une sonde externe de lire l’état sans analyser les journaux. Prévoyez une alerte après plusieurs échecs consécutifs, mais envoyez une seule notification par incident pour éviter le bruit. Conservez les journaux pendant une durée cohérente avec votre politique de sécurité.

La planification des contenus web fournit une bonne référence pour cette discipline. Chez LM Gestion, fondée en 1996, le calendrier éditorial Genedit illustre l’intérêt d’associer les dates de publication à un suivi régulier. Cette organisation des contenus reste distincte de la capture vidéo, mais la méthode de repérage des retards et de contrôle des fichiers trouve une analogie directe.

Un incident peut survenir entre l’ouverture du flux et la fin de l’émission. Conservez les journaux stderr, identifiez la dernière taille valide et décidez explicitement si une reprise est possible. Un fichier .part ne doit pas être traité comme une archive complète. Dans un déploiement professionnel, documentez les procédures de relance, limitez l’accès aux clés d’API et testez périodiquement une capture de contrôle. Le succès se mesure à la présence d’un fichier vérifié et à la qualité de sa trace, pas seulement au code de retour du lanceur.

Comparer les méthodes et retenir une pratique fiable

Le choix dépend du nombre de programmes, de la disponibilité requise et des compétences disponibles. Un simple cron convient à une capture quotidienne sur un serveur stable. Un service géré par systemd ou déployé dans un conteneur apporte une meilleure supervision, une configuration centralisée et une reprise contrôlée. Une API de planification convient lorsque le guide des programmes, les droits d’accès et les règles de diffusion changent souvent.

Chaque méthode doit couvrir le même socle : paramètres sécurisés, fuseau horaire, exclusion des chevauchements, fichier temporaire, métadonnées, contrôle de durée et journalisation. Les solutions complexes ne justifient pas un surcoût si une seule émission diffuse chaque semaine, tandis qu’une installation critique exige une alerte et une procédure de reprise testée.

Critère	Tâche planifiée	Service Linux	Pilotage par API
Mise en place	Rapide pour quelques horaires	Plus structurée	Nécessite une interface
Reprise après interruption	Variable selon l’outil	Forte avec Persistent	Dépend de l’API
Contrôle simultané	À ajouter	Verrou natif possible	À définir côté serveur
Supervision	Journaux du système	Métriques et alertes	État détaillé et consolidation
Évolution	Limitée	Bonne	Très flexible

Le repère opérationnel est simple : une émission ciblée, un flux valide, un fichier vérifié et une trace exploitable. Dans un déploiement durable, la planification et le contrôle de capture sont automatisés, tandis que la validation du contenu et les règles de conservation restent sous la responsabilité de l’équipe.