Combien de temps Spotify continuera-t-il à jouer après la perte de connexion?

J'écoutais Spotify et ma connexion Internet a été interrompue. Bien que je ne sois pas surpris que la chanson soit toujours terminée (à cause de la mise en mémoire tampon), j’ai été surprise de passer à la suivante et de continuer à jouer pendant plusieurs minutes (puis je suis revenu à Internet).

Combien de temps Spotify peut-il continuer à jouer après la perte de la connexion? Supposons qu'aucun fichier ne soit "activé hors connexion".

La tâche peut être plus difficile à analyser que simplement "chronométrer"

Spotify mettra en cache les chansons précédemment jouées. Si l'une de ces chansons est lue lorsque votre ligne tombe en panne, elle est déjà sur votre appareil et vous ne le remarquerez même pas.

Quant à la taille exacte de la mémoire tampon à un moment donné, elle s'adapte automatiquement et peut aller de 15 à une chanson entière, en fonction de la source, de l'homologue ou du serveur [voir ci-dessous].

J'ai inclus ces articles dans le seul but de les approfondir - trop pour préciser ici, mais donnez des explications assez simples.
Spotify pour les nuls a un bon article sur le cache et comment ajuster sa taille.
Technologie Spotify: Fonctionnement de Spotify contient quelques informations simples sur le fonctionnement de la technologie de streaming.

J'ai trouvé le document faisant autorité sur le sujet, rédigé par Gunnar Kreitz et Fredrik Niemelä ...
Spotify - Diffusion à grande échelle, faible latence, musique P2P

Extrait:

Une piste donnée peut être téléchargée simultanément à partir du serveur et de plusieurs pairs différents. Si un homologue est trop lent à satisfaire une requête, celle-ci est renvoyée à un autre homologue ou, si l'obtention des données est devenue trop urgente, au serveur.
Lors de la diffusion en continu depuis un serveur, les clients limitent leurs demandes de manière à ne pas dépasser d'environ 15 secondes le point de lecture actuel, s'il existe des homologues disponibles pour le suivi. Lors du téléchargement à partir du réseau d'égal à égal, aucune telle limitation ne se produit et le client tente de télécharger l'intégralité de la piste en cours de lecture. Si un utilisateur change de piste, les demandes relatives à la piste en cours sont abandonnées.
Les fichiers servis au sein du réseau d'égal à égal sont divisés en morceaux de 16 Ko. Lorsqu'il détermine à quels pairs demander des morceaux, le client trie les pairs d'après leurs temps de téléchargement prévus (calculés comme le nombre d'octets de demandes en attente de l'homologue, divisés par la vitesse de téléchargement moyenne reçue de cet homologue) et demande avidement le morceau le plus urgent. à partir de l'homologue avec le temps de téléchargement estimé le plus bas (puis met à jour les temps de téléchargement attendus). Cela signifie que les morceaux d'une piste sont demandés dans un ordre séquentiel. Comme tous les homologues qui desservent un fichier ont l'intégralité du fichier, la demande de blocs dans l'ordre n'affecte pas la disponibilité ni les vitesses de téléchargement.
Un client peut tout au plus avoir des demandes en attente d'un pair donné pour des données qu'il pense pouvoir livrer en moins de 2 secondes. Une exception à cela est qu'il est toujours autorisé d'avoir des demandes de 32 ko en attente d'un homologue. Si le temps de téléchargement estimé d'un bloc dépasse le moment où le bloc est nécessaire, ce bloc n'est pas demandé.

…

Les clients Spotify ne limitent pas la taille de la mémoire tampon. Le problème est donc essentiellement lié à la modélisation appropriée du canal et à l'utilisation de ces informations pour régler la latence de lecture initiale. Par simplification, le client considère uniquement le canal envoyé au serveur pour le réglage de la latence.
Les clients Spotify utilisent un modèle markovien pour le débit tel qu’observé par le client (c’est-à-dire affecté par la variation du délai emballé, la perte de paquets et le contrôle de la congestion TCP). Les clients observent le débit atteint lors du téléchargement depuis le serveur afin d'estimer une chaîne de Markov. Seules les données collectées au cours des 15 dernières minutes de téléchargement sont conservées et utilisées. Les états de la chaîne de Markov correspondent au débit en 1 seconde, discrétisé en 33 niveaux distincts compris entre 0 et 153 kbps (plus granulaire aux faibles débits).
Le modèle n'est pas utilisé pour calculer une latence de lecture explicite. Avant que la lecture ne commence, le client utilise régulièrement la chaîne de Markov pour simuler la lecture de la piste, en commençant par la quantité actuelle de données mises en mémoire tampon et le débit de données actuel. Chacune de ces simulations est considérée comme un échec ou un succès, selon qu’il s’agisse ou non d’une sous-exécution. Le client effectue 100 simulations et en cas d'échec de plusieurs d'entre elles, il attend plus longtemps avant de commencer la lecture. Au cours de ces simulations, le client émet l'hypothèse simplificatrice que les données sont consommées à un débit constant en dépit du fait que le codec utilisé a un codage à débit variable.