Difference between revisions of "Talk:YouTube"

From Archiveteam
Jump to: navigation, search
m (LQL @ linking to code vital to archiving on a service we're currently archiving, fixed that tho)
Line 26: Line 26:
  
 
xattrs are not portable and will get lost when copying to a file system that doesn't have them (or when uploading it somewhere, like to IA) --[[User:Darkstar|Darkstar]] 08:53, 31 May 2015 (EDT)
 
xattrs are not portable and will get lost when copying to a file system that doesn't have them (or when uploading it somewhere, like to IA) --[[User:Darkstar|Darkstar]] 08:53, 31 May 2015 (EDT)
 +
 +
Solid reasoning. I've now switched to your way of doing things. --[[User:Vxbinaca|Vxbinaca]] 19:32, 2 August 2015 (EDT)
 +
 +
== --ignore-errors shouldn't be youtube-dl archiving default best practices ==
 +
 +
Theres a myriad of reasons this isn't a good idea to have by default. Downloads getting snapped off on channel rips could go unnoticed (I search for these with ls *.part). Problems with various versions of youtube-dl could lead to a channel rip with half-processed videos, see [https://github.com/rg3/youtube-dl/issues/6413 this issue on github].
 +
 +
Perhaps for a well-tested version that works on YouTube running in a warrior, --ignore-errors is appropriate, but for an attended rip we should by default suggest people not use it and instead just make sure all of it got ripped and if theres an error try to work resolve that particular video, and if it's a problem they can't get around then just go --ignore-errors.
 +
 +
I'm open to being told why I may be wrong though.  --[[User:Vxbinaca|Vxbinaca]] 19:32, 2 August 2015 (EDT)

Revision as of 23:32, 2 August 2015

youtube2internearchive

https://github.com/emijrp/youtube2internetarchive contains a script which also handled upload to Internet Archive, but I can't find it any longer. --Nemo 06:28, 26 January 2015 (EST)

I've found something with Google. bzc6p (talk) 12:25, 26 January 2015 (EST)

If YouTube needed to be quickly captured for some unforeseen reason, it might make sense to download only the XML and SRT files, so then at least some record would be saved. Google's subtitle recognition is currently far from accurate, but it's certainly improving. wtron 06:48, 12 June 2015 (EST)

Options

Is it really necessary to explicitly call best A/V when youtube-dl it by default?

Also, why not embed the subs and thumbnail instead of make a separate file? Also why not xattrs for those of us with unix filesystems? Xattrs is only one extra flag.

My command is currently

youtube-dl -t --embed-subs --add-metadata --xattrs --console-title --embed-thumbnails

although I'm going to be incorporating elements from the suggested one into mine. The reasoning behind this is it's one file to send. That command is how I archive currently, it's changing though.

I'd appreciate hearing your input about why I may be wrong though. Thanks in advance,

--Vxbinaca 21:24, 29 May 2015 (EDT)

On your second note, I strongly believe it's better to have different things (video, thumbnail, subtitle) in separate files. Easier to access, process, categorize, recognize. I think it's worth the "trouble" of having three files (with the same name) instead of one.

bzc6p (talk) 07:08, 31 May 2015 (EDT)

xattrs are not portable and will get lost when copying to a file system that doesn't have them (or when uploading it somewhere, like to IA) --Darkstar 08:53, 31 May 2015 (EDT)

Solid reasoning. I've now switched to your way of doing things. --Vxbinaca 19:32, 2 August 2015 (EDT)

--ignore-errors shouldn't be youtube-dl archiving default best practices

Theres a myriad of reasons this isn't a good idea to have by default. Downloads getting snapped off on channel rips could go unnoticed (I search for these with ls *.part). Problems with various versions of youtube-dl could lead to a channel rip with half-processed videos, see this issue on github.

Perhaps for a well-tested version that works on YouTube running in a warrior, --ignore-errors is appropriate, but for an attended rip we should by default suggest people not use it and instead just make sure all of it got ripped and if theres an error try to work resolve that particular video, and if it's a problem they can't get around then just go --ignore-errors.

I'm open to being told why I may be wrong though. --Vxbinaca 19:32, 2 August 2015 (EDT)