Media, MediaList, MediaListPlayer unsatisfactory implementation/API

Question

There are some outstanding issues with regards to Media, MediaLists etc.

There is an awkwardness that sometimes the media player "owns" a Media instance, and sometimes it is the client application.

MediaList needs special attention, in general and specifically for events. The subItemTreeAdded and subItemAdded currently pass libvlc_media_t on their listener method, should this be wrapped in a Media object?

Need to review the whole Media/MediaList shebang with particular attention to who "owns" the media, what is retained/released natively and what must be released by vlcj or the client application.

Also, when pulling a Media instance out of a MediaList do we want to return the same Media instance each time (the same that was added) or a new instance? Use-cases are unclear.

The CueTest test/demo class is a good test for the MediaList, currently it hard-crashes when trying to play a particular sub-item.

When using the DefaultMediaPlayer, the MediaList instance can be null even if there are sub-items created.

该提问来源于开源项目：caprica/vlcj

Answer 1

The reason for the hard crash...

If the option was not set on the media player to auto play sub-items, then the sub-items list was never set on the associated media list player. Consequently crash.

It looks like auto playing sub-items should no longer be an option, if we use media player and an associated media list player correctly, the sub-item will just start (likely always what you want anyway) and so we should always just set the list.

Note that setting the list on the associated media list player starts playing.

It would actually be really nice to get rid of the API to auto play sub-items and just have it be the natural behaviour.