The upcoming foobar2000 v1.3 release will address various performance problems with very large music libraries.
Background:
One of the key issues with foobar2000 metadb design is that it stores a complete copy of file's text metadata in its cache.
This includes:
- misplaced cuesheets
- EAC logs
- lyrics
- epic novels
- misplaced base64 encoded pictures
- other weird stuff that people come up with
.. which leads to:
- extreme memory usage
- slow startup and shutdown
- poor search performance
To address the above issue, foobar2000 v1.3 metadb will selectively ignore specific metadata records read from the files - mainly data that does not need to be readily available for displaying in playlist, library viewers, etc.
This will not affect daily use; properties dialog will still be able to show complete metadata by reading it from affected files directly.
If your component needs to display such data - lyrics in particular - please change your code to fetch it from the file directly on-demand.
Example:
static bool getInfoFromFile(metadb_handle_ptr inHandle, file_info & outInfo, abort_callback & abort) {
try {
input_info_reader::ptr reader;
input_entry::g_open_for_info_read(reader, NULL, inHandle->get_path(), abort );
reader->get_info( inHandle->get_subsong_index(), outInfo, abort );
return true;
} catch(exception_aborted) {
throw;
} catch(...) {
outInfo.reset();
return false;
}
}
Thank you for your attention.
Thanks for the heads up. Just out of interest will this affect fields compiled through titleformatting?
In case it was not clear, this thread should be reserved for discussion by developers who will be affected by this change.
Non-developers should confine questions and so forth to the corresponding thread in General (http://hydrogenaudio.org/forums/?showtopic=101935). Off-topic posts from this thread have been moved there.
Fields accessible via regular title formatting methods will be affected as well.
Of course you can supply your own file_info coming from any source you like to title formatting to bypass this restriction.
Ok. Will there be a way to detect if a field exists but has not been loaded into the db?
Current situation (may still be subject to changes):
Oversized fields become "." (single dot character) - one-value regardless of original value count - so you can still search for files containing the field.
Metadb knows whether the info it holds is complete (no oversized fields encountered) or simplified, so you can skip loading info from files directly when the cached info is already complete.