A new symlink causes `IN_CREATE`. Usually, we catch `IN_CREATE` only with
IN_ISDIR to watch the new directory, but otherwise `IN_CREATE` is not
handled. Regular files are "created" but they have usable content
only with `IN_CLOSE_WRITE`. Yet symlinks have only `IN_CREATE` and
they are immediately usable.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2192
MPD stopped building since fmt 11.1.0; see
<https://github.com/fmtlib/fmt/issues/4304>. The first commit
fixing this was 9db7144, followed by 5de0909 (both on the
unstable branch).
This commit removes what the author believes to be the remaining
uses in the MPD codebase.
When compiling with libfmt-11.1.0 and newer the following compile errors occur:
In file included from ../src/decoder/DecoderPrint.cxx:23:
../src/client/Response.hxx: In instantiation of 'bool Response::Fmt(const S&, Args&& ...) [with S = decoder_plugin_print(Response&, const DecoderPlugin&)::<lambda()>::FMT_COMPILE_STRING; Args = {const char* const&}]':
../src/decoder/DecoderPrint.cxx:38:7: required from here
38 | r.Fmt(FMT_STRING("plugin: {}\n"), plugin.name);
| ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/client/Response.hxx:86:28: error: cannot convert 'const decoder_plugin_print(Response&, const DecoderPlugin&)::<lambda()>::FMT_COMPILE_STRING' to 'fmt::v11::string_view' {aka 'fmt::v11::basic_string_view<char>'}
86 | return VFmt(format_str,
| ~~~~^~~~~~~~~~~~
87 | fmt::make_format_args(args...));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/client/Response.hxx:81:36: note: initializing argument 1 of 'bool Response::VFmt(fmt::v11::string_view, fmt::v11::format_args)'
81 | bool VFmt(fmt::string_view format_str, fmt::format_args args) noexcept;
| ~~~~~~~~~~~~~~~~~^~~~~~~~~~
../src/client/Response.hxx: In instantiation of 'bool Response::Fmt(const S&, Args&& ...) [with S = decoder_plugin_print(Response&, const DecoderPlugin&)::<lambda()>::FMT_COMPILE_STRING; Args = {const char* const&}]':
The error is due to the use of FMT_STRING. The libfmt team shared the following:
The correct way of using FMT_STRING is to wrap a format string when passing to a
function with compile-time checks (i.e. that takes format_string) as documented
in https://fmt.dev/11.1/api/#legacy-compile-time-checks.
Noting that FMT_STRING is a legacy API and has been superseded by consteval-based
API starting from version 8: https://github.com/fmtlib/fmt/releases/tag/8.0.0. It
looks like MPD is trying to emulate {fmt}'s old way of implementing compile-time
checks which was never properly documented because it was basically a hack. So the
correct fix is to switch to format_string and, possibly, remove usage of FMT_STRING.
The old way of doing compile-time checks (fmt::make_args_checked) was documented
in https://fmt.dev/7.1/api.html#argument-lists but it looks like MPD is not using
that API so the problematic uses of FMT_STRING have no effect and can just be removed.
The FMT_STRING has been removed in this change based on the fmt-7.1 API and now MPD is
successfully compile against the current libfmt-11.1.0 which highlighted the issue that
had been present in the codebase as it is now triggering the error, is legacy and was
not using the API for which FMT_STRING was aligned with.
Previously, inode numbers were truncated to 32 bits, which could lead
to problems on XFS where inodes are 64 bit; this could lead to bogus
"recursive directory found" errors during database update.
[mk: added commit description and NEWS line]
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2000
This commit adds the `SHOWMOVEMENT` [tag](https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#show-work-movement-4). Historically, this tag originates from iTunes' MP4, but has since become widely used. It is created by Picard's Classical music [plugins](https://picard-docs.musicbrainz.org/en/variables/variables_classical.html) (such as "Classical Extras" or "Work & Movement").
The reasoning behind this tag is to display Work & Movement titles without redundant information and in a more uniform way. Moreover, it additionally serves as an implicit marker denoting classical music tracks (genre tags aren't sufficient).
If the client so chooses to support this tag, they can display `Work` and `Movement` instead of the track title allowing for cleaner display. Other clients can continue to display the `%title%` as before without any fuss.
Previously, inode numbers were truncated to 32 bits, which could lead
to problems on XFS where inodes are 64 bit; this could lead to bogus
"recursive directory found" errors during database update.
[mk: added commit description and NEWS line]
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2000
- added is set to current time, if a new song is added to the database.
- GetAdded falls back to mtime.
Code for proxy plugin is missing, this needs a patch for libmpdclient.
closes#378
This eliminates all `Storage::GetInfo()` calls from
`UpdateWalk::PurgeDeletedFromDirectory()` and instead uses a "marker"
field to mark items that have been visited; later, all unmarked items
can be deleted.
This eliminates a lot of redundant I/O which is noticable with the
`curl` storage plugin (i.e. WebDAV).
Without clearing all `in_playlist` flags, the songs will never be
revealed again if they were hidden once by a CUE sheet, not even after
the CUE sheet gets deleted or modified.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1784
