A third repeat mode that moves tracks to the tail instead of restarting

[freyacodes]

A third repeat mode that moves tracks to the tail instead of restarting

[knight-ryu12]

I'd say, need to make ;;repeat argumented.

[freyacodes]

Yeah, that's what I'm thinking, but what would the usage be like? What do we call modes 2 and 3?

[RealKC]

;;repeat single_track and ;;repeat queue maybe?

[knight-ryu12]

that'd be better.
Just 2,3 toggling is ok

[knight-ryu12]

can you tell us how queue are handled?

[freyacodes]

I could but my classes have just started again. I'll get back to you when I have the time.

…

On 5 January 2017 at 12:05, Chromaryu ***@***.***> wrote: can you tell us how queue is handled? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/Frederikam/FredBoat/issues/42#issuecomment-270619704>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACdoWWCwV076GoABPqecfcDeO112jgn4ks5rPM6NgaJpZM4Lbkly> .

[freyacodes]

How the audio queue works

The queue in FredBoat is partially held in the GuildPlayer and the SimpleTrackProvider. When an AudioTrack is queued, commonly by the AudioLoader, the track is added to the provider's internal ConcurrentLinkedQueue. This queue is completely independent of shuffle. The shuffled list is sorted when it is requested and cached until the provider is modified.

The SimpleTrackProvider's purpose is to provide audio tracks upon request by the GuildPlayer, which keeps the currently playing (or paused) AudioTrack for itself. If the end of a track is reached (eg not stopped/skipped) and the player is in the current repeat mode, the track is simply restarted.

[freyacodes]

What I'm thinking is this:

;;repeat off // Disables repeat
;;repeat single // Repeats a single track until skipped
;;repeat all // Ended tracks are moved back into the queue
;;repeat // Displays usage information

[schnapster]

Why not both?

I understand the two modes not as exclusive.
repeat all boils down to never kicking a song out of the queue, instead putting it back in after it has finished playing.
That's not exclusive to having the first song in front of the queue playing over and over again.

imo solve this by just adding a ;;repeatall command that will cause finished tracks to get added to the back of the queue.

Let me know if my proposal makes sense or you prefer the three-mode thing, so I can implement the preferred solution.

[knight-ryu12]

Hmm.
I'd like to prefer theree-mode

[freyacodes]

@napstr I don't think that is a very intuitive approach. It can be hard for the user to expect what modes are currently active when we don't have some sort of GUI. Why would the user even think there are two settings of repeating to begin with without reading the docs? Moreover, consider why Spotify allows you to switch between these 3 modes with a single button.

[schnapster]

Indeed, my proposal isn't great for user experience.

What is the expected behavior of the skip command in repeat all mode? Should the track be kept in the queue (added to the back of it like unskipped played tracks) or be removed completely out of the queue?

[freyacodes]

If repeat all is enabled, the track would be moved to the tail of the queue.

[Nanabell]

This can be closed. #93 was merged

[freyacodes]

True, thanks for reminding me