Database capacity?

@mags1230 wrote:


@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 


That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?

They should be able to…Rockbox devs manage it with the same hardware on the Clip+, Clip, and Fuze, after all.

@mags1230 wrote:


@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 


That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?

http://en.wikipedia.org/wiki/Hard_coded

As in, coded directly into the software and requiring a software update to change (as opposed to having a setting that can be changed without recompiling).

@saratoga wrote:


@mags1230 wrote:


@comedie wrote:

no doubt that could be one of the things, but then if not for album art, what is the intent of adding a color screen and making it larger?

I suspect it is simply a hardcoded amount of memory for their internal db structure, and things like long names and taggings deplete it faster. On the face of it, a simple improvement would be to increase the memory allocated to the structure.

 


That could well be one of the factors that prevents the max song limit from being reached.  When the fuze’s db limit was increased from 4,000 to 8,000, the player had to be formatted to be able to reach that limit.  It allowed the database to be rebuilt and to be able to “grow” large enough to accomodate the new size. 

 

What you say a “hardcoded” amount of memory, do you mean that Sandisk’s devs can’t just increase the limit with a firmware revision?


http://en.wikipedia.org/wiki/Hard_coded

 

As in, coded directly into the software and requiring a software update to change (as opposed to having a setting that can be changed without recompiling).

 

 

 

Thanks for the link.  I guess I get the meaning, being a non-programmer, between hardcoded and softcoded.  lol

It seems to me that it’s similiar to the difference between v1 and v2 tags.  The v1 tags have a set amount of space to add info into while the v2 tags have the ability to expand with the addition of more info so there’s room for things like lyrics and embedded album art.

@jk98 wrote:

Album art doesn’t have to be embedded in the tags though.

 

 

In regards to this, would a folder.jpg for each album or embedded art take up more of the database?

Rockbox OS is completely file based.  It has a file structure beneath the .rockbox folder on the player, and as such has the freedom to write the DB to the main memory of the device.  As you database grows, the database file it reads from grows.

As long as you have the storage on the device to hold the database file, then you are good.

It looks as if the database on the original Fuze is held within a specified “reserved” space of memory for the firmware.  As a result, there is a limit to the size of the DB.  

The worst part is that the “folder” navigation offered on the player is not true folder navigation and is actually just folder representations of the DB.  

If the folder navigation were simply navigating the file structure, then I could live without the DB.

Thankfully, I found a workaround.  I found that as long as I don’t modify the date in Rockbox, I can overwrite the bootloader and reload the original firmware, transfer files to rhapsody and reload the bootloader.

It adds approximately an extra 2 minutes of time, but allows me to play subscription content.

Not the best, but once I went to Rockbox, I found the original firmware so limiting.  Playlist creation in Rockbox is so easy, I don’t think I could go back.

I hope Rockbox for the zip comes soon, because I will need a replacement player as soon as the internal batteries of my Fuze run out.

@p_opus wrote:

 

I hope Rockbox for the zip comes soon, because I will need a replacement player as soon as the internal batteries of my Fuze run out.

I’ve been using Rockbox on the Zip since last November. :wink: