[vlc-devel] What should we do about recursive preparsing?

[Filip Roséen]

Hi Remi,

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).

Agreed.

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
equivalent)?

> 
> > 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
    ](http://git.videolan.org/?p=vlc.git;a=commit;h=4455e6d2935a498e02ac3c6ac144f0525d2e01f0)

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.

Best Regards,\
Filip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20180926/a0f36f9b/attachment.html>