[vlc-devel] What should we do about recursive preparsing?
Rémi Denis-Courmont
remi at remlab.net
Wed Sep 26 20:22:16 CEST 2018
Le keskiviikkona 26. syyskuuta 2018, 21.12.44 EEST Filip Roséen a écrit :
> 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.
Again, Reasonable is no more than ZERO.
ALL items in the hierarchy should be inserted retaining the playlist lock.
Otherwise shuffle and what-not does not work properly. That or the playlist
code must be significantly reworked. That might actually be the way to go in
4.0, but that seems impractical in 3.0.
> > 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)?
And again, in 2.2, expand meant expand in-line/immediately. Now expand means
collapse until the preparser expands.
--
雷米‧德尼-库尔蒙
http://www.remlab.net/
More information about the vlc-devel
mailing list