Allocate a player_control object where needed, and pass it around.
Each "client" object is associated with a "player_control" instance.
This prepares multi-player support.
This fixes a regression in the patch "return multiple tag values per
song": even when the song has values for the specified tag type, the
empty string gets added to the set, because the "return" was removed.
This patch adds a flag which remembers whether at least one value was
found.
When collecting tag values for the result set, add all of a song's tag
values of the searched type. This affects the "list" command.
Previously, "list" only considered the first tag value of a song.
After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.
This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.
Export the "g_playlist" variable, and pass it to all playlist
functions. This way, we can split playlist.c easier into separate
parts. The code which initializes the singleton variable is moved to
playlist_global.c.
On some platforms, g_free() must be used for memory allocated by
GLib. This patch intends to correct a lot of occurrences, but is
probably not complete.
Commit 0bfe7802 broke update for new files in the root directory,
because music_root->path was an empty string and not NULL. There were
some NULL tests missing. Change them to !isRootDirectory(path)
instead of path!=NULL.
Taming the directory.c monster, part II: move the database management
stuff to database. directory.c should only contain code which works
on directory objects.
Seeing the "mpd_" prefix _everywhere_ is mind-numbing as the
mind needs to retrain itself to skip over the first 4 tokens of
a type to get to its meaning. So avoid having extra characters
on my terminal to make it easier to follow code at 2:30 am in
the morning.
Please report any new issues you may come across on Free
toolchains. I realize how difficult it can be to build/maintain
cross-compiling toolchains and I have no intention of forcing
people to upgrade their toolchains to build mpd.
Tested with gcc 2.95.4 and and gcc 4.3.1 on x86-32.
tfing wrote:
> I have quite some files with an empty album tag as they do not come
> from a particular album.
>
> If I want to look for those files and browse them, this happens:
> :: nc localhost 6600
> OK MPD 0.12.0
> find album ""
> ACK [2@0] {find} too few arguments for "find"
>
> I'd like to be able to browse those files in a client like gmpc.
> So these 2 items would have to be developed:
> - list album should report that some files have an empty tag
> - it should be possible to search for an empty tag with the find command
Patch-by: Marc Pavot
ref: http://musicpd.org/mantis/view.php?id=464
Our linked-list implementation is wasteful and the
SongList isn't modified enough to benefit from being a linked
list. So use a more compact array of song pointers which
saves ~200K on a library with ~9K songs (on x86-32).
With a large music database, the linear string collection in
tagTracker.c becomes very slow. We implemented that in a
quick'n'dirty fashion when we removed tree.c, and now we rewrite it
using the fast hashed string set.
Don't pass the raw file descriptor around. This migration patch is
rather large, because all of the sources have inter dependencies - we
have to change all of them at the same time.
