WizFX/YARDWiz/WizZilla Download Problem with Windows 7

netless · Post by **netless** » Sat Nov 19, 2011 16:52

All of these programs appear to terminate a download [randomly] during download under Windows 7. They work fine on my old XP machine.

Can anyone provide some advice on this problem?

I'm communicating with an older DP-P2 with serial number prior to 1032098000000 with 01.05.334 version of firmware

Thanks

John

Gully · Post by **Gully** » Sat Nov 19, 2011 16:58

For a start I would update the firmware to the current release.

Secondly, we need more information about your setup including version numbers of all the programs, firewalls in use, how connected, permissions, etc.

Thirdly, what size file are you copying to which drive and what format?

Lastly, did you have a look at the main topic for YARDWiz?

netless · Post by **netless** » Sat Nov 19, 2011 22:05

Hi Gully

Yes I did upgrade to the latest firmware 01.05.350 just after my post - and that has fixed the problem.

Thanks for the quick response

John

Gully · Post by **Gully** » Sat Nov 19, 2011 22:08

Happy to help.

Luke · Post by **Luke** » Sun Nov 20, 2011 08:04

It's a bug in the 01.05.334 firmware.

netless · Post by **netless** » Sun Nov 20, 2011 11:14

Thanks Luke

Cheers

John

bpratt · Post by **bpratt** » Sun Feb 17, 2013 11:46

I'm having these same problems under windows 7, but my firmware is 1.07.350

Gully · Post by **Gully** » Sun Feb 17, 2013 13:05

bpratt wrote:I'm having these same problems under windows 7, but my firmware is 1.07.350

No problems with Windows 7 here so maybe give us some more information about your set up.

bpratt · Post by **bpratt** » Sun Feb 17, 2013 13:25

Gully wrote:
bpratt wrote:I'm having these same problems under windows 7, but my firmware is 1.07.350
No problems with Windows 7 here so maybe give us some more information about your set up.

Windows 7 pro 64bit with 4gb ram.

Copying via network to my Synology DS2411+

Gully · Post by **Gully** » Sun Feb 17, 2013 13:44

bpratt wrote:Copying via network to my Synology DS2411+

And how is the network set up?

Also was it working before and if so what was changed?

bpratt · Post by **bpratt** » Sun Feb 17, 2013 23:08

Gully wrote:
bpratt wrote:Copying via network to my Synology DS2411+
And how is the network set up?

Also was it working before and if so what was changed?

I've only just started using it over the last couple of days, and it's been doing this from the get-go.

It all goes via a 10/100 switch.

prl · Post by **prl** » Mon Feb 18, 2013 09:16

Hi bpratt. Is this the same problem (Bad Request) that you raised in Yet Another Recording Downloader for the Wiz?

In that case you'll have seen that so far it's not been possible for me to reproduce this problem on my setup (Macbook Pro running Win7 native using Bootcamp drivers and rEFIt boot). I don't think that I've seen anyone give any indication about how to reliably reproduce the problem on any other machine.

The fact that the problem seems to affect both WizFX and getWizPnP (which does the heavy lifting for both YARDWiz and WizZilla) points to the problem not being in the user code of either program.

In the source code for the shttpd HTTP server (which is used inside the Beyonwiz firmware to support WizPnP), the only cause of a Bad Request error is if shttpd receives a packet that is too short to possibly be a valid HTTP request (16 bytes).

The current beta versions of getWizPnP (0.5.4beta1 & 0.5.4beta2) have a --retry option that will retry a data fetch request that fails because of a Bad Request error. These betas are currently being used in the current betas of YARDWiz, but they do not appear to make use of the --retry option. However, they have a retry mechanism of their own (using the --resume option of getWizPnP).

I have only been able to test --retry for simulated Bad Request failures because I cannot reproduce this problem.

Luke · Post by **Luke** » Mon Feb 18, 2013 10:34

prl wrote:The current beta versions of getWizPnP (0.5.4beta1 & 0.5.4beta2) have a --retry option that will retry a data fetch request that fails because of a Bad Request error. These betas are currently being used in the current betas of YARDWiz, but they do not appear to make use of the --retry option. However, they have a retry mechanism of their own (using the --resume option of getWizPnP).

