[vlc-devel] [vlc-commits] playlist: service discovery nodes must set flags (refs #16923)

Pierre Ynard linkfanel at yahoo.fr
Thu Nov 17 06:57:29 CET 2016

> vlc | branch: master | Francois Cartegnie <fcvlcdev at free.fr> |
> Sun May 8 15:51:33 2016 +0200| [a9b1f3f3916a896f30bc4f2bbedfacd0867f34f0] |
> committer: Francois Cartegnie
> playlist: service discovery nodes must set flags (refs #16923)
> RO and must stop playback on failure
> > http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=a9b1f3f3916a896f30bc4f2bbedfacd0867f34f0

This breaks deletion of SD playlist nodes, after it's been somehow
working that way, maybe by accident, for 6 years. Now, repeatedly
loading and unloading the same SD module, from the CLI for example, adds
and leaves a stray playlist node every time. Certainly that's not a
desirable behavior.

I guess I get the point of the skip flag, but I'm not sure about the RO
flag, and sources are elusive. Archeology shows it has a bit of a bumpy

In 2004, the RO flag gets introduced in the SAP SD.

2 months later, more RO flag and the b_force parameter gets passed by SD
modules to delete playlist node, for the express purpose of making sure
it gets removed.

In 2006, SD node creation, with the RO flag, gets moved from SD modules
to the core.

In 2007, SD node removal is added in the core, but without the b_force
parameter. I haven't checked if forced removal was still ensured by
individual SD modules.

In 2010, the RO flag is apparently lost during a refactoring in the
core. Node removal works.

In 2016, the RO flag gets brought back along with the skip flag,
apparently for the sake of putting it back like before.

Can we explain the use of the RO flag? I do see the reassuring benefit
of preventing the user from deleting SD nodes while the SD is still

And then can we either pass b_force when stopping an SD, or stop setting
the RO flag?

Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

More information about the vlc-devel mailing list