input.harbor -> map_metadata - Wrong callback sequence?

[th3hamm0r]

If multiple metadata changes happen too quickly, it seems like map_metadata and other metadata functions are called in the reverse order for the whole bulk of metadata changes.
I'm using liquidsoap 1.1.1 (ubuntu deb).
Here my basic setup:

config_source = audio_to_stereo(input.harbor(
    "livestream",
    buffer=5.,
    max=20.,
    port=1234,
    password="password",
    on_connect=(fun(h) -> _log("input - on_connect - header: " ^ string_of(h))),
    on_disconnect={_log("input - on_disconnect")}
))
...
current_track_number = ref 0
def update_base_metadata()
    new_meta = [("tracknumber", string_of(!current_track_number)), ("track_start", string_of(gettimeofday()))]
    current_track_number := !current_track_number + 1
    new_meta
end
def update_upstream_metadata(m) =
    _log("update_upstream_metadata - tracknumber: #{string_of(!current_track_number)}, upstream meta data: #{string_of(m)}")
    update_base_metadata()
end
source = map_metadata(update_upstream_metadata, config_source)

If the metadata change comes in a bulk, the log shows something like this:

2017/07/28 07:29:55 [harbor_5091:3] New metadata chunk ? -- {"id":609336,...}.
2017/07/28 07:29:55 [harbor_5091:3] New metadata chunk ? -- {"id":610590,...}.
...
2017/07/28 07:30:12 [splitter:3] update_upstream_metadata - tracknumber: 85407, upstream meta data: [(...{\"id\":610590)]
2017/07/28 07:30:12 [splitter:3] update_upstream_metadata - tracknumber: 85408, upstream meta data: [(...{\"id\":609336)]

Is this a bug or intended that if those changes happen to quickly (maybe during one wall cycle), the metadata handlers are executed in the reverse order of the actual metadata change?

My quick-fix will skip further metadata changes during the same cycle, so at the end, if this happens, due to the reversed order of the callbacks, the last track of those bulks (here 610590) will be used for further execution.
Maybe I could find a slot, where I can test newer versions of liquidsoap, but at the first sight I did not find any commit/issue, which targets this problem.

[toots]

Thanks for the report! It should be fixed now. Any chance you could confirm? It should be fairly easy to pin liquidsoap in opam to the latest code:

git clone --recursive https://github.com/savonet/liquidsoap.git
cd liquidsoap
opam pin add liquidsoap .