我刚刚在听 Spotify，突然我的互联网连接断了。虽然我并不惊讶它仍然播放完了这首歌（由于缓冲），但我曾是当它继续播放下一个节目并持续播放几分钟时（然后我恢复了互联网），我感到很惊讶。
连接丢失后，Spotify 还能继续播放多长时间？假设没有文件“离线启用”。
答案1
分析这项任务可能比仅仅“计时”更困难
Spotify 会缓存之前播放的歌曲，因此如果您的线路断线时其中一首歌曲正在播放，那么该歌曲已经存储在您的设备上，您甚至不会注意到。
至于缓冲区在任何给定时间到底有多大 - 它会自动调整，可以是从 15 秒到整首歌曲，具体取决于其来源、对等点或服务器 [见下文]
我将这些文章列入只是为了进一步阅读——这里的内容太多了，无法概括，但给出了合理简化的解释。
Spotify 入门指南有一篇关于缓存以及如何调整其大小的好文章
Spotify 技术：Spotify 的工作原理有一些关于流媒体技术如何工作的简单信息。
我确实找到了关于这个主题的权威文献，由贡纳尔·克雷茨& 弗雷德里克·尼梅拉 (Fredrik Niemelä)...
Spotify – 大规模、低延迟、P2P 音乐点播流媒体
提炼：
给定曲目可以同时从服务器和多个不同的对等点下载。如果对等点在满足请求方面太慢，则将请求重新发送给另一个对等点，或者，如果获取数据变得太紧急，则发送给服务器。
从服务器流式传输时，如果有对等点可用于该曲目，客户端会限制其请求，使其不会比当前播放点提前超过约 15 秒。从对等网络下载时，不会发生此类限制，客户端会尝试下载整个当前播放的曲目。如果用户更改曲目，则中止与当前曲目相关的请求。对
等网络中提供的文件被分成 16 kB 的块。在确定从哪些对等点请求块时，客户端会根据对等点的预期下载时间（计算为来自对等点的未完成请求的字节数，除以从该对等点收到的平均下载速度）对对等点进行排序，并贪婪地从估计下载时间最短的对等点请求最紧急的块（然后更新预期下载时间）。这意味着按顺序请求轨道的块。由于为文件提供服务的所有对等方都拥有整个文件，因此按顺序请求块不会影响可用性或下载速度。
客户端最多可以收到来自给定对等方的未完成请求，以确认对等方可以在 2 秒内交付数据。例外情况是，始终允许收到来自对等方的 32 kB 未完成请求。如果块的估计下载时间超过了需要该块的时间点，则不会请求该块。…
Spotify 客户端不限制缓冲区大小，因此问题的关键在于对通道进行适当的建模，并使用该信息来调整初始播放延迟。为简化起见，客户端仅考虑到服务器的通道以进行延迟调整。Spotify 客户
端使用马尔可夫模型来计算客户端观察到的吞吐量（即受打包延迟变化、数据包丢失和 TCP 拥塞控制的影响）。客户端观察从服务器下载时实现的吞吐量以估计马尔可夫链。仅保留和使用下载最后 15 分钟内收集的数据。马尔可夫链的状态是 1 秒内的吞吐量，离散化为 0 到 153 kBps 之间的 33 个不同级别（吞吐量较低时更细化）。
该模型不用于计算显式播放延迟。相反，在开始播放之前，客户端会定期使用马尔可夫链来模拟曲目的播放，从当前缓冲数据量和当前数据吞吐量开始。每次模拟都被视为失败或通过，具体取决于是否发生欠载。客户端执行 100 次模拟，如果其中不止一次失败，则等待更长时间才能开始播放。在这些模拟过程中，客户端做出了简化假设，即尽管使用的编解码器具有可变比特率编码，但数据仍以恒定速率消耗。