[vlc-devel] Media Library Auto Updating Mechanism

[Jean-Philippe André]

Hi,

Any insights, anyone?

On Wed, Aug 25, 2010 at 10:42 AM, Srikanth Raju <srikiraju at gmail.com> wrote:

> Hello all,
> I need to ask a question about the architecture of the Media Library
> module.
>
> Essentially, the Media Library(ML) holds a bunch of ml_media_t
> objects(media) inside a SQLite database. There needs to be a mechanism where
> medias corresponding to input_item_ts(input item) get updated when the
> input_item changes while vlc is running. Such as when the user brings up the
> information dialog in the playlist or some other mechanisms( lua so on ).
> There are two ways of doing this:
>
> #1) This is what is currently implemented. We have a list of input_item_ts
> that are being watched for meta change events by the ML module. A loop
> thread would go over this list and garbage collect these input_items and
> update into the ML any input_item_ts that were updated. The upside of this
> is that threads which update input_item_t don't have to update in the ML by
> running the SQL, hence there would be no slowdown of that thread. The
> downside is that, now every time something obtains an input_item_t it must
> register with the ML module to watch that item so as to ensure the updates
> gets carried into the ML.
>
> #2) I was thinking it would be cool if we modify input_item_t such that on
> instantiation, it registers its own meta change events with the ML to that
> it gets updated on the fly. This would mean we can cover all interfaces with
> the ML without modifying the code of every one of them and having each of
> them register with the watching mechanism. However, the downside is that it
> will slow down the executing threads, as they will need to query the ML.
> However, I doubt it will be much of a concern, because in a real life
> scenario, the slow down will be negligible as SQL will run pretty fast. This
> also means we won't need all the complex garbage collection of these
> input_item_t and the code will be much simpler.
>
> Any inputs on what approach should be taken?
>

With #2 I'm afraid too many non-media items (subtitle tracks, folders, ...)
would be sent to the media library module. I am not sure it would be that
easy to discard them at input_item creation (as at that moment we can not be
sure of the type of that input).

But I agree the code for #1 is quite complex :-(

Best,

-- 
Jean-Philippe André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100902/9a50182f/attachment.html>