On Sat, Jul 29, 2006, EV wrote: > > I did a little experimenting and taglib seems work okay with > > just the header which always seems to be much smaller than 4k. > > Mp3s may have only trailer tag areas (no header tags).
Really? That's insane! Can't you just pretend that they don't exist and leave them unsupported? I don't own any MP3s so I'd be fine with that! :) > > The easy method would just be to write a temporary file into > > /dev/shm on the first write call and pass this along to taglib. > > Agree. /tmp/ can be used as a back-off method. We can go this > direction already. > > However there is a little difficulty: to avoid breaking > reentrant operation, we need a different temporary filename for > each ongoing open-write call. And the name must be kept in the > stack memory (we might need to open the file after the first > write chunk and close it upon the clossing call). Should be easy enough. I presume that FUSE passes around pointers for that kind of thing. Are you sure that the name has to be passed around and not just a file descriptor? > > [...] No, I meant the file that is being written *to*. > > This is what I was meaning too! of course, the *from* file may > just be unexisting... > > > We know that because we are the ones doing the writing! > > Yes but, as I said, I've not found how to refer to a file created > by FUSE/lkarmafs from within lkarmafs -- yes, I know it is quite > strange... You can easyly access files outside the lkarmafs > mount-point but not those within the mount-point tree. Now I'm really confused. You mean the fids0/_000??/??0 file? But FUSE itself isn't involved in that side of things at all. It's all done by libkarma. ??? > > libkarma may not have an interface for this currently, but it > > would be pretty trivial to add. Only works for USB, of course. > > Not really. Once a file appears under the (USB or Ethernet)) > lkarmafs-mounted directory structure, you can run e.g. id3v2 to > get the tags, but only from a process different from the one > running lkarmafs. Oh, you mean that the karma pearl interface will return the actual tag info from a query rather than the the fake version that you wrote? If that's the case then implementation is easy and you don't have to deal with any of this temporary file garbage. Surely that can't be the case, though. If this was true then why wouldn't the karma just use this info itself? If that's not what you are talking about then I am utterly confused again. Surely all id3v2 calls are done via lkarmafs which in turn just queries the karma. Please explain. Keith. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-karma-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