I haven't gotten around to implementing getWizPnP's --retry option in YARDWiz but will do so.

prl · Post by **prl** » Mon Feb 18, 2013 15:29

Luke wrote:
prl wrote:The current beta versions of getWizPnP (0.5.4beta1 & 0.5.4beta2) have a --retry option that will retry a data fetch request that fails because of a Bad Request error. These betas are currently being used in the current betas of YARDWiz, but they do not appear to make use of the --retry option. However, they have a retry mechanism of their own (using the --resume option of getWizPnP).
I haven't gotten around to implementing getWizPnP's --retry option in YARDWiz but will do so.

The advantage of --retry is that it will do that number of retries on every HTTP GET request that fails with Bad Request, while the current way that YARDWiz handles it is that the number of retries is for the whole file.

--retry will work better if there are several Bad Requests in a transfer, though because there is a (at the moment fixed) 2 sec delay between retries the transfer will be very slow if there are large numbers of Bad Requests. However, I haven't heard that being reported; normally a transfer can be completed with only a few Bad Requests happening.

Luke · Post by **Luke** » Tue Feb 19, 2013 07:23

I've added getWizPnP --retry to YARDWiz, give beta 3 a go and see if that helps the HTTP 400 Bad Request issue.

prl · Post by **prl** » Tue Feb 19, 2013 10:38

Luke wrote:I've added getWizPnP --retry to YARDWiz, give beta 3 a go and see if that helps the HTTP 400 Bad Request issue.

I initially had a strange problem that movie downloads (as .ts files) weren't downloading in full, and YARDWiz was retrying (via --resume) and not getting anywhere. Then I realised I was downloading to a FAT32 file system (the only big writable filesystem I have when I'm running WIndows), and the downloads were dying when they reached 4GB. There was no error in the Debug log, though; I'll have to make sure that getWizPnP prints an error message for write errors.

Then I tried to stop the queued downloads by pressing the "cancel & delete" button at the bottom of the YARDWiz window, but the then current download continued to completion and wasn't deleted, and the next download started. So I then clicked Exit, YARDWiz exitted and the newly-started download was deleted (but not the one before it that I'd clicked cancel on).

I then tried to restart YARDWiz to retry the downloads with the TS conversion option off, but I got the error message popup:

Code: Select all

