As an experiment, I picked something at random off P o r n h u b. I'm writing it like
that to avoid possible censorship. The particular item is probably irrelevant but I'll
give it anyway, again slightly damaged to avoid censorship:
https://www.p o r n h u
b.com/view_video.php?viewkey=ph6257dd2f3678a
I successfully downloaded this via VDH. While that was in progress, I tried to play
the .part file in VLC. You can try to play .part files in VLC. Sometimes they'll play.
In this case, it would not.
I then used my alternative technique discussed over here:
https://groups.google.com/g/video-downloadhelper-q-and-a/c/BzPLK2YyL-s
Do a string search on "cannot download" in there, then click the link you'll find to find
the discussion. Essentially, I downloaded the same item using ffmpeg. Same as with VDH,
VLC would not play the .mp4 file while ffmpeg was downloading it. However, after the
download completed, it played fine, same as the VDH download.
All of this is as expected. It shows that ffmpeg is not capable of letting you play
in-progress downloads any more than VDH is.
One curiosity. While VLC was attempting (and failing) to play VDH's .part file, VDH
completed its download. Unfortunately, it got an error saying the item was locked & the
download failed. This is not all that surprising. It was on a second attempt that I
successfully completed the download of the entire video. On that second attempt, I made
sure VLC was not trying to play the file when VDH was getting close to completing the
download. I imagine ffmpeg would have suffered a similar error if I had been trying to
play the file when that download completed. I didn't test that. If you can supply a URL
of something that you are able to "chase play" during a download, I'd like to test out
whether both VDH & ffmpeg manage to complete their downloads while VLC is playing the
file. I suspect that with VDH, when it comes time to rename the .part file, you'll get a
similar error. Or VLC might just suddenly stop playing because the file's name will no
longer be valid. With ffmpeg, since there is no renaming, maybe the error won't occur
but I'm not totally convinced. I'd like to try all of this to verify these guesses. It
would be nice if you can find an example that is relatively short, like under 15 minutes
duration.
Another curiosity. The file I downloaded with ffmpeg did not have any of the video &
audio properties you usually see in the Windows Properties dialog. The details tab
showed both video & audio properties that were completely blank. I ran ffprobe on the
file I downloaded with ffmpeg & it reported all the same video & audio properties Windows
reported for the file I downloaded with VDH. Very weird. I used to have a problem with
these properties on ffmpeg downloads but I fixed that over a year ago. I downloaded
something else earlier today with ffmpeg & all the video & audio properties were there so
I don't know what the deal is with this test file. I do note that this content has
timed_ID3 data. I've posted about that a few times on here, posts you can find via a
search in this forum. I used -map on my ffmpeg download so I omited the timed_ID3 data
streams. Maybe that has some impact on the file properties, but that's a total wildass
guess. The absence of the properties in no way affected the file. It played fine in
VLC.
Just to be complete, I'll say that I'm doing all of this on Windows 7 64-bit, Firefox
100.0 64-bit, licensed VDH 7.6.3a1 beta, CoApp 1.6.3, VLC 3.0.16 Vetinari, ffmpeg/ffprobe
version
2022-03-17-git-242c07982a-full_build-www.gyan.dev built with gcc 11.2.0 (Rev7,
Built by MSYS2 project).