Issue donwloading content from magentamusik.de

[Baum]

Problem downloading content from magentamusik.de

A few weeks ago I was able to download the video from agentamusik.de using the plugin. But recently when I tried to download some wacken festival shows an ad that have 30s starts, then the show goes normally, so I start the download and everything is normal. The problem happens when I open the downloaded video, it opens, starts, but crashes at the end of the ad (30s) it does not advance in the video, it only plays its audio. The size of the file is normal, around 3GB.

Tested using firefox and chrome, tried using adblock, cache clearing, reboot...

Interesting is that this ad (a German telecommunications company) only appears when the plugin is activated. It seems to be there to somehow confuse the download plugin.

[Baum]

the exemple https://www.magentamusik.de/woa-2022-tarja

[Wild Willy]

I opened your web page & without even launching playback, VDH showed me this:

I downloaded the first variant shown by VDH, the 1920x1080 one.  Resource Monitor reported the download speed varying between about 2 million & 28 million bytes per second.  Yes, 28 million.

I saw it spike up to 34 million once.  But these extreme speeds were just momentary.  The speed fluctuated much more than I usually see.  It did not just find an equilibrium & settle there.  It seemed like it was most often between 2 & 4 million, intermittently spiking up to extremes.  Not terrible, but not the best I've seen.  When the download eventually completed, these were my results:

The exact file size was 3,991,192,643 bytes.  You can see from the date/time stamps for when the file was created & when it was last modified that the download took 24 minutes, give or take.  Windows doesn't report the seconds but 24 minutes is good enough.  That works out to an average download speed of not quite 2.9 million bytes per second, like I said, decent but not remarkable.  The video bit rates in the 7,000 kbps range make this video well above average quality.  That explains, in part, its rather large size, in addition to the HD resolution & the duration of almost an hour.  Speaking of the resolution, VDH seems to be in the habit these days of giving videos of resolution 1912x1088.  This is bogus.  Both VLC while playing these files & ffprobe report that they are indeed 1920x1080.  I don't know why VDH shifts these numbers by 8.  It's just weird.  I ignore it.

But after all of that got my hopes up, I was disappointed, as you were, that the video was not as expected.  The first 30 seconds or so of the file consist of a cartoon that apparently is advertising a cell phone service.  The audio seems to be of the concert, not the advertisement, during these 30 seconds.  Then the video just freezes on the company's logo for the remainder of the file.  The audio of the concert appears to all be there but there is no video.  Very odd.

Time to go to ffmpeg.  You can read about what I did by starting here:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/BzPLK2YyL-s

Do a string search on "cannot download" in that thread.  That will reposition the web page on a reference that contains a link.  Click that link & you'll find a compete explanation of the approach I took next.

VDH showed this was an HLS stream.  That led me to expect to find a .m3u8 master manifest.  I was not disappointed.  I actually got a list of 8 manifests, but I looked at only the first one, on the assumption it was the master manifest.  Running ffprobe on that first manifest confirmed my assumption.  But ffprobe reported a large number of errors.  Plus it started its report with Stream 0:21, something I've never seen before.  Plus, there's timed_id3 data, something I have commented on in this forum a number of times.  (Do a search in this forum using "timed_id3" as your search key to find those comments.)  Timed_id3 data is known to cause problems for VDH.  Combining that with all the errors ffprobe found, I suppose it's not surprising that VDH had a problem downloading this video.  Since it is so weird, I'm attaching the ffprobe report to this post.

After I saw the weird & wacky ffprobe report, I settled upon getting Stream 0:21, the 1920x1080 video variant, along with Stream 0:22, its partner audio stream.  By selecting only these 2 streams, I eliminated all consideration of the erroneous streams & I ignored the timed_id3 data.  I used ffmpeg the way I explain in the reference I mentioned above.  For comparison, this is what Resource Monitor looked like during this ffmpeg download:

This is more like the behavior I observe with most downloads, with VDH, with ffmpeg, & with Firefox itself.  I must say this download speed ranks with the best sites I visit regularly.  Not the absolute best, but close.  What you see in that image is how it looked for the duration of the download, barely fluctuating at all.

My results were these:

Same duration as before, slightly smaller file, proper resolution of 1920x1080, much shorter download time (only 8 minutes), & frankly spectacular video bit rates.  After all of that build-up, this time, there was no disappointment:

I love the energy of live outdoor concerts.  Too bad this is not exactly my cup of tea.  Sadly, so many of the artists I'd like to see are dead: Eddie van Halen, BB King, Albert King, Albert Collins, Stevie Ray Vaughan, Roy Buchanan, half the Beatles, some of the Rolling Stones, Malcolm Young, the list is endless.  And I'm not even thinking about Beethoven, Mozart, Verdi, Puccini, Donizetti . . .  In any case, I couldn't handle more than a few minutes of this.  I watched about the first 10 minutes & then skimmed through the rest.  It appeared to be all there.

The ffmpeg log was filled with sequences of lines like this:

[hls @ 0000000000455280] Invalid timestamps stream=21, pts=1634400, dts=1638000, size=5585
[mp4 @ 000000000ce9d940] Invalid DTS: 738000 PTS: 734400 in output stream 0:0, replacing by guess
[mpegts @ 000000000f432700] Invalid timestamps stream=0, pts=1641600, dts=1645200, size=5137

I would post the log but it's over 58,000 lines & you can see its size in the second results image above.  The majority of the lines was like the 3 I've just quoted.  It seems that whatever guesses ffmpeg made, they were good ones because the video played just fine.

I would have to say that VDH failing to get this video is entirely to be expected.  According to the ffmpeg log, there was considerable damage in the content, not to mention the problematic timed_id3 data.  I suppose you could say that if ffmpeg got it this easily, VDH should have as well.  But given the volume of errors in the file, I'm inclined to give VDH a pass on this.  Just use ffmpeg & be happy with that.

Before you post a reply, which you will do with Reply all, NOT Reply to author, be sure you read this & follow the advice you'll find there:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/39_tUWjISN8

[Wild Willy]

It occurs to me that to be complete, I ought to post this:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Q:\VDH Testing\German Concert.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf59.20.100
  Duration: 00:57:49.01, start: 0.000000, bitrate: 9134 kb/s
  Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 9000 kb/s, 25 fps, 25 tbr, 90k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]

This is the ffprobe report for the file that ffmpeg downloaded.