[vlc-devel] Can anyone tell me why this patch was done?

[Pierre d'Herbemont]

2009/8/19 Rémi Denis-Courmont <remi at remlab.net>:
>
> On Wed, 19 Aug 2009 12:27:05 +0200, Jean-Baptiste Besnard
> <jbbesnard at actech-innovation.com> wrote:
>> I tried medialistplayer too but it seems quite unstable.
>
> Yes. The whole idea is dead born due to excessive complexity. Even if
> LibVLC were implemented "right" (if at all possible), there is almost zero
> chance that LibVLC-based application would get it right, because thread
> safety and event handling w.r.t. the playlist.

This is wrong. I have built a full blown application based on VLC
media_list. They were designed with this goal. And this was
successful, with some glue around libvlc.

The application missed one feature I didn't require, which is media
queuing in a media_player. This is achieved by the media_list_player
in a few lines of code. Yet, I never had the need nor the chance to
test it :)

>> As to me the media_player should have a working playlist
>> at the API level as it is quite a basic functionality
>> but this would involve more work.
>
> I completely disagree. Implementing a private playlist is a lot simpler for
> a UI "front-end" to LibVLC, than synchronizing the UI with the LibVLC
> playlist. The countless playlist related remaining or recently fixed bugs
> in the various VLC built-in interfaces, and the complexity of the VLC
> playlist code proves the point.

No, it does only prove that VLC playlist API is a mess. (But the
implementation has started to become mature though).

> It is a LOT simpler to push the next item when the previous item ends. In
> fact, the reason why LibVLC provides a media list abstraction is to support
> service discovery and playlist file parsing. But it has failed miserably.

Service discovery works fine in LibVLC. I have been using this for years.

That said. VLC playlist API and media_list API are not designed for
media management. If they are, they are completely out of date
regarding the state of art.

Pierre.