Rockbox

1. It seems to be a problem with list widget code to use the callback function to retrieve file names more often than necessary.

2. Currently tagcache_fill_tags(…) function is intended to work only when tagcache is loaded to ram because it would be a slow thing to do otherwise. But I can fix the tagcache code so that it will always work, but it will be very slow for big playlists.

3. That should be ok.

4. Language seems to be handled correctly also.

5. You should fix the patch so that entries point to the same directory level.

Not this way:
— ../../rockbox-daily-20060927.ref/apps/lang/english.lang 2006-09-27 07:00:45.000000000 +0300
+++ ./lang/english.lang 2006-09-28 14:11:06.000000000 +0300

But that way:
— apps/lang/english.lang 2006-09-27 07:00:45.000000000 +0300
+++ apps/lang/english.lang 2006-09-28 14:11:06.000000000 +0300

You can just use the command: cvs diff -u

Miika,

Thanks for the response.

1. Is there any easy way to fix this?

2. Is there a way I can detect if TagCache in RAM / dircache are enabled? Alternatively, is there a better API for me to use?

3. Was just an FYI

4. Yep.. I noticed that it defaults to English

5. I did that because I run the patch from within the rockbox directory. I’ll modify it, though, if that’s the standard for rockbox patches.

5. You should fix the patch so that entries point to the same directory level.

The GUI list code calls the get item name callback each time it wants to redraw an item in the list. And if you’re using a device that supports LCD remotes, some lines will be drawn twice. One solution could be to use parts of the name buffer to cache (!) the tagcache results. That would also improve things when the tagcache isn’t loaded in RAM.

I don’t (yet) know enough about the available buffers to implement this. If someone wants to, I won’t object <g>

Oh, and in my previous comment, I accidently pasted Miika’s #5 below my #5 response. Please ignore that :)

tagcache_fill_tags(…) should return false if it was unable to retrieve tag data. If you would like to try other api functions that can be used whether tagcache is loaded in ram or not, you might want to try something like this:

static struct tagcache_search tcs;

…

if (!tagcache_find_index(&tcs, filename))

  return error;

idxid = tcs.idx_id;
tagcache_search_finish(&tcs);

if (!tagcache_search(&tcs, tag_album))

  error..

if (tagcache_retrieve(&tcs, idxid, buffer, buffer_length))
{

 /* buffer = the search results */

}

tagcache_search_finish(&tcs);

I’m not convinced that it’s wise to even try if it’s not already TagCached in RAM. I assume the load times will be really bad if it has to get it from disk.

That said, in the patch I made, do you have any thoughts on why TagCache occasionally returns garbage (or, at least, the string is populated with garbage)? All songs have the same data… usually a few bytes (1-3) of non printable characters, and it’s the same for all files. It tends to happen when I play around with the tagcache settings, although I also saw it once when I changed the language (not sure how that could’ve happened).

Hi. I’ve only just stumbled across this patch. Just thought I’d say that I’d love for this to be implemented, but possibly with a configurable option of “Artist - Title”, as I like genre based playlists.

Has this completely ground to a halt?

Also… just for reference, I don’t see why loading tagcache from disk would be obstructively slow. Surely it’s just got to read the file, not rebuild the database?

I can gladly add that option for you, if you’d like (although probably not until Sunday, as my iPod is on loan to a friend for the weekend).

I haven’t pursued this lately, since I have no idea why I often get garbage in the tagcache struct (from tagcache_fill_tags), although it returns true. Maybe Miika has an idea why…

Is work being done on this? haven’t seen any activity lately :(

I haven’t touched it… I stopped using Database (nee tagcache) for a while.

It had a problem which I don’t quite understand: tagcache_fill_tags returns an ok status, but it fills the fields with garbage (every track gets the same gibberish).

Ok, I just dusted off this patch.

It works nicely now (new patch attached that replaces the “full path” view with the tagcache derived view).

It’s still slow, and search doesn’t work. I have to think about where to go from here.

   playlist_viewer.patch (0.5 KiB)

“… where to go from here” Maybe, this could be merged with the actual Database view root “menu”, allowing you to view “Current Playlist” based on tag info, and the configuration of this view could be user adjustable (to allow for Artist - Title / Tile / Title(Album) / Filename etc).

Thanks for keeping an eye on this one Mike.

Does not work for me. Although the patch could be applied without errors there are still the filenames displayed for the current playlist. I can switch between display with file names only or full path and the filenames only or the full path are shown but not the tags. Any idea why?

Did you:
* enable TagCache
* configure it to load to RAM
* wait for it to finish loading

I did all this but still see only the complete path.
By the way, I use the simulator with the latest svn since I have an iPod 80GB 5.5g and am waiting for a running rockbox version. In the latest svn version I don’t any longer find the option to use full path in the playlist context menu, but only in the general settings menu. Is that correct?

Sorry, my last sentence was not right, I found the option to use full path, but nevertheless it does not work.

Does this patch just not work, or is it out of sync?

out of sync