[Dumpert] Embed URLs are not recognized; HTTP Error 404: Not Found

[joepie91]

• Platform: openSUSE 13.1, x86_64, XFCE
• Version: 2015.08.16.1
• URL: http://www.dumpert.nl/embed/6675421/dc440fe7/
• Resolver: Dumpert
• Error: HTTPError: HTTP Error 404: Not Found

It tries to use the generic extractor, which then runs into a 404 for some reason (mis-detection, perhaps?). The video in question was embedded at http://www.rtlnieuws.nl/nieuws/binnenland/video-woedende-meisjes-na-aanhouding-lil-kleine, but I gave youtube-dl the iframe URL directly.

The original video page at http://www.dumpert.nl/mediabase/6675421/dc440fe7/lil_kleine_kopt_biertje.html works just fine in youtube-dl - it's correctly detected as being Dumpert, and the video is downloaded correctly. This probably just requires a change in the detection code to also pick up embed URLs.

sven@linux-etoq:~/archive/arrest-lil-kleine> youtube-dl -v http://www.dumpert.nl/embed/6675421/dc440fe7/
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-v', u'http://www.dumpert.nl/embed/6675421/dc440fe7/']
[debug] Encodings: locale ANSI_X3.4-1968, fs ANSI_X3.4-1968, out ANSI_X3.4-1968, pref ANSI_X3.4-1968
[debug] youtube-dl version 2015.08.16.1
[debug] Python version 2.7.6 - Linux-3.11.10-29-desktop-x86_64-with-SuSE-13.1-x86_64
[debug] exe versions: ffmpeg 2.7.2, ffprobe 2.7.2, rtmpdump 2.4
[debug] Proxy map: {}
[generic] dc440fe7: Requesting header
WARNING: Falling back on generic information extractor.
[generic] dc440fe7: Downloading webpage
[generic] dc440fe7: Extracting information
[debug] Invoking downloader on u'http://content.longtailvideo.com/videos/flvplayer.flv'
ERROR: unable to download video data: HTTP Error 404: Not Found
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1585, in process_info
    success = dl(filename, info_dict)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1527, in dl
    return fd.download(name, info)
  File "/usr/lib/python2.7/site-packages/youtube_dl/downloader/common.py", line 342, in download
    return self.real_download(filename, info_dict)
  File "/usr/lib/python2.7/site-packages/youtube_dl/downloader/http.py", line 60, in real_download
    data = self.ydl.urlopen(request)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1860, in urlopen
    return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib64/python2.7/urllib2.py", line 410, in open
    response = meth(req, response)
  File "/usr/lib64/python2.7/urllib2.py", line 523, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib64/python2.7/urllib2.py", line 448, in error
    return self._call_chain(*args)
  File "/usr/lib64/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib64/python2.7/urllib2.py", line 531, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 404: Not Found

[Reino17]

While the videolinks in the normal url are base64 encoded, in the embed-url they're plain text:

'modes': [
  {type: 'flash', src: 'http://www.dumpert.nl/swf/player.swf', config: {file: 'http://media.
dumpert.nl/tablet/dc440fe7_dumpert_ios_upload.mp4.mp4.mp4'}},
  {type: 'html5', config: {file: 'http://media.dumpert.nl/mobile/dc440fe7_dumpert_ios_upload
.mp4.mp4.mp4'}}
]

Or you can just follow //meta[@property='og:url']/@content

[joepie91]

@jaimeMF I just want to point out that this isn't so much a 'site support request', as it is a mis-detection :) The Dumpert downloading code is there, it just doesn't detect the site/URL correctly from the embed pages.

Not sure what your tagging guidelines are, but perhaps that makes a difference in making sure the right people look at it.

[jaimeMF]

Should be supported in the next version, thanks for the report.

The tag is not the best, but I think bug is also bad. I guess we could use something like improve-site-support.

[joepie91]

Hmm, I see. Another idea might be site-coverage? Though while shorter, that may be ambiguous.

Either way, thanks for fixing it :)