<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<ul>
<li>if we have a playlist set to loop that contains one item which result in ERROR_S, this patch will completely stop the playback - even if there are other playable items in the list.</li>
</ul>
</blockquote>
<p>No, this will prevent the current failing item to be opened automatically. Users will be still able to manually open it. This don’t prevent next items to be opened too.</p>
</blockquote>
<p>It will halt the next time (not the first) an item with b_error is hit, I just tested with the following setup (after applying your patch):</p>
<pre><code>+/experiment% ls -lah
total 7.2M
drwxr-xr-x  2 refp refp 4.0K May 24 11:17 .
drwxr-xr-x 11 refp refp 4.0K May 24 11:16 ..
-rw-r--r--  1 refp refp 7.1M May 24 11:17 existing.mp3

+/experiment% vlc-devel -L existing.mp3 non-existing.mp3</code></pre>
<p>The above will first play <code>existing.mp3</code>, then try to play <code>non-existing.mp3</code> (which will of course fail), it will then play <code>existing.mp3</code> but when it reaches <code>non-existing.mp3</code> a second time; everything will stop.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>If “Repeat All” or “Repeat current Item” option are set. The same failing item will be opened in loop. This might be what most expect us to do. I do not think that looping items should depend on whether there is an error when we try to play them, because there is nothing saying that the error will remain next time we try to do it. We should trust that the user knows what it has asked us to do, and even assume that any input that we are asked to play should be played (even if this results in an error). Proving that the underlying bytestream does not change before the next time we theoretically would have played the item is impossible, and we can also not prove that an access that fails one time, always will fail. One alternative way to handle this issue <em>might</em> be to have the playlist- thread temporarily “sleep” (in terms of playing next item) for a logarithmic (increasing) duration of time it if notice that no item in the current list can be played.</p>
</blockquote>
</blockquote>
<p>I like this idea.</p>
</blockquote>
<p>It is quite resonable, though it should probably be opt-in (or at least possible to opt-out).</p>