[garyi]

I love being able to browse for a tune and queue it to play. However I nearly always find myself in the following scenario.

I put my feet up and find something to play, and off it goes then I start searching for my next track and queue it.

How ever it not queued for the next track its actually put at the bottom of the entire Album that my initial choice is in. So basically to get the track I want on next I have to remove the rest of the first songs album from the playlist.

Is there anyway to prevent this from happening. i.e. for xbmc to understand that if I have queued and item to assume I want that item to be played next?

Hope this makes sense. There is nothing on it in the online manual.

[Haggy]

Hmm. So you chose an entire album to be included into the playlist, then select a single item after and you want that item to be inserted just after the song that's currently playing, right? Don't think it's possible at the moment - and what to do if nothing plays currently?

[spiff]

running in party mode will accomplish what you want, not a pretty solution though

[Maxim]

It doesn't seem like typical queuing behavior. I've not seen a player that does this when adding items to any playlist. It might seem plausible to add an option like an entry on the context menu, to "Add after current track." You could open a trac ticket and the devs can discuess it.

But regardless, spiff says party mode does this, I haven't used it so i'm not sure, it might be just as easy.

[jmarshall]

It's perfectly sane, logical behaviour. You have "Autoplay next file" turned on, so when you play a file, it'll automatically queue up all the files in the folder.

Are you saying that we should wipe this out if you queue something else? At which point should this be done? What if a new song in the auto-play list starts playing - should it queue always after that song? Do we then throw away the rest of the auto-queued songs? What if playback starts by playing a folder (which essentially does the same thing) rather than playing a specific song - does the behaviour now change?

As you can see, if you start messing with this, logic goes out the window

Instead, we keep things simple: Queuing a file ALWAYS adds it to the end of the list. Makes perfect sense to me.

If you don't want "Autoplay next file" to kick in, then start music by QUEUING the first track will do the trick.

I've said it before: Come up with a sane, logical alternative, and it will certainly be explored.

Cheers,
Jonathan

[garyi]

Hi Jonathan, your post has an underlying derivative nature which is unpleasant.

Allow me to explain again.

In my common screnario I have picked a song just to get me listening to something. Lets say track 1 of Damaged by Lambchop, 'Paperback Bible.'

So thats playing. Nice. Now I want something from pinkfloyd next so I pick 'Two Suns' from Final cut to play next.

Now when I started out I simply picked a track. Track one of Lambchop. This was not a playlist it was an album that I scrolled too.

To my mind if I have hit 'Two Suns' and queued it then I want it to play after 'Paperback bible' finishes. But it does not it wants to play the entirety of the the lambchop album before playing Two Suns.

More over the behaviour of the queue behaves exactly as I would expect after this initial mishap. All items I queue are played in order one after the other. Just like I wanted in the first place.

In conclusion then I never added the entire lambchop album to a playlist, I simply started playing a song from it before queuing items.

FWIW no music player I have come across seems to understand this simple premise, I want to pick songs on the fly. Even itunes and its on the fly selection still requires the user the create a playlist before beginning. But it does not always work that way. For instance I might think I want to hear an entire album of some such but then decide half way through a song that the next song I want to hear is from another album. The QUEUE feature would on the surface appear perfect only its not because unless you start out in a playlist it will want to include all tracks after the currently playing the album before you can add to it.

[jmarshall]

It wants to play the entire album, as that is what you asked it to do: you have "Auto play next item" turned on. Turn off "Auto play next item" if you don't want it to play them next. The main problem here is not the behaviour, it's the fact that you can't explicitly see the behaviour in action. I'm sure if you could see the playqueue when you played that first track, you'd find the behaviour quite understandable.

I presume what it is that you want is something like:

"Autoplay the next item if I haven't already queued up anything else".

This has problems, however. If you do happen to queue something else up, what should happen when that song finishes? Should it go back to what it was auto-playing, or should it start autoplaying from the track that you queued up? What if you queued up a whole album or folder? Should it just stop in that case?

The behaviour needs to be well-defined in all cases. Once that's done, I'm sure someone will be more than happy to code it up, assuming that it's a better system than we have now ofcourse!

In the meantime, just queue your first track instead of playing it.

Cheers,
Jonathan

[anderswh]

I don't know much about programming so I can't comment on the possibility of acutaly coding this function into XBMC. However I do not understand the claims that a "que as next item" function would compromise the logic of a playlist.
The problem as I unerstand it is this:
One listens to a playlist, never mind how it is created. Then one wants to listen to a particular song not on the playlist, but dosent want to wait until the end of the playlist for it to come along. Thus one wants to add this song as the next item to play in the playlist, but not altering the playlist in any other way.
This is a perfectly normal function to have in a mediaplayer.
As to the question "What hapens when the song finishes?" its answer is perfectly logical: The mediaplayer simply continues down the playlist to the next item that was originaly queued up.

[jmarshall]

As to the question "What hapens when the song finishes?" its answer is perfectly logical: The mediaplayer simply continues down the playlist to the next item that was originaly queued up.

Yes, that is logical. The point, however is that the "auto play next item" function queues up as well. Consider the following scenario:

1. User starts playing song1. XBMC by default will auto-queue up the rest of the songs in this album/folder/playlist.
2. User selects song2 to queue. As suggested by the original poster, the user wishes this to actually be played next, instead of the auto-queued items.
3. No other songs are queued by the user.

Clearly what should happen is:

Song1 plays through to the end. Song2 then should start playing.

What's not so clear is what should happen when Song2 completes.