The logfile `C:\Program Files (x86)\YARDWiz\yardwiz.exe.log' could not be opened: [Errno 13] Permission denied: 'C:\Program Files (x86)\YARDWiz\yardwiz.exe.log'

I couldn't get rid of the error, not even by uninstalling YARDWiz and re-installing. The file mentioned in the error message doesn't appear to exist, so it's presumably a directory permission problem that's preventing the file from being created, but it seems a strange log file name (with the double extension .exe.log) and a strange place to put a log file.

Then, for no apparent reason, YARDWiz started working again after I tried a couple more times. I'm off to retry the downloads in Beyonwiz format.

prl · Post by **prl** » Tue Feb 19, 2013 10:44

Suggested enhancement: Once a set of queued downloads has started, it shows the total to be downloaded. It would be nice to know the running total of downloads queued before starting the download.

Luke · Post by **Luke** » Tue Feb 19, 2013 11:10

I wish FAT32 would hurry up and disappear...

I'll look into the download cancelling issue and total queued.

Re. the logfile, that's a default set at a lower level (py2exe). To override this behaviour, I redirect sys.stderr to my own logfile, however, if I've made some stupid error and yardwiz crashes before I redirect, then the py2exe default remains, which doesn't work on Win Vista+ unless yardwiz is run as Administrator. Not a very good default... Not sure why it's happening for you.

prl · Post by **prl** » Tue Feb 19, 2013 12:08

Luke wrote:I wish FAT32 would hurry up and disappear...

I know what you mean. Unfortunately, it's the only FS I know of that's read/write to all of Windows, OS X and Linux without spending money.

Luke · Post by **Luke** » Tue Feb 19, 2013 12:56

I've started using exFAT as I really only need Linux/Win7+ compatibility - there's a free exFAT implementation for Linux (Ubuntu PPA) which works well enough, so long as I don't have to plug the stick into my TV/Wiz or some random XP PC.

prl · Post by **prl** » Tue Feb 19, 2013 17:42

Luke wrote:I've started using exFAT as I really only need Linux/Win7+ compatibility - there's a free exFAT implementation for Linux (Ubuntu PPA) which works well enough, so long as I don't have to plug the stick into my TV/Wiz or some random XP PC.

I hadn't thought of exFAT. OSX 10.6.5 Snow Leopard apparently introduced exFAT support. It certainly works in 10.8.2.

prl · Post by **prl** » Tue Feb 19, 2013 17:59

prl wrote:... I was downloading to a FAT32 file system (the only big writable filesystem I have when I'm running WIndows), and the downloads were dying when they reached 4GB. There was no error in the Debug log, though; I'll have to make sure that getWizPnP prints an error message for write errors...

Well, the intention was good, anyway. I use a callback from LWP::UserAgent::request() to update the progress bar (if active) and write the downloaded data to file. According to the LWP::UserAgent::request documentation, "The callback can abort the request by invoking die()". Which is the case, but it doesn't print the message argument to die() or propagate any sort of error indicator back to the HTTP::Response returned by the request.

This meant that when a write error happened (in my case a write beyond the legal length of a FAT32 file) there was no error message being printed on stderr, and also the file download wasn't terminated immediately, it just went on with any remaining requests for recording data files from the Beyonwiz.

This is all now fixed, and getWizPnP prints an error message on a write error to its output file(s), and terminates the download at that point.

I've also realised that the error indicator I was using for file write errors (HTTP_BAD_REQUEST) would cause problems with the --retry code, so all those error codes have been replaced by HTTP_FORBIDDEN, meaning that the only time the getWizPnP code should see HTTP_BAD_REQUEST is when the error comes from the Beyonwiz HTTP server.

I use HTTP Status codes for all the I/O errors so that there are common error codes for both file and HTTP I/O. This means that I lose expressiveness about OS I/O errors, but maintain the correct HTTP errors.

I'll sit on these fixes for a bit before I make a new getWizPnP beta in case there are any other problems found in testing.

prl · Post by **prl** » Tue Feb 19, 2013 18:06

In better news, I downloaded ~29GB of recordings with the YARDWiz 0.4.3 beta3 without any problems, but also without seeing any Bad Requests to trigger the retry.

bpratt · Post by **bpratt** » Tue Feb 19, 2013 18:51

Luke wrote:I've added getWizPnP --retry to YARDWiz, give beta 3 a go and see if that helps the HTTP 400 Bad Request issue.

No problems this time round.... mind you I've only transferred one file with it so far.

Thanks for the update.

Luke · Post by **Luke** » Tue Feb 19, 2013 19:25

prl wrote:Suggested enhancement: Once a set of queued downloads has started, it shows the total to be downloaded. It would be nice to know the running total of downloads queued before starting the download.

.
Currently, if you select a few recordings in the list, the total size of the selected recordings is displayed in the status bar.

Luke · Post by **Luke** » Tue Feb 19, 2013 19:30

bpratt wrote:No problems this time round.... mind you I've only transferred one file with it so far.

Thanks for the update.

No problem, prl did 99% of the work : )

prl · Post by **prl** » Wed Feb 20, 2013 09:24

Luke wrote:
bpratt wrote:No problems this time round.... mind you I've only transferred one file with it so far.

Thanks for the update.
No problem, prl did 99% of the work : )

Probably because 99% of the bugs were mine

prl · Post by **prl** » Thu Feb 21, 2013 17:24

I've dropped my new version of getWizPnP with the write error message fixes into the Windows YARDWiz 0.4.3 beta3 and the earlier problems (no error messages and not terminating cleanly on error) have been fixed.

I have some ideas for better handling of errors within getWizPnP, but they can wait for the next version (they're more structural than having much impact on what the user sees).

WizFX/YARDWiz/WizZilla Download Problem with Windows 7

WizFX/YARDWiz/WizZilla Download Problem with Windows 7

About the Forum

Join us