PiRSquared17 / damnvid

Automatically exported from code.google.com/p/damnvid
GNU General Public License v3.0
0 stars 0 forks source link

Download queing does not work #118

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Bug: Unable to download some videos if choosing psp-compatible profile

Steps:
Trying to send event <DamnProgressEvent holding: {'go': False}> to target 
<__main__.DamnMainFrame; proxy of <Swig Object of type 'wxFrame *' at 
0xa3906b0> > 
DamnURLGetAll called with request 
http://www.youtube.com/get_video_info?video_id=W6kDa6_IMfc and data None ; on 
error = 
DamnURLOpen called with request 
http://www.youtube.com/get_video_info?video_id=W6kDa6_IMfc ; data None ; Throw 
error? False 
Request was http://www.youtube.com/get_video_info?video_id=W6kDa6_IMfc ; 
request is now <urllib2.Request instance at 0xb09ba6c> 
[10:55:15] DamnURLOpen successful, returning stream. 
DamnURLGetAll successful; returning 3542 bytes of content. 
DamnURLPicker summoned. URLs: 
[u'http://www.youtube.com/get_video?video_id=W6kDa6_IMfc&t=vjVQa1PpcFP8x4BQ-TIaf
NZFCiirwvZ16VHY8Fozxw8%3D&fmt=18', 
u'http://www.youtube.com/get_video?video_id=W6kDa6_IMfc&t=vjVQa1PpcFP8x4BQ-TIafN
ZFCiirwvZ16VHY8Fozxw8%3D'] Resume at: None 
DamnURLOpen called with request <urllib2.Request instance at 0xb09abac> ; data 
None ; Throw error? True 
DamnURLOpen on <urllib2.Request instance at 0xb09abac> failed with code 404 and 
no reason. 
DamnURLOpen called with request <urllib2.Request instance at 0xb09abcc> ; data 
None ; Throw error? True 
DamnURLOpen on <urllib2.Request instance at 0xb09abcc> failed with code 404 and 
no reason. 
DamnURLPicker returning none because no URLs are valid 
URI is None! 
Conversion routine starting, URI is None 
Exception in thread Thread-7:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "DamnVid.py", line 3721, in run
    if os.path.exists(self.uri):
  File "/usr/lib/python2.6/genericpath.py", line 18, in exists
    st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, NoneType found

-- Auto-collected system information --
DamnVid version: 1.6
DamnVid mode: 32-bit
DamnVid arguments: --dump-locale-warnings
Machine name: andreas-laptop
Platform: Linux-2.6.35-20-generic-i686-with-Ubuntu-10.10-maverick / 
2.6.35-20-generic
Architecture: 32bit ELF / i686
-- End of auto-collected system information --

Email: anoteng (at) gmail (dot) com

(Could not upload the contents of damnvid.log)

Original issue reported on code.google.com by damnvid....@gmail.com on 18 Sep 2010 at 9:02

GoogleCodeExporter commented 9 years ago
Trying to stop the failed video also fails.
I'm guessing this has something to do with my ffmpeg package though, what do 
you think?

Original comment by anot...@gmail.com on 18 Sep 2010 at 9:07

GoogleCodeExporter commented 9 years ago
It turned out the PSP profile had nothing to do with it. The queing does not 
work. Damnvid dl's and converts the first video in the list, but fail on the 
rest. This is a regression from previous versions. Or perhaps a new bug in 
Maverick. Don't remeber if I ever tested downloading multiple files with 
1.6/lucid.

Original comment by anot...@gmail.com on 18 Sep 2010 at 9:36

GoogleCodeExporter commented 9 years ago

Original comment by anot...@gmail.com on 18 Sep 2010 at 9:37

GoogleCodeExporter commented 9 years ago
There have been multiple reports about this (see bug 155, bug 112), but I have 
yet to experience this bug myself. As such, are you sure it's only on Maverick?

Original comment by windypo...@gmail.com on 18 Sep 2010 at 9:36

GoogleCodeExporter commented 9 years ago
Nope, but I didn't experience it until I upgraded. But as I said in comment #2, 
It could as well be a bug introduced in v1.6. I'll try it on my wife's computer 
which is still lucid tomorrow.

Original comment by anot...@gmail.com on 18 Sep 2010 at 9:39

GoogleCodeExporter commented 9 years ago
I can confirm that the problem is also present with 1.6 in Lucid

Original comment by anot...@gmail.com on 26 Sep 2010 at 7:00

GoogleCodeExporter commented 9 years ago
Yeah, that's what I thought. People have been reporting this when queuing 
multiple YouTube videos, yet I have yet to run into it myself. I still don't 
know what's causing it exactly... Can you confirm that it's a YouTube-only 
thing (does it work with local files?), and can you get a Wireshark trace or 
something of what happens when DamnVid tries to download the second video?

Original comment by windypo...@gmail.com on 27 Sep 2010 at 2:42

GoogleCodeExporter commented 9 years ago
Issue 120 has been merged into this issue.

Original comment by windypo...@gmail.com on 27 Sep 2010 at 2:42

GoogleCodeExporter commented 9 years ago
Issue 115 has been merged into this issue.

Original comment by windypo...@gmail.com on 27 Sep 2010 at 2:43

GoogleCodeExporter commented 9 years ago
I can confirm that this does not affect local videos.
attached is the output from wireshark. I started the capture maybe 30 seconds 
before the end of the first file, so I'm guessing the last part is what's 
interesting for you…

Original comment by anot...@gmail.com on 2 Oct 2010 at 12:42

Attachments:

GoogleCodeExporter commented 9 years ago
Can you resend this in a Wireshark format please?

Original comment by windypo...@gmail.com on 4 Oct 2010 at 3:27

GoogleCodeExporter commented 9 years ago
I was gonna make a new capture, but it somehow looks like the issue has been 
fixed in svn… Everything is at least working fine for me now…

Original comment by anot...@gmail.com on 4 Oct 2010 at 3:51

GoogleCodeExporter commented 9 years ago
or not. Damnvid reports success, but the second video vas only 1 sec long, not 
5 mins as the original on youtube…

Original comment by anot...@gmail.com on 4 Oct 2010 at 3:53

GoogleCodeExporter commented 9 years ago
Even if it's fixed in source, a fix should be released right now if it's an 
issue like not being able to download from YouTube.
Try the video again, see if it's just a matter of a broken connection. It might 
also have something to do with the (completely rewritten in 1.7) download 
functions.

Original comment by windypo...@gmail.com on 4 Oct 2010 at 4:01

GoogleCodeExporter commented 9 years ago
Are you saying you would like to release a fix to 1.6 (1.6.1 or something)? Or 
that you want to speed up the release of 1.7.
If you want to release an 1.6 fix i should downgrade to 1.6 before doing 
further testing…

Original comment by anot...@gmail.com on 4 Oct 2010 at 4:08

GoogleCodeExporter commented 9 years ago
the symptoms are back, with 1.7.

Original comment by anot...@gmail.com on 4 Oct 2010 at 4:22

Attachments:

GoogleCodeExporter commented 9 years ago
I just installed 1.6 onto Ubuntu 10.04.1 and it wont show the YouTube link in 
the program, :/

Original comment by padraig....@gmail.com on 4 Oct 2010 at 9:46

GoogleCodeExporter commented 9 years ago
@padraig.fahy: That's a different issue, please post it in a new bug report 
(with log file and all)~
As for the Wireshark trace, it does sound like an issue with the download 
functions, asking for invalid byte ranges. The issue is obviously not the same 
for DamnVid 1.6, since it doesn't have those functions; so I guess that should 
make 2 bug reports, but oh well.

Original comment by windypo...@gmail.com on 4 Oct 2010 at 11:04

GoogleCodeExporter commented 9 years ago
Issue 123 has been merged into this issue.

Original comment by windypo...@gmail.com on 6 Oct 2010 at 9:57

GoogleCodeExporter commented 9 years ago
Issue 124 has been merged into this issue.

Original comment by windypo...@gmail.com on 11 Oct 2010 at 5:06

GoogleCodeExporter commented 9 years ago
Issue 136 has been merged into this issue.

Original comment by windypo...@gmail.com on 24 Oct 2010 at 4:33