$ sudo bash
 # cd /.Spotlight-V100
 # pwd
 /.Spotlight-V100
 # ls -l
total 262496
-rw-------   1 root  admin         0 Sep  8
04:51 .journalHistoryLog
-rw-------   1 root  admin  37048320 Sep  8
05:10 .store.db
-rw-------   1 root  admin  60293120 Sep  8
05:05 ContentIndex.db
-rw-------   1 root  admin       351 Aug 18
18:00 _exclusions.plist
-rw-------   1 root  admin       378 May  1
20:34 _rules.plist
-rw-------   1 root  admin  37048320 Sep  8
05:10 store.db
 

 # cat _exclusions.plist
 <?xml version="1.0" encoding="UTF-8"?>
 
 <!DOCTYPE plist PUBLIC "-//Apple
 Computer//DTD PLIST 1.0//EN"
 "https://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
         <key>EXCLUSIONS</key>
         <array>
                 <string>/Users/apl/snapshots</string>
 
                 <string>/Users/apl/Movies</string>
                 <string>/Users/apl/Music</string>
                 <string>/Users/apl/Pictures</string>
         </array>
 
 </dict>
 </plist>
 # 
 
 

 for i in `mdfind Stuff`
 do
   scp $i me@somewhere.com:$i
 done
 
 

  mdfind  'kMDItemTextContent == "*Seneca*" && kMDItemFSName != "*emlx"'
  mdfind  'kMDItemTextContent == "*Seneca*" && kMDItemContentType != "com.apple.mail.emlx"'
 
 

 $ mdls t.txt
 t.txt -------------
 kMDItemAttributeChangeDate     = 2005-05-06 15:44:32 -0400
 kMDItemContentCreationDate     = 2003-12-15 18:11:55 -0500
 kMDItemContentModificationDate = 2005-05-06 15:44:31 -0400
 kMDItemContentType             = "public.plain-text"
 kMDItemContentTypeTree         = (
     "public.plain-text", 
     "public.text", 
     "public.data", 
     "public.item", 
     "public.content"
 )
 kMDItemDisplayName             = "t.txt"
 kMDItemFSContentChangeDate     = 2005-05-06 15:44:31 -0400
 kMDItemFSCreationDate          = 2003-12-15 18:11:55 -0500
 kMDItemFSCreatorCode           = 0
 kMDItemFSFinderFlags           = 0
 kMDItemFSInvisible             = 0
 kMDItemFSLabel                 = 0
 kMDItemFSName                  = "t.txt"
 kMDItemFSNodeCount             = 0
 kMDItemFSOwnerGroupID          = 20
 kMDItemFSOwnerUserID           = 501
 kMDItemFSSize                  = 2552
 kMDItemFSTypeCode              = 0
 kMDItemID                      = 1802523
 kMDItemKind                    = "Plain text document"
 kMDItemLastUsedDate            = 2003-12-15 18:11:55 -0500
 kMDItemUsedDates               = (2003-12-15 18:11:55 -0500)
 
 

 $ mv t.txt z
 $ mdls z
 z -------------
 kMDItemAttributeChangeDate     = 2005-05-06 16:30:56 -0400
 kMDItemContentCreationDate     = 2004-06-08 13:06:19 -0400
 kMDItemContentModificationDate = 2005-05-06 16:30:55 -0400
 kMDItemContentType             = "public.data"
 kMDItemContentTypeTree         = ("public.data", "public.item")
 kMDItemDisplayName             = "Z"
 kMDItemFSContentChangeDate     = 2005-05-06 16:30:55 -0400
 kMDItemFSCreationDate          = 2004-06-08 13:06:19 -0400
 kMDItemFSCreatorCode           = 0
 kMDItemFSFinderFlags           = 0
 kMDItemFSInvisible             = 0
 kMDItemFSLabel                 = 0
 kMDItemFSName                  = "Z"
 kMDItemFSNodeCount             = 0
 kMDItemFSOwnerGroupID          = 20
 kMDItemFSOwnerUserID           = 501
 kMDItemFSSize                  = 2552
 kMDItemFSTypeCode              = 0
 kMDItemID                      = 2434137
 kMDItemKind                    = "Document"
 kMDItemLastUsedDate            = 2004-06-08 13:08:16 -0400
 kMDItemUsedDates               = (2004-06-08 13:08:16 -0400)
 
 

 $ diff t t.txt
 $ ls -l t t.txt
 -rwxr-xr-x   1 apl  staff  2552 May  6 15:41 t
 -rw-r--r--   1 apl  staff  2552 May  6 15:44 t.txt
 $ mdls t
 t -------------
 kMDItemAttributeChangeDate     = 2005-05-06 15:41:14 -0400
 kMDItemContentCreationDate     = 2005-05-06 15:41:11 -0400
 kMDItemContentModificationDate = 2005-05-06 15:41:11 -0400
 kMDItemContentType             = "public.data"
 kMDItemContentTypeTree         = ("public.data", "public.item")
 kMDItemDisplayName             = "t"
 kMDItemFSContentChangeDate     = 2005-05-06 15:41:11 -0400
 kMDItemFSCreationDate          = 2005-05-06 15:41:11 -0400
 kMDItemFSCreatorCode           = 0
 kMDItemFSFinderFlags           = 0
 kMDItemFSInvisible             = 0
 kMDItemFSLabel                 = 0
 kMDItemFSName                  = "t"
 kMDItemFSNodeCount             = 0
 kMDItemFSOwnerGroupID          = 20
 kMDItemFSOwnerUserID           = 501
 kMDItemFSSize                  = 2552
 kMDItemFSTypeCode              = 0
 kMDItemID                      = 5482482
 kMDItemKind                    = "Unix Executable File"
 kMDItemLastUsedDate            = 2005-05-06 15:41:11 -0400
 kMDItemUsedDates               = (2005-05-06 15:41:11 -0400)
 
 

 $ grep -l fogpr1 *
 Z
 abcde
 abcde.doc
 abcde.doh
 abcde.txt
 foo.txt
 t
 t.txt
 $ mdfind fogpr1
 /Users/apl/t.txt
 /Users/apl/abcde.txt
 /Users/apl/foo.txt
 
 

 $ defaults write com.apple.finder AppleShowAllFiles TRUE
 $ killall Finder
 
 

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> mdfind

