wip

doc/git-annex-addurl.mdwn

@@ -10,8 +10,8 @@ git annex addurl `[url ...]`
 
 Downloads each url to its own file, which is added to the annex.
 
-When `youtube-dl` is installed, and the url is to a web page,
-it's used to download any video that the web page embeds.
+When `youtube-dl` is installed, it's used to download videos
+embedded on web pages.
   
 Urls to torrent files (including magnet links) will cause the content of
 the torrent to be downloaded, using `aria2c`.
@@ -28,10 +28,20 @@ be used to get better filenames.
   Avoid immediately downloading the url. The url is still checked
   (via HEAD) to verify that it exists, and to get its size if possible.
 
+  When `youtube-dl` is installed, videos embedded on web pages
+  will be added. To avoid the extra work of checking for videos,
+  add the `--raw` option.
+
 * `--relaxed`
 
-  Avoid storing the size of the url's content, and accept whatever
-  content is there at a future point. (Implies `--fast`.)
+  Don't immediately download the url, and avoid storing the size of the
+  url's content. This makes git-annex accept whatever content is there
+  at a future point. This is also the fastest option, since it does not
+  hit the network at all.
+
+  Note that this does *not* check for embedded videos using `youtube-dl`,
+  although it used to in previous versions of git-annex. 
+  Use --fast instead if you want to do that.
 
 * `--raw`
 

doc/todo/switch_from_quvi_to_youtube-dl.mdwn

@@ -16,12 +16,12 @@ urls, see for example http://bugs.debian.org/874321)
 So, switching to youtube-dl would probably need a new switch, like `git
 annex addurl --rip` that enables using it.
 
-Currently `git annex importfeed` automatically tests for video urls with
-quvi; it would also need to support `--rip`.
+(Importfeed only treats links in the feed as video urls, not enclosures,
+so this problem does not affect it and it would not need a new switch.)
 
-Both of those changes would need changes to user's workflows and cron jobs.
-git-annex could keep supporting quvi for some time, and warn when it uses
-quvi, to help with the transition.
+That would need changes to users' workflows. git-annex could keep
+supporting quvi for some time, and warn when it uses quvi, to
+help with the transition.
 
 > Alternatively, git-annex addurl could download the url first, and then
 > check the file to see if it looks like html. If so, run youtube-dl (which
@@ -30,12 +30,22 @@ quvi, to help with the transition.
 > overhead, and the redundant download is fairly small compared to ripping
 > the media. Only the unusual case where addurl is being used on html that
 > does not contain media becomes more expensive.
+> 
+> However, for --relaxed, running youtube-dl --get-filename would be
+> significantly more expensive since it hits the network. It seems that
+> --relaxed would need to change to not rip videos; users who want that
+> could use --fast.
+> 
+> --fast already hits the network, but
+> if it uses youtube-dl --get-filename, it would fall afoul of
+> bugs like <http://bugs.debian.org/874321>, although those can be worked
+> around (/dev/null stderr in cast youtube-dl crashes)
 
 Another gotcha is playlists. youtube-dl downloads playlists automatically.
 But, git-annex needs to record an url that downloads a single file so that
 `git annex get` works right. So, playlists will need to be disabled when
 git-annex runs youtube-dl. But, `--no-playlist` does not always disable
-playlists. Best option seems to be `--playlist-items 0` which works for
+playlists. Best option seems to be `--no-playlist --playlist-items 0` which works for
 non-playlists, and downloads only 1 item from playlists (hopefully a fairly
 stable item, but who knows..).