<!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 Marvin,</p>
<p>On 2016-12-11 11:19, Marvin Scholz wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> I have the same opinion as Pierre, that this would be wrong. This is not what
this flag is intended to do, or if it is, it is incorrectly advertised to the user.
The flag is just intended to block searching for unknown metadata, but in no way
to prevent external metadata, that is not considered local, to be fetched and
would probably confuse a lot of users, me included, if that would be the
new behavior.</code></pre>
</blockquote>
<p>It might not come as a hugh surprise that I am not of the same opinion.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> If a playlist, title or lua playlist script explicitly states external metadata
for an item, it should still be fetched even with `--no-metadata-network-access`
IMHO.
What should _not_ happen, is looking it up with external art fetchers (google or
other services), if the flag is set.</code></pre>
</blockquote>
<p>The issue currently being discussed is, imo, a different one to which the patch was addressing.</p>
<p>There are a lot different ways of dealing with what you are talking about, among them:</p>
<ul>
<li><p>If the flag is poorly named, we should definitely rename it.</p></li>
<li><p>If network resource should always be allowed to query network entities, we should implement such feature.</p></li>
<li><p>If we need a way to explicitly mark something as “safe” or “necessary” when it comes to art download, we should implement such a mechanism.</p></li>
</ul>
<p>To me, the privacy concern that comes with playing something that you have stored locally, and playing something over a network based service (such as soundcloud) are two completely different set of problems.</p>
<p>Best Regards,<br />
Filip</p>
</body>
</html>