Rockbox

Tasklist

FS#6084 - Show playlist entries' Titles (instead of file names)

Attached to Project: Rockbox
Opened by Mike Miller (mikeage) - Thursday, 28 September 2006, 14:45 GMT
Last edited by Jonathan Gordon (jdgordon) - Sunday, 05 August 2007, 08:02 GMT
Task Type Patches
Category Playlists
Status Closed
Assigned To No-one
Operating System All players
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This patch allows one to view the current playlist by title and "title (album)" in addition to file name and full path.

Three major notes, and one minor note:

1. It's slow to load -- don't know why
2. If dircache and tagcache's load to ram are not enabled, it returns garbage. My quick perusal of the tagcache code suggests that this should not happen, but it does. I don't know why.
3. It increases the config file version, so you may need to clear settings (since the display format is now 2 bits instead of 1).
4. The strings only exist in the english language file. I didn't test any other languages (I'm too afraid of getting stuck in a weird menu somewhere <g>)

If anyone can help fix these, I'd like to know how.

This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Sunday, 05 August 2007, 08:02 GMT
Reason for closing:  Out of Date
Additional comments about closing:  and probably would be rejected anyway if it makes the viewer slow
2008-02-19: A request to re-open the task has been made. Reason for request: I have spent some time with this patch as well as FS 7652 which would be another way of getting tag data into the playlist view display. I altered it to add a third view option to the playlist view so you would have fliename only (default), full path, and tag data. Tag data extracted is display as "artist - filename" . I tested performance of the list view with the patch, without it, and with FS 7652. scrolling a very large list (2450 entries) I found no lag difference between no patch at all, and with the tag data retrieve. FS7652 performed worse, presumably because it doubles the size of the list that must be read into memory. It has some other issues as well.
Comment by Miika Pekkarinen (miipekk) - Thursday, 28 September 2006, 17:02 GMT
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
Comment by Mike Miller (mikeage) - Thursday, 28 September 2006, 17:12 GMT
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.
Comment by Magnus Holmgren (learman) - Thursday, 28 September 2006, 17:32 GMT
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.
Comment by Mike Miller (mikeage) - Thursday, 28 September 2006, 18:16 GMT
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 :)
Comment by Miika Pekkarinen (miipekk) - Friday, 29 September 2006, 07:43 GMT
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);
Comment by Mike Miller (mikeage) - Friday, 29 September 2006, 10:49 GMT
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).
Comment by Flid (Flid) - Friday, 10 November 2006, 09:32 GMT
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?
Comment by Mike Miller (mikeage) - Friday, 10 November 2006, 10:41 GMT
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...
Comment by Haseeb (hdaackda) - Thursday, 25 January 2007, 17:51 GMT
Is work being done on this? haven't seen any activity lately :(
Comment by Mike Miller (mikeage) - Thursday, 25 January 2007, 19:37 GMT
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).
Comment by Mike Miller (mikeage) - Sunday, 28 January 2007, 13:52 GMT
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.
Comment by Flid (Flid) - Monday, 29 January 2007, 18:42 GMT
"... 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.
Comment by Dieter (dip) - Sunday, 11 February 2007, 23:46 GMT
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?
Comment by Mike Miller (mikeage) - Monday, 12 February 2007, 02:03 GMT
Did you:
* enable TagCache
* configure it to load to RAM
* wait for it to finish loading
Comment by Dieter (dip) - Monday, 12 February 2007, 22:23 GMT
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?

Comment by Dieter (dip) - Monday, 12 February 2007, 22:26 GMT
Sorry, my last sentence was not right, I found the option to use full path, but nevertheless it does not work.
Comment by Matthew Schneider (mschneider) - Saturday, 09 June 2007, 20:46 GMT
Does this patch just not work, or is it out of sync?
Comment by Mike Miller (mikeage) - Saturday, 09 June 2007, 20:54 GMT
out of sync

Loading...