<!doctype html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body>Hi,<br><br>I don't think SMB streaming (as opposed to downloading) is a lost cause. I do think SMB streaming with libsmbclient implementation is a lost cause.<br><br>The prefetch plugin already gives maximum flexibility, within its own constraints, to the underlying access to choose how many bytes it returns in a given read, as does the core. It can't get any better without increasing the prefetch buffer size (and we have a setting for that already).<br><br><div class="gmail_quote">Le 6 février 2020 14:00:55 GMT+02:00, Thomas Guillem <thomas@gllm.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>I quote you:<br></div><div> <br></div><div> "Badly behaving streams wait for the whole requested amount and do not<br></div><div> perform any pipelining/buffering (e.g. CIFS, probably SFTP)."<br></div><div><br></div><div>Why SMB, NFS, SFTP are badly behaving streams ? For me it is just like local I/O. You read only what you request.<br></div><div><br></div><div>On Thu, Feb 6, 2020, at 12:28, Rémi Denis-Courmont wrote:<br></div><blockquote type="cite" id="qt"><div>Hi,<br></div><div><br></div><div>The access is free to return any non-zero size up to the requested read size, so the requested read size can never be too big. It can only ever be too small, and that's exactly why this patch made sense and still makes sense.<br></div></blockquote><div><br></div><div>At the VideoLabs office with 1TB network, I don't care, but at home with a shitty 2MB wifi, reading chunks by 16MB is terrible. Specially when 99% is trashed since the demuxer will only ask few kB and seek.<br></div><div><br></div><blockquote type="cite" id="qt"><div><br></div><div>But if you need to worry about the read size, you've already lost.<br></div></blockquote><div><br></div><div>Why am I lost ? Are you saying SMB streaming is a lost cause ? <br></div><div><br></div><blockquote type="cite" id="qt"><div>Small read size will cause bandwidth problems and large read size will cause latency problems.<br></div></blockquote><div><br></div><div>Can we find a solution for both cases in the core or the cache modules ? I really don't see why I should cap the read size of all "badly behaving" streams.<br></div><div>If I need to do that, what size should I use ? Should I add one more option (likely the same that you removed in prefetch) ?<br></div><div><br></div><blockquote type="cite" id="qt"><div><br></div><div class="qt-gmail_quote"><div>Le 6 février 2020 12:33:55 GMT+02:00, Thomas Guillem <thomas@gllm.fr> a écrit :<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:0pt;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><pre class="qt-k9mail"><div>Hello,<br></div><div><br></div><div>This commit and this one on vlc-3.0 : <a href="https://git.videolan.org/?p=vlc/vlc-3.0.git;a=commit;h=3dfa6d4ddd0922552e6575ded416f62b8ce828f5">https://git.videolan.org/?p=vlc/vlc-3.0.git;a=commit;h=3dfa6d4ddd0922552e6575ded416f62b8ce828f5</a> are making the smb2 module ultra slow, around 10 times slower.<br></div><div><br></div><div>The read size requested by prefetch is really big. This make probing / seek ultra slow since a lot of small read() are executed (reproduced with mkv and mp4).<br></div><div><br></div><div>So, I have one big question: Is the smb2 module supposed to not listen to the size argument and always read a smaller size ?<br></div><div>How can I decide the read size then ? Should this size be decided by the core of cache modules instead (like before) ?<br></div><div><br></div><div>PS: There is not the same problem with the libdsm module since the max read size is caped inside libdsm.<br></div><div><br></div><div>On Fri, Apr 20, 2018, at 15:45, Thomas Guillem wrote:<br></div><div>> <br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(114, 159, 207);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>On Fri, Apr 20, 2018, at 15:05, Rémi Denis-Courmont wrote:<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(173, 127, 168);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>And I don't really want to hear a commit is dangerous from somebody that <br></div><div>backports stuff as lightly and quickly as you have lately.<br></div></blockquote><div>That is a bit close to false accusation IMHO.<br></div><div><br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(173, 127, 168);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote">This was sent for review, and it was *not* backported.<br></blockquote><div>Yes and I was OK with it. It's just lately that I found out that this <br></div><div>commit might be dangerous.<br></div><div>Dangerous as changing the behavior of some access modules and maybe <br></div><div>induce some new bugs (that are access related).<br></div><div><br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(173, 127, 168);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>-- <br></div><div>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser <br></div><div>ma brièveté.<hr>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></blockquote><div><hr>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></blockquote><div><hr>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></pre></blockquote></div><div><br></div><div>-- <br></div><div>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. <br></div><div>_______________________________________________<br></div><div>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div>https://mailman.videolan.org/listinfo/vlc-devel<br></div></blockquote><div><br></div></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>