Stream that ends during recording results in corrupt ".mp4.part" file that can't be played

[Ron]

When I'm recording HLS streams, if the stream ends, Video DownloadHelper doesn't properly finish the recording. Instead, it aborts the download with an error (failed to download manifest). In the download folder, it leaves behind a ".mp4.part" file, which is corrupt and can't be played back (even if I rename it to .mp4).

Even if it is a download error when the stream is no longer available, I think that the portion that was already downloaded ought to be playable... right?

Video DownloadHelper

Version 7.3.5

Browser locale: en-US

Production build

Built on Wed Aug 01 2018 16:23:45 GMT+0200 (CEST)

Build options: browser=firefox

Platform Win x86-64

Browser Mozilla Firefox 65.0

Found companion app: VdhCoApp 1.2.4

Companion app binary: C:\Program Files\net.downloadhelper.coapp\bin\net.downloadhelper.coapp-win-64.exe

[jcv...@gmail.com]

Hi,

could you share the URL of a video with this problem?

jerome

[Ron]

It happens pretty consistently when recording Chaturbate streams. Recording the stream works fine, as long as it's stopped before the stream ends, but if the stream ends while it's recording, the download aborts and leaves a corrupt ".part" video file.

Unfortunately I don't know of any "safe for work" examples that would show the same problem...

[jcv...@gmail.com]

difficult to say. 

.mp4.part files are not playable, they are temporary pieces of a movie to be reconstructed in the end. 

If the manifest can't be downloaded, it won't work.

Sorry, don't know what to say to help you. Hope some expert users of this forum have an idea.

jerome

[Ron]

Well... what I read on Google was that .mp4 files have a manifest (I guess that's what it's called) at the end of the file, and it tells what codecs are used and contains a table of contents basically so that players can seek into the file correctly. Without it, the file is completely unplayable. But streaming video has to have all of that information pre-loaded up front in order to play normally. I read that there is an option for ffmpeg that will tell it to put the information at the beginning of the file, to optimize it for streaming... I think then the video should be playable, even if it stopped abruptly. I think Video DownloadHelper uses ffmpeg, but I don't know if there's any way to change the command line options. Really, though, it seems that the problem is that the Video DownloadHelper companion app is not closing the file properly when the stream terminates unexpectedly.

I found some software that can try to repair a .mp4 video if you have another video of the same type, and it was at least able to make the .mp4 file playable, but the framerate ended up being wrong and also it seemed like chunks of the video were just missing so it would skip. Even after I tried to correct the framerate, the missing sections of video prevented the audio and video from syncing up properly.

[WOS21Gf]

Hello, I made simmelar experiences with an suddenly ending stream recording, that left an *.mp4.part file.

I resetted te configuration of VDH and the next download was OK (perhaps I had only luck).

If the reset is not the solution you should delete VDH and install it oncemore.

Kind regards from WOS21Gf

[Tom D Frog]

I get the Part file problem sometimes.  Other times I also get ones where I clicked to end the capture but then end up with an .mp4 file which will not play. VDH shows a manifest download error under the brown dot.

I have had some luck repairing them with 3rd party utilities which load a good file to compare against.  They then open and play, but are out of sorts.

:-(

It would be really nice to have VDH automatically close and fully write out any stream where the source drops.

[Phrank]

Hi I'm on a Mac and use the Chrome  plugin. I there any solution yet to fix these dropped mp4 streams? 

I’m using the Wondershare Recoverit software to fix most videos with a similar video file it, 

but the resulting files often missing the audio after some minutes and the file length changes.

As far i know QuickTime mov. files will preserve the header, even if the stream ends before the recording was stopped. 

I red somewhere it's possible replace this header of MP4 files, but that was to complicated for me;-) Is there an easy way to recover the header of a MP4 file?

[Shaba]

found this thread while searching for any possible ways to not have HLS streams randomly stop recording in VDH... while I haven't figured that part out, I do have a solution for playing the .part files... I found this program while searching for a program to repair the corrupt/incomplete .part mp4s a year or two ago... it's called "Repair It" from Wondershare - there's an option in there called advanced repair that it will have you do after you try to repair a .part file, all you have to do is select a similar working video as a sample for it to reference and it will fix the .part for you into a viewable working video file... I originally paid for a year license, but i recently found a workaround that lets you save the repaired files without needing a license... (basically you just show hidden files in file explorer and find the drive location that the program is storing the temporary file for the repaired video & save a copy of the video before you close the program or exit the repaired video menu) 

enjoy !

[Wild Willy]

This thread is just a few months shy of 4 years old. Since the original poster told us
about his environment, there have been several new releases of VDH, several new releases
of the CoApp, & many new releases of Firefox. I have had problems with recording
livestreams that have been solved by VDH 7.6.3a6 beta. There are several threads on this
forum in which I have discussed the issues. Try VDH 7.6.3a6 beta & CoApp 1.6.3, which
are the current releases as of the moment I am writing this. Also, use the current
Firefox, which is now 106.0.5. Tell us your experience with the current software & then
maybe we can have a discussion.

The thing that goes at the end of an MP4 that acts as a sort of table of contents is
called, as far as I know, the moov atom. The problem with the moov atom in VDH is that
Michel has made a bad design choice. He keeps the moov atom in program storage & allows
the operating system's paging management to take care of that data. VDH then writes the
moov atom into the MP4 when the download completes. But keeping the moov atom in program
storage means it is volatile & subject to being prematurely discarded. Aside from the
problems of unplayable files, letting that data be paged causes problems, at least in
Windows. When multiple concurrent VDH downloads happen to complete more or less at the
same time, I have observed my Windows 7 system thrashing for as long as half an hour. My
entire system becomes unusable until Windows sorts things out. It does always sort
things out, but some of my concurrent downloads either are corrupt or simply never
started. So on top of everything else, you need to be judicious about trying to do
multiple concurrent downloads in VDH. A corrected design for VDH would involve keeping
the moov atom in a file on disk. That way it's persistent & there's the possibility of
successfully completing an interrupted download, possibly even after a complete system
reboot. It also takes management of that data out of the utterly untrustworthy hands of
Microsoft.

VDH uses ffmpeg but not for the actual download operation. VDH uses ffmpeg in the
aggregation & conversion functions, but not the download. The ffmpeg distributed with
VDH is a slimmed down build that Michel customized for use by VDH. It is not suitable
for general use the way the official ffmpeg from ffmpeg.org is. I have tried to use the
captive ffmpeg included with VDH & I can assure you it is not satisfactory for general
use.

I have found that using the stop button on the VDH blue dot status menu is not entirely
reliable, even in 7.6.3a6. Sometimes it terminates the download & you have a playable
file. Sometimes it terminates the download & you have a junk file that you have to
discard. Perhaps one of your editing tools would repair such a damaged file. Good luck
with that. The only way I have found to make VDH reliably terminate a download before it
is done is to physically disconnect the Internet connection. I unplug it from
electricity. VDH recognizes that as a termination of the input connection & happily
writes the moov atom into the MP4. The file is then playable. It is my understanding
that downloading into MKV files is not subject to this problem since the MKV format is
simply completely different from MP4. I am under the impression that you can interrupt a
download into an MKV & you will have a file that can be played. Every time. I believe
MKV is even playable while the download is still in progress. Note the weasel words in
what I'm saying. You would have to test my claims about MKV. I have not verified them.
I am simply going on what I have read & what I have read between the lines.