Support and General Use > Audio Playback, Database and Playlists
EXTM3U format support?
Lear:
--- Quote from: polygonal on September 02, 2007, 11:29:36 AM ---Yeah, I don't know why the tagcache searches for known filenames are so slow.
--- End quote ---
The main reason that patch is slow is that it makes a search each time an item is to be displayed (and if done on a player with an lcd remote, it would probably be two searches per item). Even if the database can be made faster, I'm not sure it is reasonable to expect it to be fast enough for that...
--- Quote ---1. if initiated from filebrowser, set up a tagcache search based on a "containing" clause of the dir name and retrieve the entries, which should be fast since the current database tagtree works this way and it is quite fast.
--- End quote ---
In the playlist viewer, a single search isn't always enough. You might have to make a separate search for each item...
polygonal:
--- Quote from: Lear on September 03, 2007, 06:30:00 AM ---The main reason that patch is slow is that it makes a search each time an item is to be displayed (and if done on a player with an lcd remote, it would probably be two searches per item). Even if the database can be made faster, I'm not sure it is reasonable to expect it to be fast enough for that...
--- End quote ---
Not really. My local patch actually search the database only once at the same time as the viewer ask for the filenames (and stores the track title instead of filename in the viewer entry struct). I have a tcs set up and reuse it. I think what is slow is the process of finding the tagcache idx for a given filename (it should be fast to find the tag information after the idx is known).
--- Quote ---In the playlist viewer, a single search isn't always enough. You might have to make a separate search for each item...
--- End quote ---
Maybe you are right - I forgot about the fact that you can insert shuffled, then tagcache search get next won't be very helpful. But in this case, the speed will still be a big concern since as I remarked above, doing a single search for each item is very, very slow.
Lear:
So you're doing it in playlist_entry_load (or something similar, rather than playlist_callback_name) and it is still very slow? Any idea how long time a single search takes, roughly?
polygonal:
--- Quote from: Lear on September 03, 2007, 01:03:22 PM ---So you're doing it in playlist_entry_load (or something similar, rather than playlist_callback_name) and it is still very slow? Any idea how long time a single search takes, roughly?
--- End quote ---
Yes, I made a tcs in playlist_buffer_load_entries and pass the pointer to tcs to playlist_entry_load, and this is what I do
--- Code: ---+ if (tcs != NULL)
+ {
+ entry->has_extm3u = tagcache_find_index(tcs, info.filename);
+ DEBUGF("found tc idx: %d\n",tcs->idx_id);
+ if (entry->has_extm3u)
+ {
+ entry->length = tagcache_get_numeric(tcs, tag_length) / 1000;
+ entry->has_extm3u = tagcache_retrieve(tcs, tcs->idx_id, tag_title,
+ name_buffer, MIN(MAX_PATH*2,remaining_size));
+ DEBUGF("track: %s\n",name_buffer);
+ len = strlen(name_buffer) + 1;
+ }
+ }
--- End code ---
And it is very slow. Takes about 38 sec for a 31-item playlist to load.
Lear:
If the database isn't loaded to RAM (or the dircache isn't enabled), I could understand such times. And if it is in RAM, it seems like tagcache_fill_tags could be faster...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version