Replay et timeshift : ce que c’est et pourquoi votre fenêtre est plus courte qu’annoncé

Trois mots servent à désigner des choses qui se recouvrent. Commençons par les séparer.

Le timeshift, c’est mettre en pause ou rembobiner un flux en direct que vous êtes en train de regarder. Le replay, c’est ouvrir un programme terminé plus tôt depuis l’archive de votre fournisseur. L’enregistrement, c’est capturer un flux dans un fichier sur votre propre machine.

Ils sont implémentés différemment, ils échouent différemment, et un seul est entièrement sous votre contrôle.

Pourquoi vous ne pouvez généralement pas rembobiner un flux en direct#

Commençons par celui dont tout le monde attend qu’il fonctionne, et qui ne fonctionne généralement pas.

Un flux IPTV en direct, dans sa forme normale, est une unique réponse HTTP qui ne se termine jamais. Il n’y a pas de longueur. Il n’y a pas d’index. Le serveur écrit des octets et le lecteur les lit, et aucun des deux n’a la moindre notion d’une position il y a 10 minutes, parce que rien ne l’a conservée.

Le propre garde-fou du client pour la recherche en direct reflète cela précisément : le lecteur doit signaler le flux comme seekable et une longueur positive doit être disponible. Les deux conditions doivent tenir. Le transport n’entre pas du tout en ligne de compte.

Le test qui couvre ce point porte un commentaire honnête : un flux de transport en direct typique peut avoir un démultiplexeur qui se déclare seekable alors qu’il n’y a aucune longueur sur laquelle se déplacer. Une déclaration sans longueur n’est pas une capacité.

Certains fournisseurs proposent bien une fenêtre de direct rembobinable. Là où c’est le cas, elle est implémentée comme l’archive plutôt que comme une propriété du flux en direct, ce qui nous amène au mécanisme qui compte.

Comment le replay fonctionne réellement#

Un fournisseur qui conserve une archive enregistre ses propres chaînes, en continu, sur un stockage de son côté. Votre client ne lit pas un fichier sauvegardé qui aurait un nom ; il demande une tranche de la chronologie de la chaîne.

Le fait structurel, c’est que le client construit cette requête. Aucune URL par programme n’est livrée où que ce soit. Le constructeur prend une chaîne, une heure de début et une durée, et produit une adresse :

live      http://line.example.com:8080/user/pass/12345.ts
catch-up  http://line.example.com:8080/timeshift/user/pass/120/2026-08-30:21-00/12345.ts
                                                  ^^^  ^^^^^^^^^^^^^^^^^^^^
                                                  minutes    start, local time

Deux conséquences en découlent, et toutes deux expliquent des signalements qui, sinon, ressemblent à des bugs.

Un portail qui prend en charge les archives mais utilise une autre disposition de chemin recevra une requête vers une adresse qui n’existe pas chez lui. Depuis le canapé, cela ressemble à un programme manquant plutôt qu’à une mauvaise URL.

Et l’heure de début et la durée viennent d’une ligne de programme. Le replay dépend donc du guide, entièrement.

La raison pour laquelle votre fenêtre est plus courte qu’annoncé#

Votre fournisseur dit 7 jours. Vous en atteignez 2. Rien n’est cassé et personne ne ment.

Une entrée de replay est matérialisée à partir d’une ligne de programme de votre guide. Un programme que votre guide ne détient plus n’a pas de ligne, et donc rien à ouvrir. La profondeur atteignable est donc la plus petite des deux : la fenêtre d’archive du fournisseur, ou la rétention de votre guide.

La rétention du guide n’est pas accidentelle non plus. L’analyseur conserve par défaut 8 jours en avant et 1 jour en arrière, bornés à 14 et 7, et il écarte les programmes hors de cette fenêtre pendant l’analyse plutôt que de les stocker pour les purger ensuite. Un guide qui publie 14 jours vers un client qui en garde 8 ne perd pas de données par défaillance.

provider archive   7 days back
guide retention    1 day back  (default)
reachable          1 day back

Donc si votre fenêtre de replay est décevante, ce qu’il faut étendre, c’est la rétention du guide, pas un réglage d’archive. Cela m’a surpris la première fois que j’ai remonté une promesse de 7 jours jusqu’à une fenêtre de 1 jour : l’endroit naturel où chercher est un réglage d’archive, et la limite vit dans l’analyseur du guide. C’est la chose la plus utile de cet article.

Ce qui est construit et ce qui ne l’est pas#

Le replay a d’abord été livré sur la version de bureau, avec sa propre version de schéma de catalogue. La page console est désignée comme travail restant, avec les positions de reprise et la resynchronisation des indicateurs. Donc sur une Xbox aujourd’hui, vous avez les chaînes en direct et la grille, et le rembobinage se trouve dans l’Application Windows. Télévision de rattrapage sur Xbox dit quoi faire en attendant.

La cascade prévue, où le comportement d’archive se décide par source, puis par chaîne, puis pas du tout, est à moitié construite. La matérialisation d’URL est livrée. L’interface de réglages pour choisir entre ces niveaux ne l’est pas.

L’enregistrement, la partie que vous contrôlez#

Tout ce qui précède dépend de ce que votre fournisseur conserve quelque chose. L’enregistrement, non.

La programmation depuis le guide est complète, et le planificateur est attentif à ce qui gâche le plus souvent un enregistrement : les horaires du guide sont approximatifs d’une façon que les tranches d’archive ne sont pas. Un enregistrement depuis le guide applique une marge automatique de 2 pour cent de la durée du programme, bornée entre 1 et 5 minutes, à chaque extrémité :

