<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta http-equiv="Content-Style-Type" content="text/css" />
  <meta name="generator" content="pandoc" />
  <title></title>
  <style type="text/css">
      code{white-space: pre-wrap;}
      span.smallcaps{font-variant: small-caps;}
      span.underline{text-decoration: underline;}
      div.column{display: inline-block; vertical-align: top; width: 50%;}
  </style>
</head>
<body>
<p>Hi Remi,</p>
<p>On 2018-09-26 19:24, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le tiistaina 25. syyskuuta 2018, 23.33.13 EEST Filip Roséen a écrit :</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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`).</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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).</code></pre>
</blockquote>
<p>Agreed.</p>
<p>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 <code>--recursive=expand</code> if the underlying access is too slow?</p>
<p>Not sure if <code>5000ms</code>, 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.</p>
<p>If that could be a suitable middle ground, reverting back to <code>--recursive=expand</code> 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)?</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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;</code></pre>
</blockquote>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>   2. change the default value of `--recursive` to `expand` instead of
      `collapse`.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>If others are interested, the behavior changed as part of the below linked commit (going from “expand” to “collapse” as the default argument for <code>--recursive</code>):</p>
<ul>
<li><a href="http://git.videolan.org/?p=vlc.git;a=commit;h=4455e6d2935a498e02ac3c6ac144f0525d2e01f0">input: handle recursive parsing in preparser</a></li>
</ul>
<p>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.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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?</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>Best Regards,<br />
Filip</p>
</body>
</html>