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:


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to