> The memory issue is all to do with keeping the disk spun down - we mlock into > memory so that unix doesn't try and access the disk when we're not
> expecting it.

Yeah, for the implementation I described to work, you'd have to reduce the
amount of memory used for caching stuff. You'd probably also have to
impose limits on the size in memory of the "next track" executables.

> the playlist is generated and saved when the playlist is
> selected. We need to look further ahead than the next tune in order for the
> caching to work properly, and to ensure that playlists carry on properly after
> power off/on again.

The problems this generates for my suggested implementation include:
-1 A playmode could generate a playlist of infinite length
-2 It could take a significant amount of time to generate the internal playlist

Both of these can be solved in a reasonably straightforward manner, but I
can't know the complexity of their implementation within the current
player framework.

You only need to know the very first track to start playing music.
Calculation of the rest of the playlist can be done while playing.
This takes care of problem 2 above.

The problem of an infinite length playlist is a little trickier.
You could always implement a sort of sliding window around the current
track, but that would impose a limit on the number of "previous track"
commands you can execute. I wouldn't see this as a huge problem.

In this case, you would just use the "next track" executable to generate
your internal playlist of finite length. When you were approaching the
end of it, you could generate another internal playlist.

This addresses problem 1 above, but it's a bit of kludge, I guess.

Are there other problems I've missed?

Richard.