Задача может быть сложнее для анализа, чем просто "время его"
Spotify будет кэшировать ранее проигранные песни, поэтому, если одна из них воспроизводится, когда ваша линия отключается, она уже на вашем устройстве, так что вы даже не заметите.
Что касается размера буфера в любой момент времени - он автоматически настраивается и может варьироваться от 15 секунд до всей песни, в зависимости от источника, партнера или сервера [см. Ниже]
Я включил эти статьи только для дальнейшего прочтения - слишком много, чтобы привести их здесь, но дать достаточно упрощенные объяснения.
В Spotify For Dummies есть хорошая статья о кеше и о том, как настроить его размер.
Технология Spotify: как работает Spotify, содержит простую информацию о том, как работает потоковая технология.
Я нашел авторитетный документ по этому вопросу, написанный Гуннаром Крайцем и Фредриком Нимеля ...
Spotify - Большой масштаб, низкая задержка, потоковая передача музыки по запросу P2P
Выдержка:
Данный трек может быть одновременно загружен с сервера и нескольких разных пиров. Если одноранговый узел слишком медленно удовлетворяет запрос, запрос повторно отправляется другому одноранговому узлу или, если получение данных стало слишком срочным, серверу.
Во время потоковой передачи с сервера клиенты ограничивают свои запросы так, что они не получают более чем приблизительно на 15 секунд опережающую текущую точку воспроизведения, если для дорожки доступны одноранговые узлы. При загрузке из одноранговой сети такое регулирование не происходит, и клиент пытается загрузить всю воспроизводимую в данный момент дорожку. Если пользователь меняет дорожки, запросы, относящиеся к текущей дорожке, прерываются.
Файлы, обслуживаемые в одноранговой сети, разбиваются на куски размером 16 КБ. При определении, с каких узлов запрашивать чаны, клиент сортирует одноранговые узлы по их ожидаемому времени загрузки (вычисленному как число байтов ожидающих запросов от однорангового узла, разделенное на среднюю скорость загрузки, полученную от этого однорангового узла) и жадно запрашивает самый срочный чанк. от однорангового узла с наименьшим предполагаемым временем загрузки (а затем обновляет ожидаемое время загрузки). Это означает, что порции трека запрашиваются в последовательном порядке. Поскольку все одноранговые узлы, обслуживающие файл, имеют весь файл, запрос блоков по порядку не влияет на доступность или скорость загрузки.
Клиент может получить не более ожидающих запросов от данного однорангового узла о данных, которые, по его мнению, может доставить одноранговый узел в течение 2 секунд. Исключением является то, что всегда разрешено получать запросы на 32 кБ ожидающих от однорангового узла. Если расчетное время загрузки для блока превышает момент времени, в который требуется блок, этот блок не запрашивается.
...
Клиенты Spotify не ограничивают размер буфера, и, следовательно, суть проблемы заключается в соответствующем моделировании канала и использовании этой информации для регулировки начальной задержки воспроизведения. В качестве упрощения клиент рассматривает только канал к серверу для регулировки задержки.
Клиенты Spotify используют марковскую модель пропускной способности, наблюдаемую клиентом (т. Е. На нее влияют изменение запаздывающей задержки, потеря пакетов и управление перегрузкой TCP). Клиенты наблюдают за пропускной способностью, достигнутой при загрузке с сервера, для оценки цепочки Маркова. Сохраняются и используются только данные, собранные за последние 15 минут загрузки. Состояния цепи Маркова - это пропускная способность в течение 1 секунды, дискретизированная до 33 различных уровней от 0 до 153 кБ / с (более детализированная при более низких пропускных способностях).
Модель не используется для вычисления явной задержки воспроизведения. Вместо этого до начала воспроизведения клиент периодически использует цепочку Маркова для имитации воспроизведения дорожки, начиная с текущего объема буферизованных данных и текущей пропускной способности данных. Каждое такое моделирование считается неудачным или проходящим, в зависимости от того, произошло ли опустошение или нет. Клиент выполняет 100 симуляций, и если более одного из них дает сбой, он ждет дольше, прежде чем начать воспроизведение. Во время этих симуляций клиент делает упрощенное предположение, что данные потребляются с постоянной скоростью, несмотря на тот факт, что используемый кодек имеет кодирование с переменным битрейтом.