Rockbox Development > Feature Ideas

Audio book support, Sansa clip style.

<< < (2/3) > >>

illux:
1st post on the forums, woo! (Rockbox is awesome! It gave new life to an old iRiver iHP-140 here)

>shinobi
Re: Bookmarking, I too have been spoiled by the Sansa clip, but it is a fast flash based player, so its bookmarking will be blazingly fast compared to our aincent hard-disk players :)


>torne
Does the bookmarking patch youre developing have a limit on the amount of recursive sub dirs in your /Audiobook or /Podcast tree?  I would only like to create one, once at the folders root.  I also dislike the .bmark files being saved within each sub directory.

I have two other ideas outlined below that are similar, mabey another developer is working on something similar:

1) A bookmark behavour that works like the hidden blank 'database.ignore' file.
If theres a blank file called 'auto.bookmark.yes' in a folder, rockbox will automatically bookmark everything within that folder tree.

2) A 'bookmark.cfg' file in the .rockbox/ directory that defines which folders have auto bookmarks on/off.

(Eventually there would have to be a gui/menu entry written for rockbox to make these types of ideas user-friendly, but it could be implimented manually before any UI menus are developed)

Regarding bookmarking, I personally stopped using auto bookmarks as it was causing extra hard-disk activity when I didnt want it (slowing down navigation), but I disliked the amount of loud clicking on the iriver (3 clicks in total) to save a bookmark. Its not a complaint on the 3 clicks, the UI is fantastic & well laid out, its just that most users need to bookmark in a hurry or if the player is in their pocket.

Scuse the ramble, 1st post, Cheers :)

torne:
It doesn't change how bookmarking works; there is one bookmark file per playlist. How you make that playlist is up to you: if you just play a file in a directory it will only be the files in that directory (the automatically generated dynamic playlist), not any subdirectories. If you create a playlist that contains all your audiobooks, there will be just one bookmark file for the whole thing.

I think the general feeling when this kind of thing has been discussed before is that we don't like the idea of settings being changed based on directory location... doing it the way you suggest would result in an explosion of marker files (how many settings might you want to change per-directory? Lots seem possibly applicable) and would slow things down quite a lot. Just loading a configuration file would be more realistic, but that would still involve seeking up the directory tree to look for it, and not all settings could be supported in this way (many things wouldn't work because once the playlist had been loaded it may be too late).

It comes down to: if you come up with a specific design (or better still, implementation) which doesn't compromise performance, add too much complexity, or behave in an inconsistent way, then it might happen; otherwise, probably not.

One thing you can do right now is to just save the settings you use for audiobooks, and the settings you use for music, as two .cfg files - just choosing the relevant one from the file browser will set those settings.

illux:
Thanks for the speedy reply,
I agree having one cfg file is the best way to go, I wasn't looking to troll regarding performance or the developers reasoning. Bookmarking was one of my main reasons for switching to rockbox + I was just kicking a few ideas about.

Chronon:
I don't think anyone thinks you were trying to troll.  This forum is intended for discussion of feature ideas, so this is all very much on-topic here.

illux:
Ok, thanks Chronon  :) I'm a bit of a noob to these forums

By the way I'm not a 'real coder' myself, I'm used to simple scripting, or writing bits for the web & UI/UX testing, so anything that looks like a config file is usually thrown in my editor.

I was trying to agree with torne about having just one bookmark vs some ideas on config/settings files, not a rewrite of how bookmarks are generated. Emulating the Sansa clips behaviour is difficult to figure out, anybody else got any suggestions/ideas?

It sounds like its tough to get code approved & into the main rockbox releases (which is probably a good thing, being theres so many players supported & they all have different seek/write times and performance limitations)

Navigation

[0] Message Index

[#] Next page

[*] Previous page