>> If a search-path-type thing was used, wouldn't your playlist change when
>> you
>> added more music by artist Foo?
>
> yes, but that happens with dirplay playlists now anyway. start a
> folder, then connect usb and add/remove files and there is a good
> chance you wont be on the same file you stopped on.

Indeed - but that's a bug, no?

Unsolicited and probably-very-obvious brain dump follows...

Unify the playlist enumerators:
- directory read
- database query
- playlist file read
- the current playlist (i.e. playlist viewer)
- cuesheets?
- any more?

The same enumerators are used when browsing into one of these entities,
integrating the playlist viewer.

Document a playlist enumerator API which is then implemented for each
supported entity.

Common internal playlist format - either as efficient as possible
(playlist_control-style) or semi-standard (extended M3U8-based?) format?

Playlist to allow storage of bookmarks/resume info - would keep things in
sync? Or always use seperate storage to make use of NVRAM easier? Disk
spinups should not be increased over current systems.

Are resume/bookmarks always per-playlist? How aboout podcasts? Should we
incorporate the recently added per-file resume?

pondlife
Received on 2011-03-07