search

aclap-dev / vdhcoapp

Companion application for Video DownloadHelper browser add-on
GNU General Public License v2.0
1.72k stars 280 forks source link

Q: where is the temporary buffer file for large streams on windows? #77

Closed leaumar closed 4 years ago

leaumar commented 4 years ago

I've got a download of a live stream running. The stream itself ended hours ago but vdh/coapp hasn't "realized" yet and isn't releasing the file. I can't find any way in the gui or options to force the download to end. I've noticed in test runs that any sort of manual intervention like closing the browser just ruins the process and causes the file to be lost.

I've tried to find the temp file so I could copy it to safety before ending the download, but I'm not finding anything. I've enabled the option to "keep temp files after processing", unsure of how or when it applies. The stream was 5h long and vdh says the bitrate is 8Mbps, so I'm expecting an 18GB file somewhere, or at least a file of significant size. It's clearly not being stored in RAM, my storage has no file named vdh-* (suggested by another issue here), I can't find any folders with names that would suggest them being vdh folders (except the final download location), the name of the stream (which shows up on other downloads from the same source) isn't anywhere on disk, etc. In fact, my storage stats haven't changed noticeably at all. A tree scan didn't show any unusual space hogs anywhere. The final download folder is empty.

Come to think of it, this was the first download I did via this installation of the addon (little used pc + fresh browser install), and the coapp wasn't installed yet, so starting this HLS stream download prompted for the installation of the coapp and a retry of the download before it would start. On top of that, there is no running process by the name of the binary (net.downloadhelper.coapp-win-64.exe) while the addon shows the download as ongoing, which suggests to me that it may have just crashed without the addon noticing the dead process.

I feel like the data is already lost, so knowing the path where it should show up would at least confirm that. I read diagonally through the code but didn't notice a definition of a hardcoded temp file path.

leaumar commented 4 years ago

I've started a new download of a similar stream just to compare. This new download created the expected coapp process, but I'm still not finding a temp file being written. The process' memory usage slowly goes up and then drops down, hinting at a memory buffer being flushed to a file. My search tool may not show it for some reason, maybe vdh marks it as a system file or sets the modified-timestamp to some non-now value (I'm searching by modified time). It does show a file named <uuid>.tmp popping up with a 0 byte size in the browser's (vivaldi, chromium based) user data folder for a split second before disappearing.

leaumar commented 4 years ago

Ok, so I have my answer: the final file also serves as the buffer file, and it's in the final destination folder.

The issue turned out to be, I think, that the coapp process is started and killed together with the browser, and after installation of the coapp the browser needs to be restarted to start the coapp the first time. The addon seems unaware of whether the coapp is working or not, and doesn't give any indications/errors about this.