Inexpensive and informative Apple related e-books:

Take control of Apple TV, Second Edition

Take Control of Numbers

Are Your Bits Flipped?

Take Control of Parallels Desktop 12

Photos for Mac: A Take Control Crash Course

Fri Apr 10 18:17:30 2009: 6096   JamesIsIn


I am working to get flacs to play through DAAP and I believe I can get that to work if I am able to manipulate certain default md information, specifically the kMDItemFSTypeCode (by telling the Mac to assume it is 1332176723 for any instance of a .flac).

I just need to figure out a way to induce this assumption. Here is my post:

(link)

Any help will be appreciated.



Fri Apr 10 21:59:53 2009: 6097   TonyLawrence


Hmm.. did you see this?

(link)

Also not sure if this would help:

(link)



And this reference to a Flac tool? (link)

More discussion at (link) (I know you saw that)

Let us know if you figure it out.



Sat Apr 11 00:35:28 2009: 6098   JamesIsIn


Hey, thanks. The Songbird issue is unrelated. The metadata referred to there is contained in the file. The metadata I am seeking to change in stored by Spotlight (as are the defaults as near as I can tell).

I am already using the xiph component (see my blog post linked above). There are two component pieces which need to be added (the xiph piece and another called flacimporter.component). With these in place it is still necessary to touch each file with something called Set OggS.app. This application sets the kMDItemFSTypeCode for that file (said metadata being kept elsewhere by Spotlight).

My thinking is that if we can tell the OS/Spotlight to default to the above TypeCode for any flac file which passes through the kernel (which would be nearly all of them) then we would no longer need the OggS program (and then perhaps files coming in across DAAP will also be playable).



Sat Apr 11 11:10:32 2009: 6099   TonyLawrence


Spotlight creates an index that contains the metadata info it found in files, but it gets that from the files themselves. Maybe I'm not understanding what you are getting at, but I don't see how that would help you. If you changed that, all it would mean is that Spotlight would think the files had that metadata - it wouldn't affect iTunes or anything else.

If you actually changed the metadata in the file, I could see that affecting iTunes - I don't know that it would help anything other than making iTunes think the file was a different type but maybe that's all you need.

But I know next to nothing about music formats..









Sat Apr 11 13:24:56 2009: 6100   TonyLawrence


said metadata being kept elsewhere by Spotlight

