Mopidy: a faixa anterior não funciona com o modo de repetição

Criado em 15 ago. 2018  ·  9Comentários  ·  Fonte: mopidy/mopidy

https://github.com/mopidy/mopidy/blob/2ee130057113d7c0b46e16a0d7c19180614d5bd9/mopidy/core/tracklist.py#L370

É intencional não retornar à faixa anterior quando o modo de repetição está ativado?

C-bug A-core good first issue

Comentários muito úteis

IMO, ter anterior voltar para a faixa reproduzida anteriormente quando aleatório é definido seria o comportamento mais útil. Quando é útil ir para uma faixa aleatória se você pressionar anterior?

Também acho que seria melhor se pressionar próximo depois de pressionar anterior volte para a mesma faixa em que estava antes de pressionar anterior. Este é o modo como o Spotify funciona, ou seja, quando você pressiona shuffle, ele cria uma lista de reprodução embaralhada, e pressionando anterior / próximo apenas salta nesta lista de reprodução.

Todos 9 comentários

Olhando para a (possivelmente desatualizada) tabela de comportamento do MPD , que acredito ser o que tentamos seguir, isso parece errado. Também há testes muito

Existe https://github.com/mopidy/mopidy/pull/1616/files, mas precisa de testes (e talvez um pouco de re-jigging).

Se alguém quiser dar uma olhada nisso de maneira adequada, atualizar a tabela seria um bom primeiro passo que requer um pouco de tempo. Então podemos implementar essa tabela nos testes (https://github.com/mopidy/mopidy/pull/1695).

Fiz uma nova tabela de comportamento do MPD para a ação anterior, com base na versão 0.21.19 do MPD:

repetir | aleatório | solteiro | consumir | c = 1 | c = 2 | c = 3
------ | ------- | ------ | --------- | ------ | --- | ----
T | T | T | T | Rand? | Rand? | Rand?
T | T | T | . | Rand? | Rand? | Rand?
T | T | . | T | Rand? | Rand? | Rand?
T | T | . | . | Rand? | Rand? | Rand?
T | . | T | T | 3 | 1 2
T | . | T | . | 3 | 1 2
T | . | . | T | 3 | 1 2
T | . | . | . | 3 | 1 2
. | T | T | T | 1 2 | 3
. | T | T | . | 1 2 | 3
. | T | . | T | 1 2 | 3
. | T | . | . | 1 2 | 3
. | . | T | T | 1 1 2
. | . | T | . | 1 1 2
. | . | . | T | 1 1 2
. | . | . | . | 1 1 2

Observe que a única diferença da tabela de comportamento MPD anterior
é que quando repetir e aleatório são definidos, as alterações anteriores em uma faixa aleatória.

Incrível! Você se candidataria a um PR que atualizasse o comentário que temos em https://github.com/mopidy/mopidy-mpd/blob/master/mopidy_mpd/protocol/playback.py#L242 -L265?

Nele! :)

Também examinarei a mudança de comportamento no núcleo do Mopidy primeiro,
já que isso não imita o MPD no momento.

Presumindo que a intenção ainda seja imitar o comportamento do MPD?
Como o MPD foi removido do núcleo, as tabelas de comportamento anterior / seguinte também foram removidas dos documentos.

Sugiro que realmente adicionemos as tabelas de comportamento anterior / seguinte a https://github.com/mopidy/mopidy/blob/develop/mopidy/core/tracklist.py#L300 -L349
e tornar este o comportamento de mopidy em anterior / seguinte.
(Os docstrings no Mopidy-MPD estão em conflito com aqueles no ATM do núcleo Mopidy)

Isso é legal? Ou a intenção é permitir que o comportamento de Mopidys se desvie do MPD?

Presumindo que a intenção ainda seja imitar o comportamento do MPD?

Não tivemos essa discussão desde que removemos a extensão mpd.

Mas você está certo, faz mais sentido mover essa documentação para a tracklist. E o comportamento do mpd de "quando repetir e aleatório são definidos, alterações anteriores em uma faixa aleatória" parece mais lógico, então provavelmente queremos isso. Mas ao mudar os outros desvios para seguir o mpd, talvez seja melhor considerar cada um deles. Já que você está olhando para ele, você tem uma lista de quais são os outros desvios?

O comportamento atual do Mopidy diverge bastante do mpd.

  • No mopidy, quando repeat é definido, o anterior permanece na mesma faixa. Onde no mpd eles recuam um (a menos que random seja definido).
  • No mopidy, se consume estiver definido, o anterior permanece na mesma faixa. Onde em mpd consume não tem efeito na função anterior.
  • No mopidy, se random estiver definido, o anterior permanece na mesma faixa. Onde no mpd isso ocorre apenas quando repeat não está definido.
  • No mopidy, a ação anterior nunca termina no final de uma lista de reprodução, onde mpd o faz quando repeat é definido.

E isso é olhando apenas para a ação anterior. Suspeita que o mesmo pode ser verdade para o próximo.

IMO, ter anterior voltar para a faixa reproduzida anteriormente quando aleatório é definido seria o comportamento mais útil. Quando é útil ir para uma faixa aleatória se você pressionar anterior?

Também acho que seria melhor se pressionar próximo depois de pressionar anterior volte para a mesma faixa em que estava antes de pressionar anterior. Este é o modo como o Spotify funciona, ou seja, quando você pressiona shuffle, ele cria uma lista de reprodução embaralhada, e pressionando anterior / próximo apenas salta nesta lista de reprodução.

Também acho que seria melhor se pressionar próximo depois de pressionar anterior volte para a mesma faixa em que estava antes de pressionar anterior. Este é o modo como o Spotify funciona, ou seja, quando você pressiona shuffle, ele cria uma lista de reprodução embaralhada, e pressionando anterior / próximo apenas salta nesta lista de reprodução.

É exatamente assim que o Mopidy se comporta se você simplesmente embaralhar a tracklist. Mas isso não é o mesmo que habilitar o modo de reprodução aleatória.

Acho que o MPD entendeu a distinção certa, mas a maioria dos webclients expõe o modo aleatório em vez de embaralhar, ou pelo menos não torna a distinção óbvia.

O player Spotify não suporta o modo de reprodução aleatória estilo MPD. Que você pode argumentar que é mais simples de entender na maioria dos casos (não todos!), Mas por outro lado é um pouco menos flexível. A filosofia de contexto atual da tracklist deles é muito diferente e vem com seu próprio conjunto de problemas que causam algumas alterações na tracklist realmente confusas, IMO.

Esta página foi útil?
0 / 5 - 0 avaliações