Whoohoo!
We just committed the support for write back in master.
What is it?
Tracker has a limited capability to write metadata back into the data resource. In case of a file that means writing it back into the file. For example writing some of the metadata the user sets using a SPARQL Update back into an MP3 file as ID3 tags.
Which ones do we support already?
Right now the write back capability is under development and only supports a bunch of fields for a few XMP formats (JPEG, PNG and TIFF) and the Title of MP3 files. In near future we will start supporting increasingly more fields.
Documentation?
For people who want to write support for their properties and file formats, read the documentation.
Party like it’s 2009!
How about a usable stable release for a change? Pushing new features without having any adoption is kind of pointless…
@Pavel: We’re working on that. Expect a stable 0.8 series in a month or two, maybe three. There are weekly 0.7 releases, but those are indeed unstable. We still have about four major features to finish before it’s worthwhile to do a stable release. But we’re working hard, we are gaining contributors weekly and most importantly: you’re very much invited to help us.
Are you using id3lib for this? Please don’t. It has been unmaintained for over 6 years and writes broken tags. Please use TagLib or gstreamer’s id3tag.
@Robin: we’re not religious about the id3lib usage. The MP3 write back module was only done as a proof of concept to be honest. So if you want to rewrite it using TagLib, go ahead (shouldn’t be hard, just filling in a function and setting the build environment right, removing the id3lib autotools stuff, etc).
I once read, the “patches welcome” stuff is only legitimate for enhancements.
So, if someone tells about a data corruption issue, maybe that should be taken more seriously.
No offense please, pvanhoof, you write good software I guess, but this just troubled me ;)
do not want
@mike: Ok, point taken. At this moment isn’t tracker-writeback activated, and 0.7 is unstable anyway. But we’ll consider either switching to TagLib or disabling the MP3 writeback for now.
This is really great news. I feel the time coming nearer to replace all the filesystem crawling of every photo application and every music application with software that can instantly access all relevant filesystem meta-data.
And now having the meta-data also in the files themselves is really great!
This is really, really geat! Thanks.
Will it allow per-file type opt-out for write-back? For example, I consider my mp3’s as living data (reclassify, re-rate, whatever) so more meta info from another source is great. But I want to keep my photos in their original form, so I wouldn’t want them modified.
It’s less bothersome if only additional info is in the working set, but I’ve learned to externalize meta data because e.g. F-Spot overwrite my camera name with its app name even when doing simple operations like rotate…
I hope this is turned of by default. I would hate to see this program alter the modification dates and checksums of files. Some people use these files as a key in encryption utilities.
Have fun with the bugs where you destroyed 10 Gigs of private photos because your JPEG writeback was broken just in this one release. And of course the user will not have backups.
I would be very careful to add such an option if I wasn’t sure that my application had NO bug AT ALL.
And I’m pretty sure your testsuite is either a joke or nonexistant.
@Benjamin: Interesting point.
But the same could happen when using a music or something manager that writes back.
I think having some track01.mp3 with no additional metadata in the filesystem (imagine some download from some bands website) and then all the Metadata is stored only in Tracker is not very good.
So as long as it works as expected, it’s good :)
But with downstream patching and so forth, this really started to scare me, even before it was available..
@Benjamin: note that we only do write back for sparql update queries coming from the user. Not for update queries coming from the miners. So we wont be writing back into all your files. Only when you do a sparql update query and there’s a property that is marked up for write back, and you’re running the tracker-writeback software. We will of course test things, and we don’t think it’ll be as bad as you made it sound :) (sounds a lot like unneeded panic, to me. We’re not insane people and we know what we’re doing, don’t worry).
PS. While exempi might corrupt a file if there’s a bug in it so can EVERY piece of software do that. For example libc and the kernel with its EVIL write() might corrupt your entire filesystem! If you open() the wrong device, easily even. Perhaps you should stop using computers if you are so afraid of this, Benjamin? I know you know that what you said makes no sense. You’re just spreading panic for no reason.
@John: good point, i’ll think about how I can let tracker-writeback ignore specific files. If you have suggestions, let me know.
@mike: the idea behind this feature is that music players use SPARQL and Nepomuk exclusively, and no longer care about formats that do ID3. They just write SPARQL Update queries to tracker-store, and to get a list of songs they do SPARQL select queries on tracker-store. And they enjoy life without having to implement the quagmire that ID3, with its 4 different versions, has become.
Metadata should also NOT be file per file: you can’t make relationships between resources like files that way. Relationships are the most important kind of metadata. Much more important than just “fields” (like what ID3 is about).
@pt: I fail to see any relation with encryption keys. Any music player that writes id3 tags into files changes your files too. That it does it via tracker-writeback instead makes no difference whatsoever for your encryption software. Stop going into panic mode.
@pvanhoof: You’re right, and I think the panicking is unnecessary by now.
And it’s is truely way more useful, when I can for example select a song and say “give me every song from the album this one is on”, instead of traversing ALL my music files, looking for which one match the album-tag.
But before sending a file via mail, I would use a write-back.
Yeah, maybe that should be integrated into evolution and empathy. Update metadata before letting the file leave the machine.
@pt, @pvanhoof: I also use a lot of filesystem magic that relies on compare-by-hash, and timestamps etc for syncing and versioning etc. However, I don’t think write-back as suggested by pvanhoof will get in the way. I just consider the tagged/updated file a later version of the file, and that’s that. It would be nice to have the ability to mark certain files as immutable as John says; sometimes you really want certain files to always match certain checksums.
@pvanhoof: a few more small questions about tracker’s triple store:
– could it support versioning of metadata?
– could it support signing (as in RSA) of a bunch of statements?
I don’t know enough of about it to know if there’s good ways of doing this with RDF (using reifications, maybe?) – but I’m sure it must have come up in tracker discussions already.
Awesome!
My wife wants to do some photo management and I offered to write a simple workflow app that used Tracker + tags for grouping and sorting. She loved it, but when she found out that the tags don’t follow the files around, she was not so enamored. I’ve been plunging ahead anyway, but it’s tough going (I don’t think Tracker indexes IPTC tags, for example). Writeback would be a godsend and would finally make all of this portable, simple, and painless.
So thanks, guys, and keep on chugging!
P.S. This would, of course, be implemented in Vala. :)