No. That's incorrect. Spotlight doesn't "keep" metadata. Files keep their own metadata. Spotlight simply reads it and copies it into an index so that it can later find things more quickly.

I think you are barking up the wrong tree.



Sat Apr 11 19:21:13 2009: 6106   JamesIsIn


Hmmm... Well, I'm sorry but that doesn't jive with information I have. I agree that some kinds of metadata are stored as a part of the file (like ID3 tags), but all of the kMDItem information is stored by Spotlight in a data store:

(link)

(link)

The application Set OggS.app tells Spotlight to mark the kMDItemFSTypeCode as 1332176723. I am told no change is made to the file whatsoever. I have this information from a xiph developer.

What can you add to my knowledge?



Sat Apr 11 20:12:46 2009: 6108   TonyLawrence


I can't add a thing - as I said, I know nothing about music or music files.

However, I think you might be misreading those pages. Yes, Spotlight creates a store. Does iTunes look in that store? If it does, that would imply you couldn't use iTunes if you disabled Spotlight. I don't think that's the case..

But anyway: I know nothing about iTunes. Good luck, sorry I can't help.



Sat Apr 11 20:18:31 2009: 6110   JamesIsIn


Thanks for taking a look at the matter, nonetheless. You can always send me an e-mail if you discover something later or point someone more in this area toward my post.



Sat Apr 11 20:22:49 2009: 6111   TonyLawrence


And probably what you aren't understanding about "not stored in the file" is that is always true: metadata is stored in the files resource fork.

I may be wrong about where THIS metadata is stored - see more comments below

That (link) piece is telling developers that they can put in metadata that Spotlight will understand - it's not saying that Spotlight extends the files metadata.

The other link - (link) - explains:

The meta-data store, on the other hand, is a totally new hand-tuned database designed explicitly to handle the unique needs of meta-data. Internally, it represents each file as an MDItem object. Each MDItem contains a dictionary of the various meta-data attributes of that file organized by unique keys. A sample of these keys is listed in the following table.

(I added the bold emphasis).







Sat Apr 11 20:50:22 2009: 6112   JamesIsIn


Surely "stored in a file's resource fork" and "stored in the file itself" are not the same.

As you point out the metadata in question is kept in an MDItem which is in turn a representation of the file. Much like a photograph is a representation of me. (There is much information stored in photographs of me that is not stored in me, believe me.) You can manipulate a photograph of me without involving me at all.

The MDItem is created by Spotlight on the fly. When a file passes through the kernel, a representation is created for Spotlight (assuming Spotlight is enabled). I just want to help influence the assumptions which are made when that initial representation is created (specifically the assumption about kMDItemFSTypeCode).

Crazy?



Sat Apr 11 21:26:17 2009: 6113   TonyLawrence


I don't think you are understanding.

The metadata we are talking about is stored in a file's resource fork - that's NOT in the bytes of the file but it's not a "photograph" or anything like that. It's exactly the same conceptually as data like the file size or number of links. I may be wrong about where THIS metadata is stored - see more comments below



Developers are encouraged to use metadata keys that Spotlight understands. That's what one of the links you gave explains.







Sat Apr 11 21:32:14 2009: 6114   TonyLawrence


This might help you:

(link)

Spotlight is notified when an application creates or updates a document, and imports the metadata from the file.

(again, I added the emphasis)



Sat Apr 11 22:03:33 2009: 6115   JamesIsIn


Ok, I'm not quite clear on how this is a problem. Clearly the meta type kMDItemFSTypeCode isn't inherent in mp3's or flac's or even likely aac's. So some information is interpreted to fill in that code (and perhaps returns a null value for flac's, I'm not clear). What would prevent us from interposing on that interpretation using an MDImport file? Can a developer not tell Spotlight (through an MDImport file) to make kMDItem assuptions for a proprietary extension (as if I had a file I called .ummagumma and wanted it treated in a particular manner)?



Sat Apr 11 23:30:58 2009: 6116   TonyLawrence


You can add metadata to any file.

In your post you note:

The OggS application registers certain metadata with the operating system

Not quite. It adds metadata to a file. See (link) for example.

I have NO idea what, if any, metadata iTunes cares about. I cannot imagine why iTunes would need anything from Spotlight..







Sun Apr 12 00:26:15 2009: 6117   TonyLawrence


