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

[Filip Roséen]

Hi Remi,

Thank you for your quick reply.

On 2018-09-26 20:50, Rémi Denis-Courmont wrote:

> Le keskiviikkona 26. syyskuuta 2018, 20.39.19 EEST Filip Roséen a écrit :
> > 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?
> 
> That's missing the point.
>
> The playlist needs the entire tree to show up at once so that shuffling, 
> sorting, etc, oeprate properly.

If one would like to preparse all items, but skip those that take too
long (for reasons such as being read over a "slow" network
connection), the timeout would help with making such decision. It
would then continue to populate the playlist with entities that at
least finished their job within a "reasonable"* amount of time.

* whatever timeout value would be *reasonable* in this case.

> That is how things worked until 2.2.x inclusive.

Didn't `2.2.x` suffer from the equivalent delay in preparsing (not
"showing up directly") if it started to dive into something which
looked local, but was actually remote (like a mounted network share)?

I am a little bit confused by what the actual difference would be
between `2.2.x` and the current branch, if we decide to go back to
`--recursive=expand`, as we per-default do not preparse entities that
is over a protocol we have flagged as not being `ITEM_LOCAL`. The
"mounted samba"-argument would apply to `2.2.x` too, or am I missing
something?

> Playing with the timeout value is not going to solve much if anything.

At least we wouldn't unconditionally be stuck with either *"traverse
everything but it will take loads of time"* or *"remain using
`--recursive=collapse`, and not traverse down deep enough for the
normal use-case"*.

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