The parameter signature is "pfc::list_base_const_t<metadb_handle_ptr> & p_data".
I expected to get a list of metadb_handle_ptr for the modified tracks, but supposing a 10th track of an album is modified, I'm getting a list of all the tracks in the album. Is this intended?
That does not make sense and works as expected for me.
You might as well reveal how specifically the "10th track of an album" is modified in the first place.
You might as well reveal how specifically the "10th track of an album" is modified in the first place.
I manually modified a track in an album (by right-clicking a track and selecting Properties), and when library_callback::on_items_modified is called as the result, p_data.get_size() is always equal to the number of tracks in the album. It's with the latest foobar beta version. Very strange.
Even stranger thing is that after this happened, another foobar 0.9.5 installation lost it's ability to update any tags.
Let me take this back. This happened because tracks in a locked playlist are rendered impossible to modify their fields even when the locked playlist is removed. This is strange too.
By the way, in the 0.9.5 version, p_data contains only the modified track. This might be a bug in the new beta version.
Even stranger thing is that after this happened, another foobar 0.9.5 installation lost it's ability to update any tags.
QUOTE (sun4384 @ Nov 19 2008, 23:12) 
Even stranger thing is that after this happened, another foobar 0.9.5 installation lost it's ability to update any tags.
Let me take this back. This happened because tracks in a locked playlist are rendered impossible to modify their fields even when the locked playlist is removed. This is strange too.
By the way, in the 0.9.5 version, p_data contains only the modified track. This might be a bug in the new beta version.
CODE
class blah : public library_callback {
virtual void on_items_added(const pfc::list_base_const_t<metadb_handle_ptr> & p_data) {}
virtual void on_items_removed(const pfc::list_base_const_t<metadb_handle_ptr> & p_data) {}
virtual void on_items_modified(const pfc::list_base_const_t<metadb_handle_ptr> & p_data) {
for(unsigned count=p_data.get_count(), i=0; i<count; i++)
console::formatter() << p_data[i]->get_location();
console::formatter() << "---";
}
};
library_callback_factory_t<blah> ghaglj;
virtual void on_items_added(const pfc::list_base_const_t<metadb_handle_ptr> & p_data) {}
virtual void on_items_removed(const pfc::list_base_const_t<metadb_handle_ptr> & p_data) {}
virtual void on_items_modified(const pfc::list_base_const_t<metadb_handle_ptr> & p_data) {
for(unsigned count=p_data.get_count(), i=0; i<count; i++)
console::formatter() << p_data[i]->get_location();
console::formatter() << "---";
}
};
library_callback_factory_t<blah> ghaglj;
foobar2000 v0.9.6 beta 5.
1. Select one track in a playlist from a group with identical <ARTIST>, <ALBUM>, <DATE> and <TOTALTRACKS>.
2. Open Properties.
3. Change some meta field.
4. Press OK.
Result: on_items_modified() is called. Only one item, the one which has been modified, shows up in the console.
Do you have any more precise reproduction scenario?
I found the cause. It happens in case of a cue-embedded album file with multiple tracks. Though only one track of the album file has changed, library_callback::on_items_modified reports all the tracks in the album file. This is consistent with other versions of foobar.
This might not be a desirable behavior... or intended?
This might not be a desirable behavior... or intended?
I don't know.
Though if I wanted to track for example the last-modified timestamp, it changes for the whole file, so I'd like to be notified about the change for all tracks as well.
Though if I wanted to track for example the last-modified timestamp, it changes for the whole file, so I'd like to be notified about the change for all tracks as well.
It would be good to have a method that tells how to behave in such a case.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.