Options are:
1. Playback stops. The logic here would be that user-queued songs wipe out auto-queued songs in the now playing list.
2. Playback reverts to the previous auto-queued songs. The logic here is that the auto-queued songs are not cleared, but all that happens is that user-queued songs are prioritized (i.e. insert user-queued items before any auto-queued items).
3. Playback starts continuing on from Song2. The logic here is that the auto-queued songs should always continue on from the last song played.

Cheers,
Jonathan

[2005george]

I don't know much about programming so I can't comment on the possibility of acutaly coding this function into XBMC. However I do not understand the claims that a "que as next item" function would compromise the logic of a playlist.
The problem as I unerstand it is this:
One listens to a playlist, never mind how it is created. Then one wants to listen to a particular song not on the playlist, but dosent want to wait until the end of the playlist for it to come along. Thus one wants to add this song as the next item to play in the playlist, but not altering the playlist in any other way.
This is a perfectly normal function to have in a mediaplayer.
As to the question "What hapens when the song finishes?" its answer is perfectly logical: The mediaplayer simply continues down the playlist to the next item that was originaly queued up.

Once again, the old files/playlist queueing system did this perfectly. How many 1000s of complaints will there be until the devs understand the move to 'Now Playing' instead of the playlist was a bad choice. To be honest, 'Now Playing' is useless and redundant.

In the old system, you could play any song you wanted, it did nothing to the playlist. I could browse my collection, sample any song I wanted, play it, play the next, etc. My playlist (toggled with the black button on a controller), was not affected. When I decided I wanted to queue something, I could do just that, queue a single song (or album). I was now creating a playlist. I could flip back and forth with black and look at the playlist anytime, or even play songs from it. If I toggled back to the files mode, I could then switch to playing a song there, and again, my playlist stayed perfectly intact. The old system was FAR more untuitive. If you put anyone in front of XBMC that isn't very familiar with it they will delete a playlist by mistake, _everyone_ that I have ever introduced XBMC has commented on that. The people that used the old system have commented and wondered why they changed it to such a weird system now. Why is that so difficult to understand? And don't even bring up the playlist editor, it is so inferior in every way to the main browsing system that it isn't even considered.

[snoxbox]

Once again, the old files/playlist queueing system did this perfectly. How many 1000s of complaints will there be until the devs understand the move to 'Now Playing' instead of the playlist was a bad choice. To be honest, 'Now Playing' is useless and redundant.

I agree with everything you have said, however I don't think the move to the 'Now Playing' playlist was simply for usability. If I recall the discussions at the time, the code for this was really messy, and was causing issues.

I also really dislike playlist management now, but I think the dev's had their reasons for implementing it.

[jmarshall]

@2005george: The new system is clearly not perfect. So far I have yet to hear a decent solution that addresses all concerns. Until I do, nothing will change. You can help by responding to my questions rather than parroting the same tired rant over and over.

Help make the new system better, or your posts will be ignored.

Cheers,
Jonathan

[2005george]

@2005george: The new system is clearly not perfect. So far I have yet to hear a decent solution that addresses all concerns. Until I do, nothing will change. You can help by responding to my questions rather than parroting the same tired rant over and over.

Help make the new system better, or your posts will be ignored.

Cheers,
Jonathan

Jonathan: My opinion is shared by many others, the old system _was_ ideal, and far, far better than what we have now. I don't see any way the old system could be improved so what would you like me to say? This is what I believe would make audio playlists better.

[jmarshall]

I'd like you to answer the questions I pose. Since you love the old system so much, how about you try it out and tell me what the answers are? You claim it's ideal. Prove it.

Cheers,
Jonathan

[DarkHelmet]

Yes, that is logical. The point, however is that the "auto play next item" function queues up as well. Consider the following scenario:

1. User starts playing song1. XBMC by default will auto-queue up the rest of the songs in this album/folder/playlist.
2. User selects song2 to queue. As suggested by the original poster, the user wishes this to actually be played next, instead of the auto-queued items.
3. No other songs are queued by the user.

Clearly what should happen is:

Song1 plays through to the end. Song2 then should start playing.

What's not so clear is what should happen when Song2 completes.

Options are:
1. Playback stops. The logic here would be that user-queued songs wipe out auto-queued songs in the now playing list.
2. Playback reverts to the previous auto-queued songs. The logic here is that the auto-queued songs are not cleared, but all that happens is that user-queued songs are prioritized (i.e. insert user-queued items before any auto-queued items).
3. Playback starts continuing on from Song2. The logic here is that the auto-queued songs should always continue on from the last song played.

Cheers,
Jonathan

I have to admit that I don't quite understand the difference between 2. and 3.

Here's what I would think should happen, if an "queue song after current" option would be implemented:

These are the songs currently in the now playing list:
Song 1 (currently playing)
Song 2
Song 3
Song 4
Song 5

Now I want to add "song A" to the list using "queue after current". This is what the now playing list should look like then:

Song 1
Song A
Song 2
Song 3
Song 4
Song 5

After Song A finishes it should continue to play song 2, then song 3 and so on.

Another situation where "queue after current" comes in handy is if you are in playlist view of the now playing list and you have a long list of songs (100+ songs). Now I might want to change the position of a song which is some songs down in the list. I want to hear that song next. Right now I have to pick that song, hit "move song", find the currently playing song in the list by scrolling through the list (which can be quite time consuming in a long list of songs) and then hit "insert here". This would be much easier if another option could be included "move after current".

I'm using the German translation so it could be that I' not using the right words. Right now in the playlist view of the now playing list there are these options:
show title information
add to favourites
up
down
move

Here I'd like to have the option "move after current", which would move the song to the position after the song that's currently playing. This would just be shortcut for something that can already be done by manually "moving" the song.