more than 10 "recent bookmarks" possible?

[scott082565]

does anyone know if this is possible? searched the forum, could not find an answer.

i am using rockbox on a Sansa Clip Zip, thanks.

[nick_p]

It looks like it's hard-coded;

http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/bookmark.c;hb=HEAD#l46

Unless I'm wrong, you'd have to change this define and recompile.

[TAC109]

It's an arbitrary, hard coded limit, probably for historic reasons. There is no reason why it can't be set to a larger number in the code, such as 100.

[scott082565]

does hard coded mean i can't change it myself? or can i poke around the install and rockbox files and change?

[nick_p]

You can change it yourself, but it's going to mean recompiling Rockbox. Depending on your experience, this might mean quite a lot of effort.

http://www.rockbox.org/wiki/DevelopmentGuide

[__builtin]

Just change line 46 of http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/bookmark.c;hb=HEAD#l46 to read

Code: [Select]

#define MAX_BOOKMARKS 100

... or any other number you want, and (re)-compile+install.

[[Saint]]

If I put on my speculation hat (as I'm not particularly interested in testing the exact limitations here), I would posit that at some point you're going to flood a stack if you increase this number to a ridiculous level.


[Saint]

[fredex]

Saint would know a lot more than I, as I'm not a RB developer, but I AM a C programmer:

static char global_read_buffer[MAX_BOOKMARK_SIZE];
static char global_bookmark[MAX_BOOKMARK_SIZE];

these are the only two items in the file nick_p mentions that allocate space based on MAX_BOOKMARK_SIZE.

these two items don't go on the stack (or at least for a "normal" C compiler they don't, I'll assume the one used in RB follows that convention) since they are file-scoped static variables. they probably end up somewhere in the heap. therefore they shouldn't cause any problems with the stack (except: if the stack grows so large--from other causes-- that it collides with the heap, then you're in a world of hurt, so putting two larger arrays on the heap could make that collision more likely, given the fixed, small amounts of RAM these embedded systems contain.)

[gevaerts]

Saint would know a lot more than I, as I'm not a RB developer, but I AM a C programmer:

Saint isn't :)

static char global_read_buffer[MAX_BOOKMARK_SIZE];
static char global_bookmark[MAX_BOOKMARK_SIZE];

these are the only two items in the file nick_p mentions that allocate space based on MAX_BOOKMARK_SIZE.

these two items don't go on the stack (or at least for a "normal" C compiler they don't, I'll assume the one used in RB follows that convention) since they are file-scoped static variables. they probably end up somewhere in the heap. therefore they shouldn't cause any problems with the stack (except: if the stack grows so large--from other causes-- that it collides with the heap, then you're in a world of hurt, so putting two larger arrays on the heap could make that collision more likely, given the fixed, small amounts of RAM these embedded systems contain.)

There's also MAX_BOOKMARKS, but at first sight the same applies and I'm fairly sure your analysis is correct.

There's no stack/heap collision as such to fear for. Both these arrays and the stacks are allocated statically and have a fixed size. There's a regular check for stack overflow (every tick) using a sentinel value at the bottom of the stack.

Of course, there *is* such a thing as using so much memory there isn't enough left to buffer audio, but you're going to have to go for fairly insane values here to get to that point on most devices.

[TAC109]

The only place MAX_BOOKMARKS is used is when adding a new bookmark to the bookmark file. In this process, the file is copied to a temp file, stopping when MAX_BOOKMARKS number of records have been copied, then the original bookmark file is deleted and the temp file renamed to the original bookmark file name.

There is no impact on stack or memory, only on disk storage space. And frankly, limiting the file to 10 entries of a maximum size of 350 bytes in these days of gigabyte drives is ridiculous.

[saratoga]

There is no impact on stack or memory, only on disk storage space. And frankly, limiting the file to 10 entries of a maximum size of 350 bytes in these days of gigabyte drives is ridiculous.

Hard disk space isn't important.  Its RAM that limits you.  Some SWCODEC targets have only 2MBs, while very popular ones like the Clip+ have just 8 MB. 

[TAC109]

There is no impact on stack or memory, only on disk storage space. And frankly, limiting the file to 10 entries of a maximum size of 350 bytes in these days of gigabyte drives is ridiculous.

Hard disk space isn't important.  Its RAM that limits you.  Some SWCODEC targets have only 2MBs, while very popular ones like the Clip+ have just 8 MB.

No limits in this case. The records are copied one record at a time. As I said, no impact on stack or memory (=RAM). My unsupported build 2.5.1 for the Archos Recorder (2MB RAM) has MAX_BOOKMARKS set to 100 without any adverse effects.

[gevaerts]

I think that if you're going to increase this, it has to be a setting. I for one don't actually want a long list of recent bookmarks.

[TAC109]

I think that if you're going to increase this, it has to be a setting. I for one don't actually want a long list of recent bookmarks.

New (and replaced) bookmarks are placed at the start of the file and will show in the user interface on the first page(s). You could simply ignore any subsequent pages.