If ytd2 fails to obtain the video URLs for each resolution, then the downloading thread will instead download the incorrect video (which will be the previous video that the thread successfully downloaded).
Steps to reproduce:
1. Use each of the four threads at least once
2. If you keep using ytd2 (without closing the application), there will eventually be a time when ytd2 fails to poll Youtube for the correct resolution links and you'll get this message in the console:
#info - try to download: http://www.youtube.com/watch?v=< >
#info - found video URL for resolution:
#info - could not find video url for selected resolution! trying lower res...
3. ytd2 will then start downloading a video, but it will be the incorrect one and will instead be the same one that the corresponding YTDownloadThread successfully PREVIOUSLY downloaded
Technical Explanation (note this is based on what I think anyway):
- If everything goes to plan, then ytd2 will get a list of all the video download links and then populate the sNextVideoURL vector (lines 387-440 of YTDownloadThread.java)
- ytd2 will then download sNextVideoURL.get(0) and everything is ok
- However, if ytd2 fails to get the resolution links from Youtube, then lines 387-440 of YTDownloadThread.java will just populate sNextVideoURL with a bunch of NULLs, which will then be subsequently removed by lines 454-456
- sNextVideoURL.get(0) will then contain the link to the videos from the previous successful run, and this then results in the incorrect video being downloaded
I believe the best way to fix this is to empty the sNextVideoURL vector either:
a) after the sVideoURL has been assigned (i.e. line 459) so that this data which is no longer needed won't interfere with future requests
b) before starting the population of he sNextVideoURL vector (i.e. lines 387-440) so that for this video, it ensures that there is no residual data from previous runs