[APP] Music Video Downloader (1 Viewer)

[kiwijunglist]

OK. That works. Sorry for the false alarm. Didn't try 10b.

Cool was probably just the timer I set really fast in an older version when i was testing. the timer in 10b = 5 seconds, i think v9 was 2-3 seconds. Should probably be around 10 sec, i have to do testing to get the right balance between retrying files that already exist faster 'vs' going too fast and overshooting the allowable DLs.

So in summary, 10b may still overshoot a little (esp if you have slow PC or slow internet). Best thing is set DL limit =2 then wait 5 minutes see if it is overshooting, then crank it up slowly.

 

[Pat Clark]

So in summary, 10b may still overshoot a little (esp if you have slow PC or slow internet). Best thing is set DL limit =2 then wait 5 minutes see if it is overshooting, then crank it up slowly.

Lucky me. I have both a slow machine and slow internet!! (I revised my previous reply a couple of times.)

 

[kiwijunglist]

ok re-read. if max-dl is set to 2 and there are less are >2x .marker files it should just sit there and wait, might be a bug in the code. I guess I have to test that part properly as lately I've just been skipping already DL'd files.

 

[Pat Clark]

Also, I noticed when I killed MVD that MVD DL and youtube processes stayed alive. I assume they would have finished in some fashion, but I did kill them off by hand.

Also noticed that .part files did not ever seem to resume.

 

[kiwijunglist]

if you kill MVD_DL it does not kill the download. MVD DL2.exe only tells youtube-dl.exe what to do at the start then it just monitors youtube-dl.exe progress and feeds info back to MVD.exe (as well as writing something to the database when it detects that youtube-dl has finished)

What do you have for your DL folder + Bulk DL folder + monitor folder. If you have anything like c:\ (root folder not a music folder) then it will slow it down considerably, because before it does anything it has to search the entire c:\*.* and subfolders for every DL file to check for matches.[DOUBLEPOST=1375751697][/DOUBLEPOST]Nevermind it seems there is a bug. I just got 6x marker files with DL limit set to 4. will investigate.

 

[kiwijunglist]

In version 9 + 10b it was just continuously adding files regardless of how many active DLs.

I solved the problem ( i was actually having the same issue as you, unlimited downloads, i didn't test some changes properly, not sure when this bug was introduced, but surprised no one else complained)... try this

 

[Pat Clark]

Got it. Will test soon.

I decided to just let it (v9) run, and it's nearing completion now after generating 2 times 54 processes.

But it seems to be reporting FAIL with no .tmp file being retained, having been present previously. (I had hoped to discover why the failure.)

Also (sometimes) seems to be reporting OK but the .part filename remains and the real file is absent. I tried renaming the .part off on two files, but they wouldn't play right.

 

[kiwijunglist]

it automatically deletes the mini logs (.tmp file) regardless of success or failure... there is currently no way to show why the file failed as I haven't implemented any sort of long term logging. With slow internet + slow pc + 50 DL processes at the same time I wouldn't be suprised that some of the DLs failed.

Best way to find out is click View download list, then find the failed video, then try to load it in the browser. it probably no longer exists or is not available to your country. if it works send me the link, it might be that youtube has changed encryption for that video in which case wait 48hrs then click update, then retry.

Alternatively goto command prompt type

youtube-dl.exe www.youtube.com/watch?v=XXXXXXX

 

[Pat Clark]

The test version is running now, and catching some, but not all, videos the V9 overloaded run failed on. I had saved the .ini file before the last test and am using it against the same directory, which contains the files and .part files from that run. I'm trying to verify that the large .part files are merely completed. That would be nice. It's hard to tell though.

I was watching the v9 run fairly closely, and I believe youtube probably reset some connections due to a time out. (Current hypothesis.)

I'll watch it a while longer and then off to bed.

Update. I have verified that at least one .part file was not completed, but was marked SKIP in the updated .ini file. I reloaded the .ini file from disk into an editor, since View Download List is disabled in this version.

Many files are now downloading that failed before, so it will run a long time. Good night, thank you, and good luck. (Not that you need it.)

 

[Pat Clark]

Testing clipboard downloading revealed that it, too, needs a queuing process, but does not have it. Eight downloads caused the last 2 to fail immediately, 2 to fail partly downloaded, and 4 to complete.

FWIW, the reason this software is of such interest to me is because my internet speeds are so slow I cannot use youtube "live." Might be worth a mention in the initial write-up for other such unfortunates as me.