Por quanto tempo o spotify continuará jogando após a perda da conexão?

1

Eu estava apenas ouvindo o Spotify, e minha conexão com a internet caiu. Enquanto eu não estava surpreso que ainda completava a música (devido ao buffer), eu estava surpreso quando foi para o próximo e continuei tocando por vários minutos (e então eu consegui internet de volta). / p>

Por quanto tempo o Spotify pode continuar jogando após a perda da conexão? Suponha que nenhum arquivo esteja "habilitado off-line".

    
por Ludwik 06.02.2015 / 23:18

1 resposta

2

A tarefa pode ser mais difícil de analisar do que apenas "tempo"

O Spotify armazenará em cache as músicas reproduzidas anteriormente, portanto, se uma delas estiver em exibição quando a linha estiver inativa, ela já estará no seu dispositivo, e você nem perceberá.

Quanto ao tamanho exato do buffer em um dado momento - ele ajusta automaticamente & pode ser de 15s a uma música inteira, dependendo de sua fonte, ponto ou servidor [veja abaixo]

Eu incluí estes artigos apenas para ler mais - muito para resumir aqui, mas dê explicações razoavelmente simplificadas. Spotify For Dummies tem um bom artigo sobre o cache & como ajustar seu tamanho para Spotify Technology: Como funciona o Spotify tem algumas informações simples sobre como a tecnologia de streaming funciona.

Eu encontrei o documento oficial sobre o assunto, escrito por Gunnar Kreitz & Fredrik Niemelä ...
Spotify - Escala Grande, Latência Baixa, P2P Music-on- Demanda de Streaming

Extrair:

A given track can be simultaneously downloaded from the server and several different peers. If a peer is too slow in satisfying a request, the request is resent to another peer or, if getting the data has become too urgent, to the server.
While streaming from a server, clients throttle their requests such that they do not get more than approximately 15 seconds ahead of the current playback point, if there are peers available for the track. When downloading from the peer-to-peer network, no such throttling occurs and the client attempts to download the entire currently playing track. If a user changes tracks, requests relating to the current track are aborted.
Files served within the peer-to-peer network are split into chunks of 16 kB. When determining which peers to request chunks from, the client sorts peers by their expected download times (computed as the number of bytes of outstanding requests from the peer, divided by the average download speed received from that peer) and greedily requests the most urgent chunk from the peer with the lowest estimated download time (and then updates the expected download times). This means that chunks of a track are requested in sequential order. As all peers serving a file have the entire file, requesting blocks in-order does not affect availability or download speeds.
A client can at most have outstanding requests from a given peer for data it believes the peer can deliver within 2 seconds. An exception to this is that it is always allowed to have requests for 32 kB outstanding from a peer. If the estimated download time for a block exceeds the point in time at which the block is needed, that block is not requested.

Spotify clients do not limit the buffer size, and thus the crux of the problem is the appropriate modeling of the channel and using that information to adjust the initial playback latency. As a simplification, the client only considers the channel to the server for latency adjustment.
Spotify clients use a Markovian model for throughput as observed by the client (i.e., affected by packed delay variation, packet loss, and TCP congestion control). Clients make observations of throughput achieved while it is downloading from the server to estimate a Markov chain. Only data collected during the last 15 minutes of downloading is kept and used. The states of the Markov chain is the throughput during 1 second, discretized to 33 distinct levels between 0 and 153 kBps (more granular at lower throughputs).
The model is not used to compute an explicit playback latency. Instead, before playback has commenced, the client periodically uses the Markov chain to simulate the playback of the track, beginning with the current amount of buffered data, and the current data throughput. Each such simulation is considered as failing or passing, depending on if an underrun occurred or not. The client performs 100 simulations and if more than one of them fails, it waits longer before beginning playback. During these simulations the client makes the simplifying assumption that data is consumed at a constant rate despite the fact that the codec used has a variable bitrate encoding.

    
por 07.02.2015 / 09:15