Click in the nick column to highlight everything a person has said.
The icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

I'd like to do this because I have a lot of different artists because of large compilations. Thus I'd like to browse only the artists for which I have an album (the ones in the Album Artist list), but then I'd like the list of their songs to include the ones which are on compilations CS =)

hmmm.... now I think I remember. The builld dir was very old and possibly untouched since before putting the target config files in a subdirectory and that change wasn't caught by "make clean". Sorry for the noise :)

I would love to combine srt's so that only the difficult words are in Dutch and the easy conversations in shows are subbed only in English. And as srt are plain text that is something that i can do. I can't go into the kids house and force them to watch Star Trek's Picard with english subs but I can enhance their request for Katy Perry with some properly pronounced English for when they are bored :-)

that's interesting, and opens a parallel question: Is the incidence of user-renaming w/o touching the FAT for some other reason common enough to worry about addressing that possibility when the disc scan could be saved (or at least done when actually needed) in (what I can only assume is) the vast majority of cases?

Can we make dircache a little less aggressive, making it only remember directory entries that are opened during normal operation anyway, instead of actively scanning? or would that defeat the whole purpose of dircache?

Could the dircache scan optimise for seek times? i.e. could it order the list of directories it has to scan (but already knows about, obviously) by proximity to current disk location? Or does it already do such things?

It might speed up the scan a bit, but it won't actually fix the real issue, which is that (people report that) during the scan nothing really works properly. It doesn't really matter if the scan takes 8 minutes or 4 minutes

Yes, I've never had issues, but I've never had a ton of files either. The first time I recall these problems starting to pop up was when Rockbox started supporting all the chip tune formats and people seemed to have /thousands/ of little files in their directories.

Writing with 512 byte buffer is where things are becoming nasty: As the ata driver cannot know whether another 512 byte sector will follow, it reads 1024 bytes, modifies one half, then writes those 1024 bytes back. The disk firmware doesn't expect two subsequent accesses to the same sector, hence it has to do heavy internal seeking (it expects the next sector to be accessed next)