[vlc-devel] [RFC] Nth playlist rewrite
funman at videolan.org
Sat Mar 15 21:05:31 CET 2008
I love you,
Please accept my modest feelings,
The idea had been running for a while around my mind, so I started this
evening a playlist branch in my local tree to fix the mess in
As you may know it was maintained by zorglub (Clément Stenac), who is
now busy with something else since quite a while now, and I more or less
took his place, fixing some more or less critical bugs (the main reason
being my heavy use of the playlist & media library with my huge music
When I joined you, zorglub was not finished yet with the playlist, and
left it in a more or less finished state.
This not finished state included : memory corruption due to the complex
handling of 2 separate trees: one with nodes, and one without (also
known as flat)
The first thing I started here is removing the flat tree, and leave the
work to display a flat playlist to other modules.
I quickly noticed that I was reverting
[ed0b72e3714ad87cb4e10b9a7239e19b9ef0724e] which reads "Merge back
branch 0.8.6-playlist-vlm to trunk."
So I would like to ask the elders : what was this for ?
- * It is envisioned that a third tree will appear: VLM, but it's not
Was it worth ? Is there some feature I fail to understand, like the
ability to manage VLM through any GUI ?
If this is the case, and nobody is coming to do the work, I'll simply
revert that branch, and statically link the inputs to the playlist, in
order to remove the input_item_subitem_added() UGLY HACK added by
pdherbemont (Pierre d'Herbemont) for the vlc-control API (carrying its
own memory corruptions).
It MAY cause some (external, aka vlc-control) API changes, and afaik
0.9.0 is already bringing changes here, so I want to have this ready for
the next release, hopefully with the help of pdherbemont
The playlist internal API is quite complex, and some stuff (a.k.a
preparsing and metadata fetching, such as album art) is badly
implemented/splitted across input and playlist.
Since I care about that last stuff too, it's an occasion to factorize it
in the right way, because I never took the time to read the whole code.
Stay cool, I'll do that on my PRIVATE tree (which I'm ready to share
with interested people) and will not merge it without your approval.
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the vlc-devel