What I mean is this: you say "registers with the OS". That's wrong.

Metadata *might* mean something to the OS (uti's for example), it *might* mean something to Spotlight (the specific things Spotlight understands) or it might only be meaningful to the application that uses those files. That;s not "registering".



Sun Apr 12 01:57:38 2009: 6121   JamesIsIn


I am not convinced the file changes at all. I checked the byte count and it didn't change. I suppose I could do a checksum and compare that too.

If the Set OggS is not run (or after you have run Clear OggS) you cannot drag and drop the file into an iTunes library. That certainly looks like the OS making a decision to me.

Thoughts?



Sun Apr 12 10:43:01 2009: 6122   TonyLawrence


I checked the byte count and it didn't change. I suppose I could do a checksum and compare that too.

Of course it's the same: metadata is stored in the file's resource fork, not in the data bytes. The "mdls" command will show you that metadata.

I may be wrong about where THIS metadata is stored - see more comments below

You can see this yourself at the command line. Take a file name that doesn't exist - "showme" for example. Do this

date > showme.txt

You now have a file called "showme.txt" with the date/time in it. See that with "cat showme" or open it with TextEdit.

But you have more than that. Do

ls showme.txt/..namedfork/rsrc

Where did THAT come from? It's the resource fork. Do

mdls showme.txt

to see what's in it.

You can even add to that. If you do "GetInfo" on that file (or any file), you can add a "Spotlight Comment" that will then show up in "mdls"

Notice that nothing changes in the file itself - it;s still just the date/time.



Sun Apr 12 10:57:42 2009: 6123   TonyLawrence


Note also that when you copy a file, you don't necessarily copy the resource fork. The fork can tag along if the target file system supports resource forks but otherwise it's either not coped or is copied as a new file (which will look like "junk" on the target disk)..

See (link) (link)

I hope that helps you understand that the metadata is in the filesystem and not some magic in the OS or Spotlight.



Sun Apr 12 11:24:49 2009: 6125   TonyLawrence


Some other links that might help:

(link) (link)

And an open source resource fork editor:

(link)







Sun Apr 12 11:29:33 2009: 6126   JamesIsIn


Well, this is interesting. I am learning a lot. Thanks for that.

I ran the command "ls Song.flac/..namedfork/rsrc" and it returned "Song.flac/..namedfork/rsrc" both with and without OggS set. What does that mean?



Sun Apr 12 11:38:16 2009: 6127   TonyLawrence


It means that just like "showme.txt" , every file has a resource fork. Oggs didn't create the fork - it supposedly modifies it.

Do "mdls" on your file before and after Oggs and compare.

I may be wrong about where THIS metadata is stored - see more comments below

Simple way to compare in Terminal:

mdls Song.flac  > /tmp/before
then do your Oggs thing
mdls Song.flac  > /tmp/after
diff /tmp/before /tmp/before

For example, if I add a spotlight comment

$ date > t
$ mdls t > /tmp/before
(now use GetInfo to add a Spotlight comment)
$ mdls t > /tmp/after
$ diff /tmp/before /tmp/after
8a9
> kMDItemFinderComment           = "I added this comment"

See?

I have stuff to do and family coming now so if you still have questions I may not answer till tomorrow, sorry.







Sun Apr 12 12:22:13 2009: 6128   TonyLawrence


Actually, I may be confusing things by mentioning resource forks.. that's older OS 9 and before for the most part. I'm trying to find a good article that lays this all out - not having much luck.

There's (link) but that's 8 years old - just before OS X began.

I'll keep looking :-)



Sun Apr 12 12:42:51 2009: 6129   TonyLawrence


This is an interesting thread:

(link)

It's so confusing. We have resource forks, Spotlight, xattr .. so much metadata, so little documentation :-)



Sun Apr 12 12:58:12 2009: 6130   TonyLawrence


Once the Mac OS does kick-off the extraction of metadata from a file, it does so through a Spotlight Importer. Spotlight Importers are plug-ins for the Mac OS that a developer provides specifically for helping files created by their applications to be searchable within Spotlight. Spotlight crawls through its list of changed files, handing each one to the appropriate importer. The importers then read the files, compile a list of metadata, and then hand the metadata back to Spotlight. At this point, the changed file is available for searching within Spotlight.

That's from (link)

Now: where is the metadata stored before Spotlight imports it? Is it "BundleFiles"?

Apparently an app that wishes to give data to Spotlight creates an "importer" for its files: (link)

But that doesn't tell me how an individual file stores its Spotlight related metadata..

Still looking :-)



