<!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;}</style>
</head>
<body>
<p>Hi Rémi,</p>
<p>On 2017-03-29 22:46, 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 keskiviikkona 29. maaliskuuta 2017, 21.38.43 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> Hi Rémi,
On 2017-03-29 22:13, Rémi Denis-Courmont wrote:</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le perjantaina 24. maaliskuuta 2017, 3.28.31 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> This will cancel any pending request for preparsing the relevant
playlist_item_t as preparsing the entity:
- is redundant since we are about to start playback,</code></pre>
</blockquote>
<pre><code> Yes but I don´t see how this prevents the next two problems short of
unwarranted sunny day case timing assumptions.</code></pre>
</blockquote>
<pre><code> There are other paths where the problem might arise, but for all of
those cases the preparsing does not originate from the relevant code
of the below listed files:
- `src/playlist/thread.c`
- `src/playlist/engine.c`
- `src/playlist/item.c`
What is described in the commit message you are referring to is what
it addresses, not cases from outside of the scope of the changes.</code></pre>
</blockquote>
<pre><code> Sure, it addresses those cases. But those look like the sunny day cases of a
more general problem, which this does not fix.
I don´t like to add complexity to conceal a bug instead of fixing it. We have
had a LOT of problems with that approach and race conditions in VLC in
general, and in the playlist in particular.</code></pre>
</blockquote>
<p>I do not think that these changes conceals the bug in any case, it addresses the issue as it is described. It also does not prevent any future fixes of the relevant problem.</p>
<p>I have branches that refactor the playlist implementations far more extensively than what has seen the light of day during the past year in terms of VLC development; I am however saving that for after <code>3.0.0</code> due to the changes being (as aspected) far more intrusive.</p>
<p>There is nothing in my mind that would ever stand behind hiding a bug further down in the stack, but as stated I cannot see how the relevant changes in this patch-batch does that.</p>
</body>
</html>