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.

The pants are up to my choice. But whenever we decided to use _that_ tool only we very soon got stuck in the restrictions that tool has and made a hell of effort to circumvent them. I prefer to rigidly specify the results and not the tools.

Zagor: Is it okay to continue with plugin adaption (both for Ondio and for USB handling via default handler) while the feature freeze is in effect? I would like to change the plugin api when done with tha (taking out usb_screen(), therefore breaking backwards compatibility -> sort functions)

A design question: I believe that triggered recording _could_ be split into very little code that must reside within rockbox, and other code (most of it) that could be separated into a plugin. Would it be desirable to allow triggered recording from a plugin only?

Zagor: I'd rather do that plugin stuff before release, because (iirc) shortly after the last release we broke api compatibility. That raised a number of "support calls" on the ml, because people wanted to flash with mixed rockbox/plugin versions, and got "incompatible version"

I don't understand why we need different tables at all. All song info of one mp3 file is connected anyway, so imho it might be easier to use just one table, indexed on song name, artist, and album. It would be easy to add more criteria this way (year...)

One index should fit completely into memory, but tthat should not be a problem. Assuming a field length of 50 chars (more than id3v1 provides), it would allow ~30,000 db entries (tracks) on the Archos (~1.5 MB)

i want it too, but I don't think we should mix it with the id3 database. the statistics are long-life data that you want to make sure survives a long time. the id3 database can be recreated at any point in time.

But now I think you're right: it might be good to think about the statistical infos and updating / reindexing them separately. Even if we had to update an id3 tag and half a dozen db entries - for that task we have plenty of time.