Rockbox

Well, the general idea of the sleep timer is to shut the box off after you've gone to sleep, so you shouldn't be hearing it when it ends... Though I could imagine maybe "Sleep at end of last song" instead of at the exact time, but setting just a number of songs since you can then just have a playlist, after which playback stops and then the idle time power off kicks in.

Yes, but sometimes you fall sleep later than expected :)
I like the "Sleep at end of last song" option that you mention but it could expand the time too much. Maybe it'd be better something like "Wait song to finish before sleep". With this option we could solve what I'm saying: The sleep time would be still specified in minutes but when it would reach 0 it could wait for the current song to finish before turning off the unit.

That's what I meant by "Sleep at the end of last song." :)

Cool!

An altogether different approach to this problem might be accomplished by adding an option to the long-click of a certain song on "current playlist":
"Stop after this song".
I tend to slowly crawl through loooooong playlists consisting of various assortments of my entire collection on random, so waiting for the playlist to end (or counting on it ending in some finite time) is kinda out of the question.

I'm still not a fan of the "please code around my listening habits" argument. What precisely stops you from creating a limited length playlist?

If you want to do a random playlist of all your songs, and you're happy browsing to a certain song and choosing "stop at this song" why not browse to the end of the playlist, go back 20 songs, and start there? Then you get 20 randomized songs from the whole selection, and then the playlist ends. In practical terms, you're performing the about same amount of actions (scrolling up 20 songs from the beginning, instead of down, plus less clicks to start playing there than to select a menu option to stop at), you get the exact same effective end, and once again you don't need new code.

Also i'd like to add:
the two previous feature requests for "sleep after N" were closed because people simply said "why not use an N-length playlist?" (see my reasons above) or "why is sleep-after-time insufficient?"...
I believe it is.
Nothing is quite as jarring as the song suddenly cutting out in the middle since it has run out of time. If I'm reallllly trying to go to sleep (and will almost never really fall asleep while the music is still playing) the most i can hope for is that it will get me really relaxed, sometimes half asleep if i'm lucky. a hard-cutoff (or even a standard stop/fadeout) at that point will be enough to jar me out of it. It seems that either allowing the song to end, or very slowly fading out would be preferable, and it would be reasonable to at least allow for either of these.

And you've completely ignored my response above which denotes a way to achieve an n-length number of songs to play after, meets your requirements of shuffledness (or rather, no custom playlist design), and allows it to fade/stop at the end.

you're kindof making an assumption that since i'm listening to a long playlist, then there's no reason for me to skip order and go right to the end. my example is of me listening to a random one, but at the moment i'm about 1200 songs in out of 3000; i have logging enabled for last.fm use, and don't really feel like skipping to the end (and later perhaps having to reshuffle) to get it to stop after so many tracks. but there are probably better examples of long playlists (like, a ten-album-long queue that someone is slowly progressing through), and probably also other (better) examples of why a "stop after this track" would be useful. It's something I've wished Winamp to have for years now; the best they can do is ctrl-V which stops after the current song (only) is done, which I use rather constantly.

you wrote:
And you've completely ignored my response


patience, hehe.. i hadn't seen your reply when i wrote my addition.

I still see this feature as an "I don't want to make use of what playlisting actually does."

If your songs are shuffled, what's the point of LAST.FM logging them, at all really? Just take that playlist, break it into average use per day segments (say 8 hours, or 4 hours, or whatever) and have an automated script submit it to last.fm.

I know that's a bit absolute, but I just don't see last.fm as an excuse not to go to the end of a playlist.

For the person listening to a progression of albums, they can very easily only queue up the next album, so that it stops after that.

I'm not _firmly_ against this option, I just see it as overengineering to solve a problem that doesn't actually exist, except in the minds of people who want to make it exist because they're unwilling to simply use a playlist.

your last.fm workaround sounds like more work than actually implementing this patch, hehe...
i bother with it because my iriver is not my only music source (also use winamp, generally listening to whole albums), and don't always get all the way through a long random playlist before something happens to it, or more stuff is added, or i queue songs i want to hear, etc.. thus i just let it log everything... but we digress, this was only one thing in many that's a consideration, not really trying to use it as an 'excuse' per se.

my 'progression of albums' example (and i think it's a pretty reasonable case?) is someone who has inserted 10 or 20 albums, and doesn't feel like messing with that simply to have the player auto-shutdown after such-and-such song or CD. you seem to say "what playlisting actually does" as if the correct way to use a playlist is the one you describe, eh? not that it's incorrect, but i thought one of the neat things about rockbox was that it allows its features to be used in various combinations to do things individual users want, often in new or unexpected ways. either of the features suggested in this conversation would seem to free the user of being forced to do things "THIS" way, and allow them to proceed uninterrupted in using rockbox how they see fit.

Yes, but one allows them to get the results without new code, and the other one takes away a piece of *my* audio buffer, so that you have a second way of getting the exact same result.

That's the problem: Every new feature slightly increases the binary size, costing everyone a tiny but non-zero piece of their audio buffer. On some players this is more significant than others. On other players there's a limited binary size due to other reasons (actually several levels of limited binary size, one we're already larger than.)

This is why I argue against new "features" that don't actually add the ability to do anything new. All this does is allow a user to bypass what is already a fairly small amount of work (setting up a playlist with the intent for it to end after they've gone to sleep, or skipping to a part in the existing one).

You're basically saying "The convenience of a few users, so that they have to take a couple less steps to achieve the exact same ends, is more important than getting ROMbox working again for Archos users, or keeping the binary size trim to allow for the maximum amount of audio buffer."

This isn't a new feature, from a "what you can do" perspective, it's just a second way to do something that already exists, and that's why I'm against it. It adds code without adding to what Rockbox can actually do.

While I agree with Llorean that there already exists a way to do this, I still think that "sleep after X songs" is a way simpler and more intuitive way of doing it. If you're already listening to a huge playlist you have created, just setting it to sleep after X songs is much simpler than having to sit down and create new playlist. Especially since you will have the huge agony of trying to decide what songs to include in this special playlist. :-)

I believe we have another feature request for being able to insert a "stop here" entry to the playlist. This would solve this issue quite nicely, because after stopping idle poweroff kicks in (well, it will wait for the idle time like chosen by the user, but it will shut down and simply staying in an idle state doesn't eat much battery at all).

Having that said I think a "sleep after N tracks" setting is superfluous, just add the ability to add a stop mark to the playlist (possibly similar to the Insert and Queue functions -- one way to preserve the mark, another way to automatically remove it once it's used). The difference to "sleep after N tracks" is minimal and it also solves other issues (unlike the N tracks variant)

I like the idea of a sleep setting that once it hits 0 still waits until the end of the current song. It's very elegant - a nice little touch, the sort of feature people would brag about if it were built into an ipod.

Its other advantage is that you don't need to add new features (creating feature bloat) or worry about new key combos. It just has to be a setting somewhere in the menu. You change it once, if that's what you're looking for, and it's done.

Personally I think that the "stop here" playlist entry is not as good... what when you're listening in shuffle mode?
Then, "sleep after N tracks" is not so superfluous when you already have a "sleep after N minutes" setting... It could be just another way of using the sleep function...

When you're listening in shuffle mode, if you view the playlist, you'll see the playlist as shuffled. This means you still see the order they will be played in. So I don't understand your objection.