mdfind
and power than the GUI Spotlight does, but before we get to that, let's look at where Spotlight (and mdfind) stores its index. We need a root shell to get to the Spotlight directory:$ 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
The ContentIndex.db and .store.db are Spotlight's files, but the _exclusions.plist is an ordinary text plist file.
# cat _exclusions.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple
Computer//DTD PLIST 1.0//EN"
"http://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>
#
Notice the EXCLUSIONS list? You can add to that with the System Preferences tool, but this is where it is actually stored. However, as we'll see in a moment, this is NOT all that Spotlight (and mdfind) ignores. You need to be aware of that when using mdfind.
For the simplest use, just do "mdfind whatever". Can you use that in a script? Why not?
for i in `mdfind Stuff` do scp $i me@somewhere.com:$i done
But mdfind is much more powerful than that:
mdfind 'kMDItemTextContent == "*Seneca*" && kMDItemFSName != "*emlx"' mdfind 'kMDItemTextContent == "*Seneca*" && kMDItemContentType != "com.apple.mail.emlx"'
That's searching metadata. What metadata can you search? Well, anything that's available and "mdls" will show you that:
$ 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)
What mdls (and thus mdfind) sees can change:
$ 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)
Just because the file is named differently, mdls and mdfind will treat it completely differently.
Permissions can also affect metadata, which in turn changes how Spotlight and mdfind see a file:
$ 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)
I put the string "fogpr1" in a file, and then copied it to a few different names. Using "grep" finds all of them, but "mdfind" does not:
$ 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
Spotlight and mdfind also ignore "." files, even if you have told Finder not to ignore them:
$ defaults write com.apple.finder AppleShowAllFiles TRUE $ killall Finder
mdfind is a little strange with regard to "."'s in other ways: a nice little option is (for example) to say "mdfind -onlyin /tmp foo", which would search for foo but only in /tmp. You would naturally expect to be able to say "mdfind -onlyin . foo", but that won't work. Use "mdfind -onlyin `pwd` foo" instead.
For more technical information on Spotlight and mdfind, see http://arstechnica.com/reviews/os/macosx-10.4.ars/9 and http://developer.apple.com/macosx/spotlight.html.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
Inexpensive and informative Apple related e-books:
Take Control of Parallels Desktop 12
Take Control of Preview
Take Control of Security for Mac Users
iOS 10: A Take Control Crash Course
Take Control of Numbers
More Articles by Tony Lawrence
Find me on Google+
© 2009-11-07 Tony Lawrence
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:
For example, if I add a spotlight 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:
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).
------------------------
Printer Friendly Version
mdfind Copyright © December 2005 Tony Lawrence
Have you tried Searching this site?
Support RatesThis is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version