Sun Apr 12 13:04:04 2009: 6131   TonyLawrence


This seems to be the most helpful

(link)

BUT: that tells developers this

Avoid the use of external files to store metadata content. All critical metadata should be in the same file as the data. The system store of metadata should be considered volatile.

Fine, but the default Spotlight metadata (mdls of showme.txt above) isn't stored in the file. Is it in the resource fork? I don't know..

And I really have no more time for this today :-)



Sun Apr 12 13:23:51 2009: 6132   TonyLawrence


One more thing:

The use of the importer implies that at least some metadata only exists when supplied by the importer - if it is always going to be the same, why store it?

This pdf is an interesting look at a forensics tool and of course it talks about how Spotlight and importers work: (link)







Sun Apr 12 13:31:26 2009: 6133   TonyLawrence


Finally found what I wanted:

(link)

That doesn't help you though..



Sun Apr 12 13:59:49 2009: 6134   TonyLawrence


Just can't help poking around :-)

In my ~/Library/Caches/Metadata I found some interesting stuff. *Some* apps store Spotlight metadata there. Not iTunes, but it has

Billings Microsoft Safari Camino Precipitate com.evernote.Evernote



For example, looking down in Billings (a little invoicing program I looked at once) it has a plist with a Metadata key:

<key>MetaData</key>
	<dict>
		<key>com_marketcircle_projectname</key>
		<string>Repair</string>
		<key>kMDItemContentCreationDate</key>
		<date>2009-03-22T12:10:17Z</date>
		<key>kMDItemContentModificationDate</key>
		<date>2009-03-22T12:21:17Z</date>
		<key>kMDItemDisplayName</key>
		<string>Extreme rework</string>
		<key>kMDItemTitle</key>
		<string>Extreme rework</string>
	</dict>

Presumably there was an importer that would read this to give it to Spotlight but as I removed the app, that's gone.



Sun Apr 12 14:17:20 2009: 6135   TonyLawrence


However, this DOES lead us back to your original issue (finally).

If you want to modify how Spotlight indexes flac files, you'd need to find the Importer responsible. I would assume that's iTunes? I don't know how much luck you'd have there, but it would seem to me that's where you'd need to be.

How that's going to help you play these, I don't know..



Sun Apr 12 14:21:46 2009: 6136   TonyLawrence


Or you'd need a custom importer for flac files like this

(link)



Sun Apr 12 19:34:01 2009: 6141   JamesIsIn


Thanks for all the light reading. Hahaha.

This brings us around to where I wanted to be, in a way. I think the solution lies in creating an MDImport file and giving that to Spotlight. This file will in effect tell Spotlight what to do when it encounters a FLAC file, something like "when you see metadata x in a file mark kMDItemFSTypeCode as 1332176723". What is x? It is whatever piece of metadata Spotlight is finding in a FLAC for which it currently returns a null or 0.

(One of your posts above says Spotlight will create this data when a file is "chaged" but changed in this context could mean "moved to the file system" or even "created".)

I added another comment to my post which contains notes you may be interested in.



Sun Apr 12 20:56:48 2009: 6142   TonyLawrence


You say Spotlight restricts what file types are allowed to do based on kMD (metadata) information.

Spotlight has no such function. An app could use Spotlight to find its files, but Spotlight doesn't restrict anything.

I think the solution lies in creating an MDImport file

Well, maybe. But remember the real issue is importer code. That's how information gets to Spotlight (if Spotlight matters at all here). That *might* read a plist file (as that Billings program and Entourage apparently do) but it might not. Is there an existing importer for .flac files? Does it read plists? It certainly appears that iTunes does not work that way.

I don't know enough about this but I really think you still have this upside down and that something is very confused somewhere. People disable Spotlight regularly - less so since it improved on Leopard but some still do - would they do that if it had anything to do with applications working? Don't you think Google would be full of posts from people who lost iTunes when they disabled Spotlight???

Do you have exactly what that developer said? Maybe you misinterpreted it?





Sun Apr 12 23:03:16 2009: 6144   JamesIsIn


It was from an IRC session:

