[jmarshall]

It'd take a few seconds to index probably, depending on the connection. If you do it via a script that could be backgrounded. You don't need a relational database really for this - you only need a path to id mapping that's preserved, for which a flat file would suffice? That could also act as the cache for directory listing so that you only update when you have to.

I guess my main point is I'm not sure that we'd benefit from having a lot of code added to the main sources to support karaoke, when it wouldn't benefit all that many users. Thus, a script or plugin seems the most obvious way to do the user interface side of it. Obviously playback support is something that the core should support, however.

Cheers,
Jonathan

[oldnemesis]

Yes, a plugin is also an option (script unfortunately is not as my knowledge of Python is kinda limited). Do plugins have access to functionality like MusicInfoTag* classes and full user interface integration (like adding options to Settings window)?

[jmarshall]

I'm not sure why you'd need to alter any settings windows? Plugins basically function purely as a virtual directory listing device, though given they're python they can in some respects do more than this. They have their own settings available to them via the context menu. And yes, they can set some info tag members at least - I'm not sure all of them are available or not, but most of the useful ones are.

Cheers,
Jonathan

[oldnemesis]

Thank you for clarification. Isn't there a C/Cpp interface as well? My relationship with Python was far from being perfect

[spiff]

currently no. it's definitely something to be considered though

[oldnemesis]

Understand. So is it possible to still have it in the main source tree, but compile it in only for those who explicitly enable it with --enable-karaoke or something like this?

[spiff]

yeah, it would be a separate .so.

see CPluginDirectory (this is the python version - you'd need to do an equivalent c interface)