Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Input plugin vs metadata cache (Read 974 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Input plugin vs metadata cache

Sample rate and playback time are preferences of my chiptune input plugin foo_asap. Unfortunately foobar2000 caches these on the first playback in metadb.sqlite. How can my plugin opt-out of this caching or refresh the stale cache?

Re: Input plugin vs metadata cache

Reply #1 –
Don't report sample rate as a static file property as it's not a file property for synthesized format. Report it as dynamic info.
Length should be a static property and if you report it as a file property you can't prevent it from being cached. You could force foobar2000 to refresh it, but I fail to see why a reported track length would depend on input decoder settings.

Re: Input plugin vs metadata cache

Reply #2 –
Quote from: Case on
Length should be a static property and if you report it as a file property you can't prevent it from being cached. You could force foobar2000 to refresh it, but I fail to see why a reported track length would depend on input decoder settings.
For synthesized tracks there can be a difference between the length (= the sum of all individual events) and the duration if the format allows multiple loop points. The duration of a track is not always the same as the length. In fact, duration can be infinite. Since the reported length controls the behavior of the fb2k position control there is always a 'wrong' choice.
Unless I missed something in the API.

Re: Input plugin vs metadata cache

Reply #3 –
Quote from: Case on
Don't report sample rate as a static file property as it's not a file property for synthesized format. Report it as dynamic info.
Thanks, it works!
Quote from: Case on
I fail to see why a reported track length would depend on input decoder settings.
A chiptune is stored as a computer program. My plugin emulates the computer. For chiptunes not tagged with playback length, the plugin provides configuration option to set some fixed playback time.
Quote from: Case on
You could force foobar2000 to refresh it
How?

Re: Input plugin vs metadata cache

Reply #4 –
I'm definitely against the idea of loop settings altering cached track lengths. But I suppose changing default length for tracks that have no length is a valid reason to update cached data.

Adding something like this to open() is at least one way to achieve info update.
Code: [Select]
try {
    auto mio = metadb_io_v2::get();
    auto mdb = metadb::get();
    service_ptr_t<metadb_hint_list> hint_list = mio->create_hint_list();
    metadb_hint_list_v3::ptr hint_list_v3;
    hint_list_v3 ^= hint_list;
    metadb_handle_ptr track;
    mdb->handle_create(track, make_playable_location(p_path, 0));
    if (track.is_valid()) {
        file_info_impl info;
        get_info(info, p_abort);
        // info.set_length(new_length); // you can force a new length here if get_info() doesn't return the value you want
        hint_list_v3->add_hint_forced(track, info, get_file_stats(p_abort), true);
        fb2k::inMainThread([=] {hint_list->on_done(); });
    }
} catch (pfc::exception) {}