"
the files themselves are not modified...
macosx stores medainfo [metadata] in separate place on the filesystem, and that's where the change is made, your flacs remain as you made them...
...not in the flac file itself, but in the resource fork associated with that file
"

If I take an image file (Image.jpg) and rename it (Image.flac), then run it through Set OggS I am able to drop it into iTunes (though iTunes doesn't actually add it). I am not able to add a flac (unset) to iTunes as it zips back across the desktop to its former location.

This metadata is thus used by the operating system to determine whether to allow the drag and drop operation. It is seemingly also used by iTunes to determine which backend component to use to perform playback (MPEG's are not handled by QT and a QuickTime movie file is).



Sun Apr 12 23:22:30 2009: 6145   JamesIsIn


Does iTunes use QT for playback? (From the same conversation.)

"
it does but not always...
you'r problem is that iTunes (probably) assumes/requires those files to be mpeg/audio and tries to play them itself
"

Which I confirmed...

"
iTunes shows mpeg in the info for a flac file
"

His reply?

"
as I thought
"

So what needs to happen is to globally lie to iTunes (rather than this current method of piece meal lying). Three-card Monte, anyone?



Mon Apr 13 10:54:17 2009: 6150   TonyLawrence


OK. I don't know how you got all the misinformation about Spotlight from that, but I hope that's behind us now.

There are only two possibilities here: either the file carries the kMDItemFSTypeCode info (in its resource fork, in a plist somewhere or in the file itself) OR the importer code for .flac makes its own decision without any such metadata.

iTunes may or may not use kMDItemFSTypeCode (I have no idea). If it does, where does it get it from? If kMDItemFSTypeCode is not in the resource fork etc. I suppose it COULD ask Spotlight just as you can ask with "mdls".

So.. maybe (and again I have no idea) that's the "Spotlight angle". If so, you really need to know HOW iTunes works. If it gets kMDItemFSTypeCode directly from metadata, you need to find out where that metadata lives and change it. If not (and I suspect this would be the case), you need to modify whatever importer code is responsible for this.

Notice that in the IRC session your developer said that the metadata is "in the resource fork associated with that file". If he/she is correct, than you DON'T need to change the importer code, you only need something that can change kMDItemFSTypeCode in each files resource fork.

Does this all make sense to you now? I want to make sure that you don't still have this notion that Spotlight is some grand file control thing and set you searching in the right place - which is to find out how iTunes decides that .flac is an mp3.



Mon Apr 13 16:07:26 2009: 6160   JamesIsIn


Regardless of where the kMD information is kept (and the resource fork looks to me like a kind of database which is spread throughout the filesystem), it is generated by something outside of anything to do with a particular file. I am under the impression that this is done by Spotlight, but it sounds like perhaps some other aspect of the os handles that.

The Set OggS application will change the TypeCode for any single flac if that flac is run through the application (you could do it with other file types but why would you want to?). Once a flac has been run through Set OggS it can be added to iTunes. QT will play the file without taking this step, but iTunes will try to play the file itself without it (once set iTunes will use QT for playback on this file). My hope was to create a global solution so that the os would assume a particular TypeCode for any instance of *.flac, thus eliminating the need for the OggS app (and circumnavigating its clumsiness).



Mon Apr 13 16:21:52 2009: 6161   TonyLawrence


Resource forks are not a database.

What you are saying is that you want iTunes to pay attention to the extension. Fine - lots of operating systems worked that way and some apps do still. But iTunes doesn't.

I'm thinking you could eliminate the clumsiness by having a Folder Action that ran Oggs on any flac file dropped into it. Wouldn't that meet your needs?





Mon Apr 13 23:04:47 2009: 6167   JamesIsIn


Well, there are two issues as I see it. The DAAP issue and the local issue.

The local issue can at the moment be dealt with using Set OggS (by merely dropping the flac on the app). I was hoping to work toward a better solution (hence our conversation).

The DAAP issue is in no way helped by Set OggS (and neither by any combination involving it). I'm not convinced what I had envisioned would have helped the DAAP matter, but it certainly would have made things simpler for the folks dealing with the local issue. It's possible it could have fixed it, but I am uncertain.

I am also asking around for someone who might be interested in modifying the Rhythmbox plugin for DAAP to make a version set up to lie to iTunes (by masking the MIME type of flacs).

------------------------

Site map     |      Disclaimer

mdfind Copyright © December 2005 Tony Lawrence