Hi, Make sure you CC the bug number when you reply, so that other people can see your comments.
On 08/02/18 14:26, Marc Becker wrote: > Hello James, > > newer upstream LUA code supports direct urls for playlists, v0.23 code does > not. > To my knowledge our (base) code forces calls 'youtube-dl' again for each > playlist > entry by adding a 'ytdl://'-prefix. > So FOR THIS VERSION it should not be necessary to check a url when CREATING a > playlist entry. It is certain to get to filter entries (again) due to their > prefix. > > So in short, keep the original: >> playlist = playlist .. "ytdl://" .. site .. "\n" > and only filter urls that are returned directly (line 270 ff.) or added to > EDL playlists. > > While I am aware this is against "fail early" practices it is closest > in control flow logic to the original code and there might be cases/sites > where the 'ytdl://' prefix is needed due to the older LUA logic. [replied to lower down] > Additionally: > If somebody manages to slip in a multiline value for 'site' it's over anyway… > Up-to-date upstream code does not really handle this either. > Let's hope the downloader validates its input. That probably warrants some investigation... > Glad if I could help and please scream at me if I'm on the wrong track here. You have been helpful - noone realized there was a regression until you reported it :) > Hi James, > > needed too long to compose last message, and missed your > mail(s), sorry > > The only problem would arise if there is some internal logic > that decides to return links to some other protocol type but > must, for some strange reason, again be handled by 'youtube-dl'. My fix has already been uploaded now do it would be a bit of a pain to change it :/ However, I think it is still correct. It effectively incorporates this upstream commit, so if what I have done is wrong, upstream has also made a mistake: https://github.com/mpv-player/mpv/commit/1623430b200c7bf67ec19bcab13ccbe9a494d2c7 Thanks, James
Description: OpenPGP digital signature