| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Pass const songvec pointers to songvec_find() and songvec_for_each().
[ew: already merged songvec_for_each() cosntification somewhere...]
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Again, a data type which can be forward-declared.
[ew:
* used "struct mpd_song" instead to avoid token duplication
(like I did with "struct mpd_tag") as there's no good
abbreviation for "song" and identical tokens on the same
line don't read well
* rewritten using
perl -i -p -e 's/\bSong\b/struct mpd_song/g' src/*.[ch]
since it was too hard to merge
* also, I don't care much for forward declarations
]
|
| |
|
|
| |
Get rid of songvec_write so we can enforce proper locking
|
| |
|
|
|
| |
This is so we can more consistently deal with locking
needed for thread-safety in iterator functions.
|
| |
|
|
| |
We don't modify the Song when we delete it
|
| |
|
|
|
| |
"free" implies the songvec structure itself is freed,
which is not the case.
|
| |
|
|
|
|
| |
Any pruned files will be noticed during update and pruned
from the live database, so this inefficient function can
go away and never come back.
|
|
|
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).
|
