>> 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
