In the abstract, it's a fine idea. We don't all use parochial code to do host name resolution; we all ask DNS to resolve host names for us. Why not a similar service for audio metadata, even if only at the local level.
Thanks, glad you agree on that level :)
But describing an idealized service is one thing. Building it is quite another. Getting a non-trivial percentage of applications to even be aware of its existence is a still much larger hurdle.
Yes I realise this. I belive I can code this system relativly easily. The principles are fairly standard and there are big chunks of programs I/others have previously written that could deal with large portions of this project too.
The changes to Myth would be easy enough to code, albeit take a little time.
Other programs etc. may be harder to convince, and it may take a fair bit of time to gain acceptance, but everythings got to start somewhere.
If you want to get anywhere close to a path that might lead to wide acceptance of your idea, you will need to make it work with current (unmodified) software. That means, to the extent possible, pushing metadata back into the mp3's themselves (ie. writing tags that other software can read).
Oh yes. I totally agree. Simon also seemed to hint at this, but I am not suggesting that it does not write tags to files. If running as a daemon, apps could submit metadata changes to the MetaLibrarian and it could at a later date (or immediately) write these changes to the file itself. I'll rewrite that part of the description to make it clearer that file based tags will *always* be maintained.
So ... uhm ... for mythmusic, where exactly are we on 2.3 versus 2.4 tags? As I understand things, we're now writing tags that almost nothing else can understand. Is that accurate? If so, can we improve on that :-) ?
Well, my general thought was that if the metadata writing was off loaded to another program/library then it could use a better tag writing library to write to the files and thus get round the whole problem! It doesn't really solve it directly tho' and would still add other dependancies (although I reckon such dependancies could be wrapped up in to a libmyth component, to keep it "in house" kinda).
I decided last night to write a simple ID3v2 tag writer for Myth and use that for writing tags. The spec is uber simple to follow so it will only take a few days of coding to get it right and libid3tag can P155 right off. It's caused me enough hassle. (OK, it can stick around for reading tags - that at least seems OK ;)
btw: DAAP does have rather extensive metadata-description capabilities, but in-and-of itself it is just a markup and streaming protocol. It says nothing about how that data should be persisted.
Interesting, thanks for the summary. So a DAAP daemon could still use this as a backend for persistant storage of the data etc.
Cheers for the feedback.
Col. --
+------------------------+ | Colin Guthrie | +------------------------+ | [EMAIL PROTECTED] | | http://colin.guthr.ie/ | +------------------------+
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
