09-13-2011 02:56 PM
It's based on how it is stored on your device. The database starts at your tree and works down.
For example, I can see immediately where it stopped because the last "folder" shown in folder navigation is "rock albums" and the last band showing is U2. Therefore, I can see that's exactly where the database stopped. Any files located in my file structure past Rock Albums/U2 is invisible.
My entire "seasonal music" or "world music" folder is gone and no songs in those folders are navigatable.
09-14-2011 07:47 AM
Yep,,,, personally I was running into trouble at about 3500-4000 songs on my 8GB clip+ with a 16GB micro SDHC in it. The internal database restriction, and some sensitivity to tags, has been my main problem.
So far as DRM content, I have been using Audials to cleanse my songs. It works as good as my 50 year old ears can detect.
I work in db for a living. I've touble understanding why Sandisk seems to have this longterm restriction. When memory was expensive, perhaps you could understand. But today memory is cheap, and the market for MP3's certainly expects more capacity. You'd think it is high time to extend/rewrite that db mgmt support for their players.
09-14-2011 08:50 AM
So would you be able to see more of your collection if you simplified it to just artist folders, like this?
I've never bothered with genre sorting for my file structure, whether on my hard drive or my players.
iPod Touch 5G 32GB, Touch 4G 32GB, Clip Sport 8GB.
Rockbox-> Clip Zip 4GB, iPod Nano 2G 4GB, iPod 5.5G 80GB
2012 Nexus 7 32GB, Asus MeMoPad 8 16+64GB, LG Optimus G Pro, Nokia Lumia 900, Nokia Lumia 520
09-14-2011 09:16 AM
That's pretty much how my folders are. Folder per artist, then a subfolder per album. Suspect it is the tags and name length, both inherited from the sources, that bites me most.
....but,,, the core of the issue is the capacity of the DB structures they are using within. No doubt designed/implemented when memory was more precious and a couple thousand songs on a player was considered bleeding edge.
A cobbled together path could even be something like a huffman conpress/decompress on the tag data internally. Since it is mostly text, that would compress htings pretty nicely with a static compression dictionary. Would mean no change to the underlying DB structures, but would eat some CPU cycles.
09-14-2011 11:13 AM
I read somewhere(perhaps the Anythingbutipod website?) that embedded album art is likely what is causing some to have only a maximum of around 3500-5000 songs that the player can navigate to.
09-14-2011 03:53 PM
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.
09-14-2011 04:22 PM
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?