On Sat, Jul 29, 2006, EV wrote: > > 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. > > I know it is confusing... and my English surely adds to it ;) > > Let's try again. Let myBestTune.mp3 be a tune file in your host. > Using, e.g. 'id3v2 -l myBestTune.mp3', you get: Title: "my best > title", Artist: "my prefered artist", Album: "the best one", etc.
[...] Oh right, now I get it. Our problem is that things like taglib and the rid generation code need to be passed a filename, which we don't have since we are only given raw data. However, lkarmafs itself provides a virtual filename which could be passed to these function calls instead. Very cunning. Well, we have most of the pathname because it is passed to us by FUSE. The only thing that is missing is the mountpoint. I couldnt find any sensible way of getting that via fuse either. But we can cheat. The mountpoint is passed in as one of the initial arguments. We just need to determine which one it is and then store it somewhere for later use. Bingo. Problem solved. No messy temporary files. No distinction between USB and ethernet. There still needs to be a little bit of care taken since the subsequent open() performed by the function call will launch a new thread, but that should be easy enough to handle. I'll knock up something tomorrow. 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