programme     margin (2% of duration, clamped to 1..5 minutes)
30 minutes    1 minute      (0.6 rounded up to the floor)
40 minutes    1 minute
2 hours       2.4 minutes
3 hours       5 minutes     (3.6 would be 3.6, the ceiling binds at longer runs)

Un enregistrement terminé porte comme vignette une image extraite de lui-même, plutôt que le logo de la chaîne, si bien qu’une liste d’enregistrements se parcourt d’un coup d’œil.

Deux propriétés des enregistrements sont délibérées plutôt qu’accidentelles.

Les enregistrements sont des fichiers locaux sur le client qui les a créés. Le serveur ne détient aucune donnée d’enregistrement : il n’y a pas de famille d’enregistrements dans le modèle de synchronisation et aucun type d’enregistrement dans le service de catalogue. La gestion des enregistrements côté serveur a été retirée des objectifs plutôt que reportée, parce qu’un index de ce que vous avez enregistré est une connaissance de ce que vous regardez, et le détenir rendrait le service conscient du contenu. C’est une ligne que ce produit ne franchit pas, et le DVR cloud est un non-objectif permanent au titre de la même règle.

Et une capture en direct ne peut pas rapporter sa progression en pourcentage, parce que la durée d’entrée est inconnue. C’est le même fait que celui qui rend la recherche en direct impossible, qui réapparaît à un autre endroit. Un enregistrement en cours peut vous dire depuis combien de temps il tourne. Il ne peut pas vous dire où il en est, parce qu’il n’y a pas de fin à laquelle se mesurer.

Ce que l’enregistrement fait réellement au flux#

Un enregistrement est un remux, pas un réencodage. Le moteur de capture pilote FFmpeg pour copier les flux élémentaires depuis le transport en direct vers un fichier, sans rien décoder ni recompresser. L’image dans le fichier est, bit pour bit, l’image qui a été diffusée.

Deux conséquences en découlent directement.

Cela ne coûte presque rien. Il n’y a ni décodage ni encodage, juste un démultiplexage et un multiplexage, donc enregistrer une chaîne 4K ne charge pas la machine comme le fait sa lecture. Vous pouvez enregistrer tout en regardant autre chose.

Et il n’y a pas de réglages de qualité, parce qu’il n’y a aucune décision de qualité à prendre. Un enregistrement est exactement aussi bon que le flux, et pas meilleur. Si la chaîne est un upscale 1080p mou, le fichier l’est aussi. Des préréglages de qualité d’enregistrement figurent sur notre propre liste de travail restant, et ce qu’ils contrôleraient réellement est un réencodage, qui est une fonctionnalité différente avec un coût différent.

Un prérequis pratique : FFmpeg doit pouvoir être résolu. S’il est absent, la capture renvoie une erreur d’exécutable introuvable plutôt que d’échouer silencieusement à mi-chemin.

Où vont les enregistrements#

Deux backends sont livrés : le disque local et un partage réseau SMB, avec un test de connexion pour le second, si bien que vous découvrez que les identifiants sont faux avant un enregistrement plutôt qu’après.

Une cible SMB est la bonne réponse pour un foyer équipé d’un NAS, et elle change considérablement l’arithmétique. La télévision en direct aux débits de diffusion représente quelques gigaoctets par heure. Une saison de n’importe quoi remplit vite un ordinateur portable.

Un backend cloud n’est pas implémenté et, pour la raison de frontière évoquée plus haut, n’est pas prévu non plus.

La lacune dans la programmation#

Les enregistrements individuels depuis le guide fonctionnent. L’enregistrement récurrent et par série n’existe pas.

Donc « enregistrer chaque épisode de ceci » n’est pas quelque chose que vous pouvez demander aujourd’hui ; chaque épisode est programmé séparément depuis le guide. C’est la plus grande lacune de ce domaine du produit, et il vaut la peine de le savoir avant de bâtir un flux de travail autour.

Le coût en connexions que personne ne budgète#

Une chose piège les foyers, et elle s’applique également aux 3 mécanismes.

Le replay est un flux. L’enregistrement est un flux. Tous deux consomment une connexion du fournisseur aussi longtemps qu’ils tournent, exactement comme le visionnage en direct. Une ligne autorisant 2 connexions, avec 1 enregistrement en cours, en a 1 de libre.

C’est pourquoi un enregistrement programmé pour la soirée peut discrètement empêcher quelqu’un d’autre de regarder, et pourquoi deux enregistrements qui se chevauchent sur une ligne à 2 connexions signifient que personne ne regarde rien. Le volet enregistrement de la prise en compte des connexions est sur notre liste de travail restant, donc l’application ne vous avertit pas actuellement de cette collision avant qu’elle se produise. Connexions maximales couvre la comptabilité, y compris pourquoi une connexion peut rester consommée après l’arrêt d’un flux.

Lequel utiliser#

Si le programme a déjà été diffusé et que votre fournisseur a une archive, utilisez le replay, et attendez-vous à ce que la fenêtre atteignable soit bornée par votre guide plutôt que par la promesse du fournisseur.

Si le programme n’a pas encore été diffusé, enregistrez-le. Il n’expire pas quand la fenêtre du fournisseur se referme, et il ne dépend pas de la rétention du guide après coup. C’est un fichier qui vous appartient.

Si vous voulez mettre en pause la télévision en direct, la réponse honnête est que vous ne pouvez généralement pas, et la raison est structurelle plutôt qu’une fonctionnalité manquante. MPEG-TS ou HLS couvre ce qu’est un flux en direct et pourquoi une position dans celui-ci n’est pas une chose qui existe.