[vlc-devel] What should we do about recursive preparsing?
filip at atch.se
Wed Sep 26 19:39:19 CEST 2018
On 2018-09-26 19:24, Rémi Denis-Courmont wrote:
> Le tiistaina 25. syyskuuta 2018, 23.33.13 EEST Filip Roséen a écrit :
> > Given that the bug was present for such a long time, it seems many
> > users have started to rely on (and like) the broken behavior present
> > in versions prior to `3.0.4` (which should only have been enabled on
> > `--recursive=expand`).
> No. By and large, users are not used to any broken behavior. They are used to
> the old behaviour of 2.2.8 and earlier. The difference is much more noticeable
> with 3.0.4 than with 3.0.3, so the complaints come now.
> The users are used to the then reasonable behaviour that VLC has had for over
> a decade until version 2.2.x (inclusive). That is to say, extracting
> directories recursively (except for infinite loops) in a single go so that the
> playlist shows and shuffles properly.
> But of course, that behaviour is not really compatible with network browsing,
> which was not supported in 2.2... And thus you have to choose between pissing
> users off one way (no expansion) or another way (no/crappy network support).
Given that we have a preparser timeout, do you think it is a good idea
to rely on said timeout, which would in turn prevent recursing to deep
on `--recursive=expand` if the underlying access is too slow?
Not sure if `5000ms`, the current default value, is suitable for such
"keep on traversing unless too slow" (honestly it feels a bit high),
but while writing this reply the idea came to mind.
If that could be a suitable middle ground, reverting back to
`--recursive=expand` alone might be a good enough fix as I assume the
network browsing your are referring to refers to things that look like
they are local, but are actually remote (like a mounted smb-share, or
> > I stated that the broken behavior could already be relied upon, but I
> > failed to see just how wide-spread this actually was. Below is a link
> > to the relevant patch where I mention it.
> > - https://mailman.videolan.org/pipermail/vlc-devel/2018-July/120454.html
> > So, now we need to decide how we handle this. From what I can tell
> > there are two viable paths to walk, either we;
> > 1. leave the behavior as it currently is, and do our best to educate
> > users that they can change the recursive behavior (and get back to
> > the one in `3.0.3`) by using `--recursive=expand`, or;
> > 2. change the default value of `--recursive` to `expand` instead of
> > `collapse`.
> Of course the default should be expand, like it was in version 2.2.8 and
> earlier. But at the same time, the recursion has to avoid loops and insanely
> deep depths.
If others are interested, the behavior changed as part of the below
linked commit (going from "expand" to "collapse" as the default
argument for `--recursive`):
- [input: handle recursive parsing in preparser
It took me a while to find, so if someone else is about to do the same
commit jumping, I hope this will save you the trouble.
> > I have no idea how many silent complaints we have, nor is it easy to
> > see how many users that actually appreciated the regression-fix. Given
> > the activity on *trac*, it seems to imply that most users actually
> > want to do full recursion by default (though it is as with most things
> > a mere guess).
> > What do you think?
> With the benefit of hindsight, my regression report should evidently have been
> taken more seriously before the directory rework was merged and 3.0 was
> frozen, so the design could have taken the issue into account.
> But even then, I do not know if/how this can be solved without either dropping
> network browsing or making it horrendously slow. It is only worse with the
> extra constraint of 3.0 API/ABI stability.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel