parrot: Concurrent playlist queuing causes out-of-order queue

That would be a great idea! In fact, most bots I have used before were really fast at queueing tracks. The one I ran before only downloaded metadata for queueing purposes, and only downloaded the track when playing (in fact, a lot of times it errored out because it wasn’t able to play it).

From a UX perspective, I don’t find being unable to use other queue-based commands as a bad thing if we provide enough feedback to the user

@danrpinho this would block everything, meaning while you queue 100 songs, for about, I don’t know, 2 minutes, you can’t use ANY command, like /queue /np and what not. This is absolutely not great.

@rafaeldamasceno @danrpinho Don’t get me wrong, it’s intended but I agree it’s confusing behaviour.

I can’t think of a simple way to implement this other than creating a queueing system where tracks wait for their turn to be decoded. I think this is actually a cool improvement.

We would need to implement our own queueing system or separate thread that then enqueues it. Seems we are over-engineering it for a not-so-common use case that is not that shocking. In fact, we should probably look into speeding up the enqueueing system itself 😄

I don’t really agree with it being expected behaviour. Visualising this in another way, if I wanted to insert two bags of marbles (playlists) in a tube (the queue) I’d expect that all marbles in the first bag would be inside of the tube before the first marble of the second bag entered. If I wanted to mix the songs in the two playlists, I could use /shuffle to get that effect.

From a UX perspective, I don’t find being unable to use other queue-based commands as a bad thing if we provide enough feedback to the user. A message saying “adding songs to queue” when a playlist past a certain size threshold could be enough in my opinion. Are there any other reasons as to why these commands should be available 100% of the time?