In other words, basically the same as the original firmware. I'm not sure how else it could be done.

Sorry, I hadn't tried the OF so I didn't know how it worked.

Eventually I want to add an option to merge the two file systems together recursively, but its fairly complex to do it. XBMC has code for doing it (which works awesome by the way), but given how deep within the guts of code the file system is, its not so easy to merge in new things. Plus I don't know much about file systems, so i'm kind of hoping someone else does it first.

In other words, basically the same as the original firmware. I'm not sure how else it could be done.

Except it's not really. The 'folder browsing' in the original firmware is fake. It still uses the database which accounts for the requirement of the tedious database building each time you touch the filesystem.

In Rockbox the database is not enabled by default and you can use the filesystem for real.

Except it's not really. The 'folder browsing' in the original firmware is fake. It still uses the database which accounts for the requirement of the tedious database building each time you touch the filesystem.

Sorry, but I don't really believe you. Got any proof?

The database is built to provide access by artist name, song title, genre, etc.

The database is built to provide access by artist name, song title, genre, etc.

Steve

I wouldn't say folder browsing in the OF is fake but it's not anything like folder browsing in Rockbox. The OF folders are based on the tags it reads from music files it recognizes. Folder browsing in Rockbox is a complete folder/file browser. Any file that's on the player is visible, not just music files and folders.

That's part of how make use of Rockbox features. You can actually see and manipulate files and directories that can't be seen at all in the OF.

That's part of how make use of Rockbox features. You can actually see and manipulate files and directories that can't be seen at all in the OF.

OK, but in Rockbox, you can do something with those files. In the OF, there's nothing you can do with them, so why show them? This could be considered intelligent programming by Sansa. 99% of Clip users (me included) don't want to see files that they can't play.

Quote:

Originally Posted by skip252

I wouldn't say folder browsing in the OF is fake but it's not anything like folder browsing in Rockbox.

OK, but to some degree that's just the way it's been programmed by the two different groups. I need to see the Rockbox display, but really I suspect that both are "right".

Quote:

Originally Posted by skip252

The OF folders are based on the tags it reads from music files it recognizes.

I don't believe that they are based on the tags. Perhaps it builds a folder structure in the database while reading the tags to build the tag database.

But this is a programming detail. How do you know that there is a stored structure, or that the structure is read when needed? And really, it doesn't matter to 99% of users.

OK, but in Rockbox, you can do something with those files. In the OF, there's nothing you can do with them, so why show them? This could be considered intelligent programming by Sansa. 99% of Clip users (me included) don't want to see files that they can't play.

I do because it can help alert me to the presence of crap on the filesystems that I need to clean off to make room for more music.

Quote:

OK, but to some degree that's just the way it's been programmed by the two different groups. I need to see the Rockbox display, but really I suspect that both are "right".

That's one way to look at it.

You can 1) stick with the OF if you like it, or 2) hack up Rockbox to work how you want it to.

Steve, you win. I don't use the OF enough for it to be a genuine concern plus I think your point is valid. Each file browser is appropriate for the firmware and clientele it services. Also I don't know enough about how the OF folder browser decides what to display to make a good case one way or the other. As long as it works for those who use it, that's what's important.

Letting some people see files they don't need to play the music would no doubt lead to silly things happening and a higher return rate. Seeing more directories and files files in Rockbox is a necessity due to it's extended capabilities. Once again, different environments and uses, different file/folder views.

I'm one of those that happen to think the OF is usable for most things. I don't need or want geek extreme control over every aspect of just getting some tunes rolling. I enjoy what Rockbox brings but big part of that is how it lets me automate multiple aspects of my listening experience.

I change headphones and external memory a lot and being able to switch my setup by simply playing a premade .cfg file makes that really easy. I'm guessing most people don't need that type flexibility. That doesn't mean we don't both enjoy our music equally, we just go about it differently.

There is one feature of Rockbox that interests me (but isn't essential), and one bug of the Clip Zip that Rockbox fixes. Do I really want to go thru the Rockbox learning curve? No matter how steep or shallow? So far, my answer is no.

Did you actually ever give Rockbox a try, at least for more than a few minutes?

Nope, and yes I need to do that. But then I'm set in my ways (lazy) when it comes to stuff like this. I used to have to learn new programs in order to fix them and/or teach users & programmers. So now, there's a bit of a negative attached in my mind to something new.

Changed the first letter of the folder of some files in this file and tried to play them using the original firmware (OF) through the folder browsing option. The original firmware skipped the files for which i had modified the folder name.

To me, that's proof the OF's folder browsing uses the database and not the filesystem like Rockbox does.

I checked the "Debug (Keep Out!)" item for info on the database status, but it seems to return a false negative.

I can tell that a DB update is in progress when I tell it to "Update Now", by noticing slightly more activity from the "disk" icon, and from the fact that some time later, when I restart the player, the 9-part database commit has to run.

But what I'd really like is just a simple counter that increments with every file scanned, or a timer that tells how long the database update (or track scan process) has been running.

N.B. that part of my trouble might be that I'm adding tracks in small batches to a disk with ~10,000 files already on it. So I appreciate that there may be some overhead going on here, as well as the potential for redundant scanning of a lot of already-scanned tracks.

Any advice would be appreciated. (Maybe what I really want is an option in the file browser--"scan THIS DIRECTORY, RIGHT HERE, NOW".)

I never use the "update now" for the database.....if I add something to it, I "initialize database". Never have to deal with that database commit you speak of. Then again, I don't have 10,000 files on my Zip.....even the one with the 32GB card!