Le défaut
Un transcodage en direct n'a ni longueur ni plages : le serveur répond
Accept-Ranges: none et refuse en 416 toute plage qui ne part pas du premier
octet (waveflow-server, src/media.rs).
Quand le réseau se coupe en cours de lecture, Media3 fait ce qu'il fait
toujours : il rouvre le flux à l'octet où il s'était arrêté, donc avec un
Range: bytes=N-. Le serveur refuse. Media3 reçoit une erreur 2008
(ERROR_CODE_IO_READ_POSITION_OUT_OF_RANGE) que
DefaultLoadErrorHandlingPolicy classe jamais retentable.
Résultat : une coupure de deux secondes dans le métro fait tomber la lecture,
définitivement, et non pas le temps de la coupure.
Pourquoi ce n'est pas déjà corrigé
C'est un manque connu et assumé de la PR #54, écrit dans
docs/deplacement-dans-un-transcodage.md, section « Ce que cette première
version ne couvre pas » :
La coupure réseau pendant un transcodage. Media3 reprend à l'octet
atteint, et le serveur refuse cette plage. La même relance l'y ramènera, au
décalage de la position logique courante — dans une PR suivante, une fois
l'enveloppe en place.
Le correctif de la #52 (IncompleteTranscodeEviction) traite un cas voisin
mais différent : il empêche le début d'un transcodage abandonné de rester dans
le cache. Il ne fait rien pour une coupure en vol.
Ce qui rend le correctif possible aujourd'hui
L'enveloppe existe désormais (TranscodeSeekingPlayer, PR #54), et avec
elle la relance : remplacer le flux de la piste courante par le même morceau
demandé à un autre offset_ms.
La reprise après coupure est donc exactement une relance, au décalage de la
position logique courante — la position que l'enveloppe publie déjà.
À éprouver
- Un
MockWebServer qui coupe le flux en plein milieu, puis accepte à nouveau :
la lecture doit reprendre là où elle en était, pas au début, pas du tout.
- Une coupure sur un fichier original (non transcodé) doit continuer à se
comporter comme avant : les plages y fonctionnent, il n'y a rien à relancer.
- Le compteur d'écoute ne doit pas voir de changement de piste (règle R5).
Lien
Voir docs/deplacement-dans-un-transcodage.md, règles R5, R7 et R11.
Le défaut
Un transcodage en direct n'a ni longueur ni plages : le serveur répond
Accept-Ranges: noneet refuse en 416 toute plage qui ne part pas du premieroctet (
waveflow-server,src/media.rs).Quand le réseau se coupe en cours de lecture, Media3 fait ce qu'il fait
toujours : il rouvre le flux à l'octet où il s'était arrêté, donc avec un
Range: bytes=N-. Le serveur refuse. Media3 reçoit une erreur2008(
ERROR_CODE_IO_READ_POSITION_OUT_OF_RANGE) queDefaultLoadErrorHandlingPolicyclasse jamais retentable.Résultat : une coupure de deux secondes dans le métro fait tomber la lecture,
définitivement, et non pas le temps de la coupure.
Pourquoi ce n'est pas déjà corrigé
C'est un manque connu et assumé de la PR #54, écrit dans
docs/deplacement-dans-un-transcodage.md, section « Ce que cette premièreversion ne couvre pas » :
Le correctif de la #52 (
IncompleteTranscodeEviction) traite un cas voisinmais différent : il empêche le début d'un transcodage abandonné de rester dans
le cache. Il ne fait rien pour une coupure en vol.
Ce qui rend le correctif possible aujourd'hui
L'enveloppe existe désormais (
TranscodeSeekingPlayer, PR #54), et avecelle la relance : remplacer le flux de la piste courante par le même morceau
demandé à un autre
offset_ms.La reprise après coupure est donc exactement une relance, au décalage de la
position logique courante — la position que l'enveloppe publie déjà.
À éprouver
MockWebServerqui coupe le flux en plein milieu, puis accepte à nouveau :la lecture doit reprendre là où elle en était, pas au début, pas du tout.
comporter comme avant : les plages y fonctionnent, il n'y a rien à relancer.
Lien
Voir
docs/deplacement-dans-un-transcodage.md, règles R5, R7 et R11.