Hello Max, Max Kellermann wrote: > It's a hack, but I think if we cut off some rough edges, we can merge > it anyway. Let's get the feature in if it doesn't break anything, and > think about migrating to a clean solution after that.
Currently i'm working on the scan_directory() method you proposed in one of your first emails. This isn't to hard to do now and we'll get rid of several include dependencies. Do you know of a better way/have a better idea for enumerating the subtracks instead of "track_xxx.flac" like i did atm? >> diff --git a/src/input_file.c b/src/input_file.c >> index b29a412..cd3f2e7 100644 >> --- a/src/input_file.c >> +++ b/src/input_file.c >> @@ -25,6 +25,9 @@ >> #include <string.h> >> #include <glib.h> >> >> +#include "ls.h" >> +#include "decoder/_flac_common.h" >> + > > MPD core sources should not include decoder specific headers. But now > I understand what you meant with "input_flac" on IRC - it'll eliminate > this dependency. Would it be better if i did something like this: stat() the pathname on NULL: go one level below stat() again until we're either root or have a file. (haven't tried it yet, maybe i'm wrong on this but after a quick look in input_file.c i think this might work as well) >> diff --git a/src/update.c b/src/update.c >> index 17059ff..9599e9a 100644 >> --- a/src/update.c >> +++ b/src/update.c >> @@ -35,6 +35,9 @@ >> #include "stats.h" >> #include "main.h" >> #include "config.h" >> +#include "tag.h" >> + >> +#include "decoder/_flac_common.h" > > Same here, although that will be more difficult to get rid of. Let's > say you add #ifdef HAVE_FLAC around that code, and we merge it - > cleanup (decoder API extension) later. This should be no problem with the scan_directory api extension. Though i now have to include tag.h, song.h, songvec.h and dirvec.h to flac_plugin.c. Is this ok? The general approach of scan_directory could be used for the archive plugin as well i think.. We had a short talk about the cue sheet support on irc. This is going to be a pita imho. :) 1) cuetools are from 2006 and take only a fd as input A possible solution would be to write out embedded cue sheets (like in flacs) to a temporary file with mkstemp() (libc) and use that for i/o. 2) cdrecord has a cue sheet parser. This also takes an fd and it's not a library so using it could become quite difficult. Whatsmore it another ~1250 lines monster i cannot rewrite easily.. This gets me to 3) Write an parser on your own. Here you can find the complete spec: http://digitalx.org/cuesheetsyntax.php As you can see (and also from cuetools/cdrecord) this ain't an easy thing to do. 4) Use a parser lib written in e.g. in C#: http://wyday.com/cuesharp/ Do you really want that? :) As a conclusion for the cue parser/plugin: Writing a parser ourselves would be the best option but also the hardest. I tend to like the cuetools approach best because the specs didn't change and cuetools seem to be usable in an easy way. What i don't like though is having a tmp file.. Looking forward to your reply and greets, Jochen
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
_______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
