On 7 March 2011 19:18, pondlife <pondl...@pondlife.me> wrote: >>> 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?
I could very easily argue both sides of that. Lets think of it like this. You are unlikely to add/remove files in /Music/Some Artist/Some Album/ right? so the same for the database (i.e we can ignore that entirely for the discussion). You would likely add/remove tracks if your common usage is "shuffle all tracks by Artist" or "anything of genre Foo". now in those cases when would you really ever care if the files changed between uses (remembering that you have to manually change the files (i.e with usb)). Surely in those cases you are in a "I just want to listen to this music, immerse my ears" mood? > > 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? > Cant disagree with anything there. if rockbox is playing music it should be consistant no matter how the music was started > Are resume/bookmarks always per-playlist? How aboout podcasts? Should we > incorporate the recently added per-file resume? > > This is part of the current problem. I have no problem with people logically grouping podcasts differently to actual music. I do however have big problems with random_music_file.mp3 not being able to do everything that some_otherfile.mp3 cant.
