This removes the insertion offset parameter to playlist_Add(),
playlist_AddExt() and playlist_AddInput().
intf_InsertItem() was the only occurrence where the offset was zero,
a side effect of how the command line is parsed backward. This is now
done explicitly with playlist_NodeAddInput().
A non-zero positive offset made no sense, since:
- the number of children of a node can change asynchronously while the
playlist lock,
- the back-end asserted or triggered undefined behaviour if the offset
was out of range.
DBus was the only occurrence of this bug (see also #17451 comment:4),
and has been fixed in an earlier change.
In all remaining call sites, the offset was PLAYLIST_END. This removes
the parameter which would otherwise constitute a useless constant.
They are set but never used. In practice, the (following) position
parameter determines whether the item is inserted or appended. A
positive position means insertion; PLAYLIST_END means appendment.
Listen to playlist "input-current" to update the current input_thead_t, and
listen to input "intf-event" to update the current vout. The vout/input don't
need to be fetched when processing an action, this removes one FIXME, but this
adds more lock complexity.
This will be mainly needed for the next commit, in order to listen to mouse
events from the vout.
The function can only fail if the named variable does not exist. The
only case where the error was actually checked was after another check
that the variable exists (Old RC).
That parameter assumed that the query was part of the path. However it
is not, which leads to invalid host name, and eventually failure when
the path is missing. In practice, passing any value other than '?' as
separator would not work properly.
Remaining vlc_UrlParse() call sites without the option separator do not
support query at the protocol level anyway, so they are unaffected by the
change.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>