Yet Another Recording Downloader for the Wiz

[sub3R]

It's available under File->Check Recordings, though should probably be under Tools menu.

I didn’t know that, I thought that was to be a future addition because it was greyed out whenever I looked – I must give it a try.

I finally got ‘Check Recordings’ to come up available (not greyed out). Being greyed out may be something to do with having two wizzes under ‘Tools > Options > Device’ (fixed IP address:Wiz_01; fixed IP address:Wiz_02), but I’m not sure because after I got it to come up available, a bit later it was greyed out again & I had to make the wiz re-list the recordings to make it available again – I’ll see if I can pin down what sequence causes this.

Anyway, as to be expected, the getWizPnP --check problem when run from a WinXP PC as discussed starting here in the ‘Contents, Software and USB > getWizPnP - Beyonwiz recording downloader’ topic also appears when I run ‘Check Recordings’ from YARDWiz 0.1.4.
With the ‘Check Recordings’ I just did, it listed ‘data file 0077 missing’ in the bottom ‘Log’ window & in the YARDWiz log file for the current session, but it doesn’t show where it’s missing from if it was missing (which it isn’t).

Running getwizpnp -a -H (fixed IP address) --verbose --check from the cmd line shows:

Code: Select all

...
recordings/I Fish Jan.12.2012_17.0:
    data file 0036 missing
recordings/I Fish Jan.15.2012_17.28:
...

It stall or waits on recordings/I Fish Jan.12.2012_17.0: for 3 minutes before listing the missing data file & continuing. The missing data file being a different number is what happens with each following check.

[sub3R]

... but I’m not sure because after I got it to come up available, a bit later it was greyed out again & I had to make the wiz re-list the recordings to make it available again – I’ll see if I can pin down what sequence causes this.

This is what happens: With another application open in a window (eg. MS Word, Internet Explorer 8, etc), if YARDWiz 0.4.1 is opened & then all recordings listed on one of the wizzes, the ‘Check Recordings’ option is available providing the YARDWiz window is still selected as listing completes. But if a window with another open application is then selected, then the window with YARDWiz selected, the ‘Check Recordings’ option isn’t available anymore (greyed out). To make it available again all recordings must be re-listed & if the YARDWiz window is left during the listing it must be returned to before listing completes.
I get caught with this because I usually do something else on the PC while waiting for the files to be listed.

Also if YARDWiz 0.4.1 is opened & then all recordings listed on a wiz the ‘Check Recordings’ option is available - but if ‘Tools > Options’ is then opened & then closed, the ‘Check Recordings’ option isn’t available anymore (greyed out). If ‘Help > About’ is opened then closed, the same thing happens. Sometimes when ‘File’ is opened then closed, the same thing happens (this is hard to reproduce).

The above isn’t a problem now I know what causes it & what the workaround is. In fact it is probably good that it works this way because it can help stop ‘Check Recordings’ being accidently highlighted. Once ‘Check Recordings’ is highlighted the check process is started without asking for confirmation. I got caught with this when a DVD was being watched on the S1 that YARDWiz started checking & due the very low transfer rate (approx 1.1MB/s with a DVD playing), it sat there for ages & didn’t appear to start the check process - I ended up using ‘Exit’ to close YARDWiz down.

Edit: Sequences added to the first paragraph.

[sub3R]

I have added additional sequences in the first paragraph of my previous post.

[raymondjpg]

Short of rebooting the access point, I can't think what might be throttling the rate of data transfer..

All using YARDWiz 0.4.1, Win 7 Professional SP1 fully patched. P2 f/w .350.

1. Maximum rate of data transfer over Wireless N link limited to 1.9 MBps. Some downloads terminating prematurely.
2. Power cycled the wireless access point (Netgear WNR2000v3). No effect.
3. Updated firmware for the wireless access point. No effect. (An update would have been applied previously, but for an issue with password protection which fortuitously has been resolved in a version posted 24 February 2012.)
4. Updated drivers for PCI wireless adapter. No effect.
5. Applied RIP-2M (multicasting) on wireless access point. No effect. (I did not know if this would have any influence on data transfer, but there are two devices connected to the Netgear WNR2000v3, the P2 and a media player. At no time are they required to communicate with each other.)
6. Enabled WMM on the WNR2000v3. SUCCESS! Rate of data transfer from the P2 now a steady 3.1 MBps.
7. Disabled RIP-2M on wireless access point. Rate of data transfer from P2 still at 3.1 MBps.
8. Started a data stream to the file player from the pc. Bluray M2TS with a combined video.audio bitrate of 33 Mbps. File played flawlessly. Rate of data transfer from P2 still at 3.1 MBps, rate of data transfer from pc to file player 4.5 MBps.
9. Started a queued download of a SD and an HD file from the P2. The SD completed successfully, but the HD download terminated prematurely a number of times.
10. Re-enabled RIP-2M (multicasting) on wireless access point and re-started (not resume) download of HD file from the P2. Rate of data transfer from P2 3.2 MBps, rate of data transfer from pc to file player still at 4.5 MBps and file playing flawlessly. However, file transfer from the P2 did not proceed at a steady rate. On at least one occasion the file transfer paused at an apparent 0 MBps (as reported by YARDWiz) but resumed after a short while at 3.2 MBps.
11. The HD file transfer still terminated prematurely about half way in.

From this I have concluded that:

1. Enabling WMM on the (updated firmware) wireless access point has restored rate of data transfer from the P2 using YARDWiz 0.4.1 to a level at least as good as what I was getting with a wired connection. I don't know if the improvement might have been achieved by enabling WMM before updating the firmware on the access point.
2. Rate of data transfer from the P2 apparently improved from 3.1 to 3.2 MBps after enabling RIP-2M on the wireless access point, but ths might have been coincidental.
3. Unless anyone can see a potential benefit from enabling RIP-2M I have disabled it for now.
4. Unfortunately the improved rate of data transfer was not accompanied by any improvement to the premature termination of file transfer under my installation of Windows 7.

As a side benefit of this process I now find that with WMM enabled on the (updated firmware) wireless access point the file player (SMB) can now browse shares on the Windows 7 pc. Previously it could only do so if the access point was configured as the gateway, and not when trying to discover shares through two routers - the access point, and a D-Link configured as the gateway (for the internet). Again, I do not know if this improvement might have been achieved by enabling WMM before updating the firmware on the access point, or, come to that, if the improvement was achieved solely through the access point firmware update.

[sub3R]

... 11. The HD file transfer still terminated prematurely about half way in.

What does YARDWiz do when this happens – does it resume downloading without any user input? I assume it doesn’t resume going by one of your earlier posts:

... With the P2 set in file player mode and starting a 6 GB download with YARDWiz, it terminated after transferring 75 MB advising that the download of the file was complete. Asking YARDWiz to download the file again, it appeared to resume the previously truncated download.

Did this show anything abnormal in YARDWiz’s log for that particular session?

I realise our systems are different (WinXP home sp3 vs Win7 pro sp1, DP-S1 vs DP-P2, Ethernet LAN vs wireless) but when I disconnected the Ethernet lead for about 10 seconds during a download, YARDWiz 0.4.1’s transfer rate dropped to 0.0MB/s & stopped updating as expected. About 5 seconds after the lead was plugged back in YARDWiz resumed downloading as it should. The YARDWiz log for that download session doesn’t show anything abnormal.

To see if I could experience any download problems on my system I tried a few downloads at different transfer rates. Last night I successfully downloaded 5 SD recordings consecutively (each approx 5Mb/s) without any apparent issues (transfer rate was averaging 3.2MB/s).
Today I decided to consecutively download some HD recordings (each approx 12.3Mb/s) at a forced lower transfer rate (playing a DVD on the DP-S1 while downloading with YARDWiz). The transfer rate regularly dropped down to 0.5MB/s & never exceeded 1.2MB/s – it sat mainly around 0.9MB/s. After 2hrs I terminated the download & the downloaded recordings appear fine when played back on the S1 from the PC.
The trouble is I don’t know if the downloads stopped then resumed. I must try downloading with getWizPnP.exe without the --resume option.

Have you tried downloading using getWizPnP.exe from the command line to see if you still get early terminations?

That’s interesting about WMM. I checked my Belkin router & it has WMM disabled (although the wireless part only gets connected to the Vista Notebook). I must enable it & see what difference it makes to the Notebook.
The Belkin router handbook quotes:
“WMM (Wi-Fi Multimedia):
WMM based on 802.11e QoS (Quality of Service) prioritizes important data on your network such as multimedia content and voice-over-IP (VoIP) so it will not be interfered with by other data being sent over the network. This feature requires other wireless devices, such as Wi-Fi phone or wireless laptop, to support WMM for best results.”

This bit of information here indicates WMM should be left enabled.

[raymondjpg]

What does YARDWiz do when this happens – does it resume downloading without any user input? I assume it doesn’t resume going by one of your earlier posts:

Yes. If YARDWiz doesn't resume a stalled download, then it terminates with the log advising that the download has completed.

Did this show anything abnormal in YARDWiz’s log for that particular session?

Not to my recollection; the log reflects what grampus described in an earlier post in this thread.

I realise our systems are different (WinXP home sp3 vs Win7 pro sp1, DP-S1 vs DP-P2, Ethernet LAN vs wireless) but when I disconnected the Ethernet lead for about 10 seconds during a download, YARDWiz 0.4.1’s transfer rate dropped to 0.0MB/s & stopped updating as expected. About 5 seconds after the lead was plugged back in YARDWiz resumed downloading as it should. The YARDWiz log for that download session doesn’t show anything abnormal.

Same for me IIRC.

Have you tried downloading using getWizPnP.exe from the command line to see if you still get early terminations?

Not lately, but you can see from the getWizPnP thread that we went through a number of trial runs without prl being able to pin down the problem. At least with YARDWiz 0.4.1 one can resume a prematurely terminated download without losing what has already been downloaded. One may well be able to do that with getWizPnP but like grampus I much prefer a GUI option rather than fiddling with command lines or batch files. WizFX was also giving me problems after installation of Win 7 SP1, but has been behaving well for about six months or so now, so I would probably use that if I were to run an unattended download from the P2.

That’s interesting about WMM. I checked my Belkin router & it has WMM disabled (although the wireless part only gets connected to the Vista Notebook). I must enable it & see what difference it makes to the Notebook.
The Belkin router handbook quotes:
“WMM (Wi-Fi Multimedia):
WMM based on 802.11e QoS (Quality of Service) prioritizes important data on your network such as multimedia content and voice-over-IP (VoIP) so it will not be interfered with by other data being sent over the network. This feature requires other wireless devices, such as Wi-Fi phone or wireless laptop, to support WMM for best results.”

I too thought that was interesting, having consistently turned off all QoS features on wireless access points and routers thinking it would more likely than not interfere with file data transfer rates. I also thought it may have principal value with VoIP, which I don't have any interest in, at least for now. I might change my view if and when I am offered a more reliable NBN data link.

I have no idea if enabling WMM in the Netgear AP would make any difference if the media player was disconnected (I could try it if someone really wanted to know), or if with the media player connected WMM somehow prioritises or facilitates data flow to and from each device separately. It didn't appear to compromise data flow in either direction, from the P2 to the pc and to the media player from the pc, in my trial.

This bit of information here indicates WMM should be left enabled.

At first glance my reaction was that not all implementations of the wireless N draft standard are equal. Also, that the comments and recommendations regarding WMM related to a Netgear device. I'd be taking statements from Netgear like "the behavior found by the reader was normal!" and "Since WMM support is required for products to be certified for 802.11n, WMM comes enabled by default in all Wi-Fi Certified n APs and wireless routers" with a pinch of salt. AFAIK 802.11n is still a draft specification, and open to a variety of interpretations, each of which may (or may not) qualify for certification, that is if such certification even exists. Someone more knowledgeable than I on this may care to comment.

Netgear went from a Broadcom BCM4716 chip in the WNR2000v2 to an Atheros AR7240 chip in the WNR2000v3. I have both versions, and found the v2 to be more forgiving of single channel (20M) connections than the v3. The v2 is used as an access point for the Topfield PVR, and with WMM disabled achieves FTP file transfers upwards of the maximum data rate achievable over Cat5 ethernet i.e. about 8.3 MBps. FWIW it connects to a PCIe wireless adapter with an Atheros chip, and the WNR2000v3 to a PCI wireless adapter with a Ralink chip. Make of this what you will, but you can see why people consistently advocate use of wireless N devices from the same manufacturer, if not stable, as it is in their interests to make it work. I might also now be inclined to turn WMM on in any Netgear device if available, unless and until I could detect no conceivable benefit, in which case I might still be inclined to turn it off!

[sub3R]

Did this show anything abnormal in YARDWiz’s log for that particular session?

Not to my recollection; the log reflects what grampus described in an earlier post in this thread.

I forgot what grampus’ bottom window ‘Log’ looked like. I don’t get anything like that by temporarily unplugging the Ethernet lead.

Have you tried downloading using getWizPnP.exe from the command line to see if you still get early terminations?

... Not lately, but you can see from the getWizPnP thread that we went through a number of trial runs without prl being able to pin down the problem. ...

I now remember following that – so you’ve been there done that. I just had a re-read & everything does seem to point towards Win7 sp1, yet Peter (prl) couldn’t replicate the problem. And I was thinking of going with Win7 on my next PC.

BTW ... You can download the 802.11n 2009 IEEE Standard here if interested.

[raymondjpg]

I don’t get anything like that by temporarily unplugging the Ethernet lead.

To be clear, grampus' log shows what happens when a YARDWiz download terminates prematurely, then resumed by the user instructing YARDWiz to download the file again. It resumes from where it left off without any indication in the log of an error.

When a download stalls (like when temporarily unplugging the Ethernet lead) then resumes there is no entry in the log at all.

And I was thinking of going with Win7 on my next PC.

Don't be deterred. I like the aero themes, AHCI is enabled by default (if you so choose), and the 32 bit version can handle up to 4 GB of RAM compared to 2 GB for Win XP (untweaked). There are people here who have no difficulties with YARDWiz or getWizPnP on Win 7 SP1. My problems *may* track back to Outpost Free Security Suite. Even disabled, it may still have something running in the backgound that gets in the way of getWizPnP, but I haven't uninstalled it completely to find out and if it were the culprit I wouldn't be about to abandon it because it is currently the most effective software firewall option for my setup. I like to know what may be phoning home.

BTW ... You can download the 802.11n 2009 IEEE Standard here if interested.

I might just look at that but I would be more interested in whatever arrangements might be in place for "certification" and if it is yet anything more than adherence to, or compliance with, that Atheros was referring to in that link you provided in your previous post.

[sub3R]

Thanks for clarifying the premature termination vs. stall & resume.
So with a successful download (or an interruption & then resume by itself) it would look like this in YARDWiz’s log file for that session (this is part of the log file for the download where I temporarily unplugged the Ethernet lead):

Code: Select all

DEBUG __init__._Log: Downloading Dads Army...
DEBUG __init__._Log: Download of O:\--- PVR_RECORDINGS ---\--- Test11 ---\Dads Army 2012-02-28.tvwiz complete.

But if it terminated prematurely & was manually restarted once, going by grampus’ post it should show two of these instances.

Thanks for the reassurance on Win7, my only concern was it just sounded a bit hit or miss if one experienced download problems with YARDWIz.

... My problems *may* track back to Outpost Free Security Suite. Even disabled, it may still have something running in the backgound that gets in the way of getWizPnP, ...

One thing you could try if you suspect that, if you haven’t done so already, is to run a command line getWizPnP.exe download from Windows ‘Safe Mode with Networking’ after suspending any non-essential services with Process Explorer, & see if the download terminates unexpectedly. But that means fiddling around with various getWizPnP commands again which can be time consuming.

I might just look at that ...

Something to read on a rainy day by the sound of it. I haven’t looked at it but this link indicates it is 560 pages long.

[raymondjpg]

One thing you could try if you suspect that, if you haven’t done so already, is to run a command line getWizPnP.exe download from Windows ‘Safe Mode with Networking’ after suspending any non-essential services with Process Explorer, & see if the download terminates unexpectedly. But that means fiddling around with various getWizPnP commands again which can be time consuming.

That I haven't tried. Thanks!

[Luke]

... but I’m not sure because after I got it to come up available, a bit later it was greyed out again & I had to make the wiz re-list the recordings to make it available again – I’ll see if I can pin down what sequence causes this.

This is what happens: With another application open in a window (eg. MS Word, Internet Explorer 8, etc), if YARDWiz 0.4.1 is opened & then all recordings listed on one of the wizzes, the ‘Check Recordings’ option is available providing the YARDWiz window is still selected as listing completes. But if a window with another open application is then selected, then the window with YARDWiz selected, the ‘Check Recordings’ option isn’t available anymore (greyed out). To make it available again all recordings must be re-listed & if the YARDWiz window is left during the listing it must be returned to before listing completes.
I get caught with this because I usually do something else on the PC while waiting for the files to be listed.

Also if YARDWiz 0.4.1 is opened & then all recordings listed on a wiz the ‘Check Recordings’ option is available - but if ‘Tools > Options’ is then opened & then closed, the ‘Check Recordings’ option isn’t available anymore (greyed out). If ‘Help > About’ is opened then closed, the same thing happens. Sometimes when ‘File’ is opened then closed, the same thing happens (this is hard to reproduce).

The above isn’t a problem now I know what causes it & what the workaround is. In fact it is probably good that it works this way because it can help stop ‘Check Recordings’ being accidently highlighted. Once ‘Check Recordings’ is highlighted the check process is started without asking for confirmation. I got caught with this when a DVD was being watched on the S1 that YARDWiz started checking & due the very low transfer rate (approx 1.1MB/s with a DVD playing), it sat there for ages & didn’t appear to start the check process - I ended up using ‘Exit’ to close YARDWiz down.

Edit: Sequences added to the first paragraph.

Ok, back from holidays. I'll look into it in the next week or so.

[sub3R]

The cause may be related to what I discussed in this post here Luke (more info in my next post in that topic). I have a couple of fairly long log files on that one for you.

In addition to what I described in that topic, when ‘Save’ is pressed the ‘Tools > Option’ window flickers on & off quickly as it shuts down, it appears that this is when Wiz_02 changes to Wiz_01 as shown for ‘Wiz server:’. This was also there in YARDWiz 0.3.9 when I checked it on the Vista Notebook but the opposite way around (Wiz_02 is listed in front of Wiz_01 on the Notebook).

Neither of these worry me because I know the workaround.

[prl]

New beta of getWizPnP (0.5.3beta3) has been released. Brief release notes in the linked post.

Should fix all the oddities printing 64-bit recording offsets, limits the use of ephemeral ports in --check (with some loss of performance, especially on WinXP), and adds --stdout to allow copying of recordings to standard output (intended to allow streaming of recordings to computer applications without requiring any intermediate storage).

For the latter two, see the manual items for --check and --stdout.

[Luke]

Thanks Peter

[Luke]

YARDWiz 0.4.2 released!

Quite a few changes and bug fixes, plus getWizPnP is updated to the latest 0.5.3 version.

Code: Select all

===_New in 0.4.2_===
  * Add "Play in VLC" item to programs menu.
  * Add option to play in VLC with or without a temporary file (getWizPnP 0.5.3+ only).
  * Add getWizPnP version info to Help->About... dialog.
  * Added auto list recordings on startup and on Wiz server list selection change options.
  * Make discovered device IP address visible in combobox. 
  * Reselect previously selected device on preference save.
  * Move "Check recordings..." to Tools menu and add feedback when recordings are being checked.
  * Add feedback when recordings are being deleted.
  * Update getWizPnP to 0.5.3 in downloads that include a compiled version.

===_Fixed in 0.4.2_===
  * Fix sort bug after deleting when quick listing is enabled.
  * Handle exception when file dialog is cancelled.
  * Don't run post-download command if scheduled download is cancelled.
  * Don't allow downloading into an existing tvwiz dir.
  * Fix incorrect testing of file size (megabytes v.s mebibytes).
  * Fix bug when delete from Wiz fails.
  * Fix bug when download fails because of Wiz error.
  * Fix incorrect download complete message when download fails at the Wiz end.
  * Fix bug when delete from file system fails .
  * Catch 'Copy failed: Forbidden' getWizPnP response .
  * Advise user to rename a recording on the Wiz when multiple recordings with the same index exist.
  * Fix not listing recording name when there's a missing data file error .
  * Open logfile in "w" mode, not "wb" so line end is cr/lf not lf on Windows and it can be read properly in notepad.exe
  * Add better error handling in TVWiz to TS conversion.
  * Fix check recording menu item enabling bug.
  * Stop auto scrolling when selecting a control in the Tools->Options dialog.
  * Fix bug setting tooltip on option label in the Tools->Options dialog so both option label and option value display tooltips.
  * Symlink yardwiz.desktop to /usr/share/applications so it shows up in the Ubuntu Unity dash.
  * Include psutil in py2exe build. Resolves Issue 3.

[glow]

Thanks Luke and prl
I like the auto list recordings on startup - one click less and the list seems to appear much faster now.

[netmask]

Fantastic support and many thanks

[prl]

Thanks Luke and prl
I like the auto list recordings on startup - one click less and the list seems to appear much faster now.

One of the optimisations I made in getWizPnP to reduce the effect of the limits placed on ephemeral port use had the side-effect of making listing recordings, especially verbose listings, faster than in 0.5.2 (which doesn't have the port restrictions). There may have also been improvements in YARDWiz that assisted with the speed of listings,

[prl]

Fantastic support and many thanks

I think that one of the things that helped Luke get support for getWizPnP 0.5.3 out so quickly was that I'd made betas available, and that there was no significant change between 0.5.3beta4 and 0.5.3. In future releases of getWizPnP I also intend to make betas publicly available. It also helped that Luke and Dennis (sub3r) were able to assist with testing and debugging on the betas.

[Luke]

There may have also been improvements in YARDWiz that assisted with the speed of listings,

Nope, not a thing.

I think that one of the things that helped Luke get support for getWizPnP 0.5.3 out so quickly was that I'd made betas available, and that there was no significant change between 0.5.3beta4 and 0.5.3.

Absolutely.

[grampus]

I am having a problem downloading any files to my PC
The downloads terminate randomly through the download.
It amy be related to Wireless activity.
It seemd to go on for about 30 minutes, when I started a browser activity it seemed to coincide with the termination. Does not appear to have any error indication in the transfer window.
I have a P2 f/w .350
Dell Inspiron Windows 7
The P2 is connected to a wireless Telstra Gateway hardwire via ethernet.
The connection speed via wireless from gateway to the PC is 54 Mbs.
I had tried Yardwiz v 40, and 41 with similar results.

I've now tried the new YARDWiz, on the above environment.
Used it on both DP-Lite and P2.
The results have been great so far.
About 25 GB without a hiccup. I hadn't tried to check the throughput prior.
But on the above setup, around 2.2MB/s. Watching my router, the visual indication is that the transfer is so much more solid, as I feel that prior to this I would notice a visible stutter, then generally the Txfr would prematurely terminate.
Browser activity was also being done during the Txfer.

Pleased with the improvement.
Thanks.

[prl]

Hi, grampus, I'm glad the new YARDWiz working better for you, but I can't think of anything that I've done in getWizPnP that would make it perform better in your WLAN environment.

I think any improvement may be due to local changes (like reduction in interference or not so much traffic from other nearby people using the same WLAN channel). Did you ever try changing your WLAN channel when you were originally having the problem?

[grampus]

Hi, grampus, I'm glad the new YARDWiz working better for you, but I can't think of anything that I've done in getWizPnP that would make it perform better in your WLAN environment.

I think any improvement may be due to local changes (like reduction in interference or not so much traffic from other nearby people using the same WLAN channel). Did you ever try changing your WLAN channel when you were originally having the problem?

I hadn't tried changing channels, I only have 2 others that can be seen, and we are all separated.
At the time, I had the feeling it may have been more load dependant on the PC, as I seemed to be able to cause a bit of havoc when I was using a browser concurrently.
Then of course going down that path, the browser is using the same pipe, and may have been load on the wireless side.
Anyway, thanks for the thought, I'll keep it in mind when I am confronted with it again.

[ad]

Still have problems. Not only will it not complete a transfer from the DP2 but now it deletes the transferred ts file as well, i.e., it can no longer be appended as was possible previously.

From the log file:

Downloading Bargain Hunt - Devon...
Error, unable to download M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts.
getWizPnP STDOUT:7TWO: Bargain Hunt/Devon - Copy
getWizPnP STDERR:Error fetching M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts idehdd/Recordings/7TWO_Apr.20.2012_18.20+56037.66000.tvwiz/0020: 400 Bad request
Undefined subroutine &main::status_message called at script/getWizPnP.pl line 2680.

[Luke]

If you replace the version of getWizPnP.exe (0.5.3) distributed with YARDWiz with 0.5.2 you should be able to resume the downloads. As to why getWizPnP is failing with that error message, I'll leave that question to prl (getWizPnP author) to field.

Edit: as you didn't say... I assume you're using YARDWiz 0.4.2 on Windows.

[Half Round]

Still have problems. Not only will it not complete a transfer from the DP2 but now it deletes the transferred ts file as well, i.e., it can no longer be appended as was possible previously.

From the log file:

Downloading Bargain Hunt - Devon...
Error, unable to download M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts.
getWizPnP STDOUT:7TWO: Bargain Hunt/Devon - Copy
getWizPnP STDERR:Error fetching M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts idehdd/Recordings/7TWO_Apr.20.2012_18.20+56037.66000.tvwiz/0020: 400 Bad request
Undefined subroutine &main::status_message called at script/getWizPnP.pl line 2680.

Hi Luke and prl,
Using Yardwiz 0.4.2. on windows 7 and was getting similar messages. First problem getting going was the transfer just starting then bombing out with the 400 Bad request - yes the request has a small 'r'. Stopped the Trend virus checker and the transfer would run for a short while and then bomb out with the line 2680 error
Then ran with Yardwiz 'run as administrator' right click and the transfer would complete successfully. Not exhaustive testing only downloading 6 minute file.

[Half Round]

Hi luke & prl,
Update:
Had a closer look at the downloading. Found I had a name/password error between the wiz and user accounts which I fixed. Have not seen line 2680 error since.
I am now running the yardwiz as a 'normal' program i.e not running with administrator rights.
Still having '400 Bad request errors' though.

Code: Select all

The WizPnP server is online.
Downloading Nowra...
Error, unable to download C:\Users\Public\Documents\Nowra 2012-04-15k.ts.
getWizPnP STDOUT:A/V Input: Nowra - Copy
getWizPnP STDERR:Error fetching C:\Users\Public\Documents\Nowra 2012-04-15k.ts idehdd/Recordings/Nowra_Apr.15.2012_17.18+56032.62326.tvwiz/0004: 400 Bad request
Copy failed: Bad Request

If I select a new save filename for the download it may or may not complete without an error. If it does error, keeping trying with the same filename, the download will complete after 2 or 3 attempts.

[ad]

Edit: as you didn't say... I assume you're using YARDWiz 0.4.2 on Windows.

Indeed I do. Also running Windows 7 Ultimate.

Have totally uninstalled YARDWiz, cleaned out the registry, rebooted the OS and reinstalled YARDWiz 0.4.2 Tried again to download the same program from the Beyonwiz but failed again.

[Luke]

prl might have missed these posts, perhaps you could post the error messages in the getWizPnP thread.

[prl]

Prl has been reading these posts, but unfortunately he has no more to add than what was said in getWizPnP topic back in May/June last year. He only just got around to digging out the old discussion. The problem is known about but is unresolved. I haven't been able to reproduce it on my setup.

If the linked discussion is tl;dr: The problem is caused when the Beyonwiz HTTP server receives a message that's too short to be a legal HTTP request (400: Bad request). I can't see how that can be possible after looking at the source of Perl HTTP-related packages. I also added some debug code to a compiled version, and ramondjpg ran that on his system, got the error, but without the extra debug information throwing any light on the problem.

Any offers to assist in tracking down the problem by running getWizPnP with additional debug information will be taken up.

[Luke]

Ahhh yes, I remember reading that discussion now.

[Half Round]

Hi Luke and prl,

I have tried a large number of combinations of networking from crossover lead between computer and Wiz to networking involving/ not involving wireless plus using 2 different routers.
Yardwiz 0.4.2
Computers - One XP SP3 and one Windows 7 32 bit. Storing download on computer hard drive or small NAS unit.
Networking - iinet BOB or/and Linksys E1000.
Wiz DPP2 later model with v 01-07-350 f/w and also tried 01-07-069 f/w.

Results for both computers was similar. Often the transfer failed to complete. If the transfer failed then the same message that
'ad' was getting occurred:

Downloading Bargain Hunt - Devon...
Error, unable to download M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts.
getWizPnP STDOUT:7TWO: Bargain Hunt/Devon - Copy
getWizPnP STDERR:Error fetching M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts idehdd/Recordings/7TWO_Apr.20.2012_18.20+56037.66000.tvwiz/0020: 400 Bad request
Undefined subroutine &main::status_message called at script/getWizPnP.pl line 2680.

I was using a 10 minute file and a couple of 1 hour files.
Not all transfers failed. If a transfer failed it was at a random (non repeatable) time.
If the transfer was tried again it might fail at a different time. Repeated tries to transfer of a program would eventually end in success.

Side observation: On win7 the wiz server drop down box in Yardwiz is not sticky between uses of the program, but it is on win XP.

prl I would be happy to try some debugging.
Things I have noticed: Pinging the wiz there can be some latency initially but it is generally around 1ms . The 'rate of errors' on the XP machine seemed to decrease when I reduced the Ethernet card receive buffer from 64kb to its minimum of 8k.

VLC via Yardwiz plays the files from the wiz OK.(only tried on the XP machine)

[prl]

...

Downloading Bargain Hunt - Devon...
Error, unable to download M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts.
getWizPnP STDOUT:7TWO: Bargain Hunt/Devon - Copy
getWizPnP STDERR:Error fetching M:\HB_output\Bargain Hunt - Devon 2012-04-20.ts idehdd/Recordings/7TWO_Apr.20.2012_18.20+56037.66000.tvwiz/0020: 400 Bad request
Undefined subroutine &main::status_message called at script/getWizPnP.pl line 2680.

...

The last line "Undefined subroutine..." is a getWizPnP bug. But all it would have printed if the bug wasn't there would have been "Copy failed: Bad Request", and it would have continued on to do any more copies that it should have.

prl I would be happy to try some debugging.
Things I have noticed: Pinging the wiz there can be some latency initially but it is generally around 1ms . The 'rate of errors' on the XP machine seemed to decrease when I reduced the Ethernet card receive buffer from 64kb to its minimum of 8k.

VLC via Yardwiz plays the files from the wiz OK.(only tried on the XP machine)

Thanks for the offer to help with the debugging.

What sort of error rates are you seeing from the Ethernet card? However, the fact that you also see the same problem on the Win7 machine seems to make it less likely that this is the source of the problem. I also get ~1ms latency from pinging our DP-Lite, but I can't seem to make the problem happen on my system (either when I run OS X, as usual or when I run Win7 - both on MacBook Pro).

I need to have a bit more of a think about what sort of debug info would be helpful. IIRC, the last time I tried this, we established that the request contents were correct, even though the Beyonwiz server said that they weren't. The error seems almost certainly to be coming from the Beyonwiz. It uses shttpd as its HTTP server, and I have a copy of the (original open-source) code, though I have no guarantee that what Beyonwiz runs is exactly the same. In that code, this error is only generated with that error string (Bad request) if the received request is shorter than a HTTP request can possibly be (16 bytes). But the request to be sent looks OK.

While I ponder what debugging might be useful, I'll have another try at replicating the problem at my end.

Are you able to run getWizPnP from the Perl source, or would you prefer a precompiled version when I have something ready?

[Half Round]

Hi Peter,

My feeling is that a buffer may be getting full and overwriting or truncating data. Otherwise maybe interrupts or time of program execution through different paths may be causing problems. If I had to pick a problem point it would be the wiz with its limited time for processing requests due to processor power or amount of buffering it has available.

A precompiled version would be great.
Maybe some method of introducing a delay between requests to the HTTP server? This may indicate if it is a network thing or something else.
I just used netstat -s and compared discards and errors before a (5minute) failed transfer and after, there was no difference.

[prl]

...
Maybe some method of introducing a delay between requests to the HTTP server? This may indicate if it is a network thing or something else. ...

When it's copying files, getWizPnP only issues one HTTP GET request per file. The header files are small and copy quite quickly, but the data files are mostly about 32MB, and with a transfer rate usually no better than 3MB/sec each one of them takes 10 sec or so to copy.

I could insert further delay between the completion of a transfer and the start of the next, though.

I really can't see how any of this should be causing any reasonable-speed PC any problems due to Ethernet buffer over-runs. The Beyonwiz only wants to push through 3MB/sec; a 100Mb/sec Ethernet card should have no problem running close to 10MB/sec.

[Half Round]

Hi Peter,
I have been testing with the network set up the way I want it, which includes a client bridged router running dd-wrt. The wiz in question and another (soon) are connected to this router. Throughput is a bit down at about 1.9MB/S indicated by Yardwiz. The network monitor on task manager indicates 16% to 18% load and the CPU is ~7%.

When an error occurs is it a result of several retries? Can the downloading wind back and try again? Questions I ask as I have no detailed knowledge of how this works.

Over the next couple of days I will connect the wiz with a crossover cable and play with a few of the settings on the ethernet card to see what happens.

I really don't have that many items to transfer to computer, so could put up with the errors. I will be mainly running the 2 wizzes networked together so that a full change over is not required to watch recorded programs.
It would still be nice to know what is going on though.

[prl]

...
When an error occurs is it a result of several retries? Can the downloading wind back and try again? Questions I ask as I have no detailed knowledge of how this works.
...

getWizPnP only makes one attempt to download each file, if that's what you mean. In this case, as far as I can tell, getWizPnP (via the Perl LWP package) is reporting an error that was generated by the Beyonwiz's HTTP server, and again that appears to be because the server has receives a HTTP request that is too small to be legal. getWizPnP could do a retry on the file for "400 Bad request" errors, but I'd prefer to try to find out what's causing the problem.

You can manually "wind back and start again" by repeating the download using the --resume option. That will re-start copying from the point at which the last copy left off (to the byte). I think that if you use YARDWiz to run getWizPnP than --resume is always used, but Luke can answer that for sure.

[Luke]

I think that if you use YARDWiz to run getWizPnP than --resume is always used, but Luke can answer that for sure.

Correct.

[Half Round]

I think that if you use YARDWiz to run getWizPnP than --resume is always used, but Luke can answer that for sure.

Correct.

Not quite sure how this works in Yardwiz. After a transfer crashes the part downloaded file disappears from the destination folder and the download starts again from the start. Same happens if Yardwiz is paused and then closed. Upon opening Yardwiz it just starts at the beginning again.

[If you replace the version of getWizPnP.exe (0.5.3) distributed with YARDWiz with 0.5.2 you should be able to resume the downloads. As to why getWizPnP is failing with that error message, I'll leave that question to prl (getWizPnP author) to field. ]

Tried this with no change to above.
All running on winXPSP3 machine.

[sub3R]

... After a transfer crashes the part downloaded file disappears from the destination folder and the download starts again from the start. Same happens if Yardwiz is paused and then closed. Upon opening Yardwiz it just starts at the beginning again.

Seeing I have WinXP sp3 I have been trying to replicate a download failure by unplugging the router to wiz Ethernet cable for a short period then restoring the connection. So far with the limited number of tests carried out the download eventually resumed each time - I noticed it does take quite some time to start downloading again. With normal downloading I haven’t had any failures to date.

However I think I have uncovered another bug when downloading an ABC1 SD recording from the DPS1 to a USB drive on the PC as a .ts file.
After downloading approx 100MB of the 562MB recording I clicked the pause option at the bottom of YARDWiz to pause the download. After leaving the download paused for about 15sec I clicked the resume download button to resume the download. After quite some time (I didn’t time this but it was more than a minute) the download resumed for a short period then stopped downloading & deleted the partially downloaded file from the PC.

The log at the bottom of YARDWiz showed:
...
Finished listing programs on the WizPnP server
The WizPnP server is online.
Downloading Minuscule...
Download paused.
Downloading Minuscule...
Error, unable to download O:\--- PVR_RECORDINGS ---\--- Seen_keep ---\Minuscule 2012-05-02.ts.
getWizPnP STDOUT:ABC1: Minuscule/A group of black ants get their load -a nice nut - stolen by a band of red ants. But the leader of the black ants isn't prepared to give up the fight. - Copy
getWizPnP STDERR:

Part of YARDWiz log file ‘YARDWiz.20120503.121316.1710.log’ for this session shows:

Code: Select all

...
DEBUG __init__._Log: Finished listing programs on the WizPnP server
DEBUG utilities.subproc: getWizPnP.exe --all -q -R --BWName -O "O:\--- PVR_RECORDINGS ---\--- Seen_keep ---" -T "Minuscule 2012-05-02" "recordings/Minuscule May.2.2012_18.53" -H (static IP address) -p 49152 -t
DEBUG utilities.subproc: ['getWizPnP.exe', '--all', '-q', '-R', '--BWName', '-O', 'O:\\--- PVR_RECORDINGS ---\\--- Seen_keep ---', '-T', 'Minuscule 2012-05-02', 'recordings/Minuscule May.2.2012_18.53', '-H', '(static IP address)', '-p', '49152', '-t']
DEBUG __init__._Log: The WizPnP server is online.
DEBUG __init__._Log: Downloading Minuscule...
DEBUG utilities.subproc: pskill /accepteula -t 3760
DEBUG utilities.subproc: ['pskill', '/accepteula', '-t', '3760']
DEBUG utilities.kill: Killed process 3760, 1
DEBUG __init__._Log: Download paused.
DEBUG __init__.cbxDevice_OnKillFocus: (static IP address):49152 Wiz_01;(static IP address):49152 Wiz_02
DEBUG __init__.cbxDevice_OnKillFocus: OrderedDict([('Wiz_01 (static IP address:49152)', <yardwizgui.utilities.Device object at 0x01C39A90>), ('Wiz_02 (static IP address:49152)', <yardwizgui.utilities.Device object at 0x01C39CF0>)])
DEBUG __init__.cbxDevice_OnKillFocus: [<yardwizgui.utilities.Device object at 0x01C39A90>, <yardwizgui.utilities.Device object at 0x01C39CF0>]
DEBUG __init__._Log: Downloading Minuscule...
DEBUG utilities.subproc: getWizPnP.exe --all -q -R --BWName -O "O:\--- PVR_RECORDINGS ---\--- Seen_keep ---" -T "Minuscule 2012-05-02" "recordings/Minuscule May.2.2012_18.53" -H (static IP address) -p 49152 -t
DEBUG utilities.subproc: ['getWizPnP.exe', '--all', '-q', '-R', '--BWName', '-O', 'O:\\--- PVR_RECORDINGS ---\\--- Seen_keep ---', '-T', 'Minuscule 2012-05-02', 'recordings/Minuscule May.2.2012_18.53', '-H', '(static IP address)', '-p', '49152', '-t']
DEBUG __init__._Log: Error, unable to download O:\--- PVR_RECORDINGS ---\--- Seen_keep ---\Minuscule 2012-05-02.ts.
DEBUG __init__._Log: getWizPnP STDOUT:ABC1: Minuscule/A group of black ants get their load -a nice nut - stolen by a band of red ants. But the leader of the black ants isn't prepared to give up the fight. - Copy
DEBUG __init__._Log: getWizPnP STDERR:
DEBUG __init__.cbxDevice_OnKillFocus: (static IP address):49152 Wiz_01;(static IP address):49152 Wiz_02
DEBUG __init__.cbxDevice_OnKillFocus: OrderedDict([('Wiz_01 (static IP address:49152)', <yardwizgui.utilities.Device object at 0x01C39A90>), ('Wiz_02 (static IP address:49152)', <yardwizgui.utilities.Device object at 0x01C39CF0>)])
DEBUG __init__.cbxDevice_OnKillFocus: [<yardwizgui.utilities.Device object at 0x01C39A90>, <yardwizgui.utilities.Device object at 0x01C39CF0>]
DEBUG __init__.cbxDevice_OnKillFocus: (static IP address):49152 Wiz_01;(static IP address):49152 Wiz_02
DEBUG __init__.cbxDevice_OnKillFocus: OrderedDict([('Wiz_01 (static IP address:49152)', <yardwizgui.utilities.Device object at 0x01C39A90>), ('Wiz_02 (static IP address:49152)', <yardwizgui.utilities.Device object at 0x01C39CF0>)])
DEBUG __init__.cbxDevice_OnKillFocus: [<yardwizgui.utilities.Device object at 0x01C39A90>, <yardwizgui.utilities.Device object at 0x01C39CF0>]
DEBUG __init__._WriteConfig: 'Settings'
...

This appears to be an intermittent bug – once I had to pause the recording three times before it failed – other times I couldn’t make it fail. I have ‘pskill.exe’ in the YARDWiz directory. I didn't have Wiz_01 switched ON.

Luke, I notice with this version (0.4.2) the font size appears to be slightly larger than previous versions in the top ‘Wiz Server’ box. With this size font the complete Wiz device ‘Wiz_02 (static IP address)’ doesn’t quite fit – the ‘W’ at the beginning of ‘Wiz_02’ is left out.

I like the option of being able to disable auto listing – very handy when one has two or more wizzes.

[sub3R]

An update on the above pause/resume download failure.

When I tried to download a short 326MB test recording from the 2nd wiz (Wiz_01) to an internal HDD in the PC in .ts format I got the following results:

Sequence of events with getWizPnP.exe 0.5.2 in the YARDWiz program files directory:

• Started downloading (right click > download now) the recording.
• After 100MB had downloaded clicked ‘pause download’ (the download paused).
• After 30 seconds clicked ‘resume download’ (nothing happened for 15 seconds – download speed remained on 0.0MB/S).
• The download resumed at the normal download speed & the download completed.

Sequence of events with getWizPnP.exe 0.5.3 in the YARDWiz program files directory:

• Started downloading (right click > download now) the recording.
• After 100MB had downloaded clicked ‘pause download’ (the download paused).
• After 30 seconds clicked ‘resume download’ (nothing happened for 6 minutes – download speed remained on 0.0MB/S).
• The download resumed for only 20 seconds at the normal download speed & the download then stopped & the partially downloaded recording was deleted from the PC. Error message displayed.

The above results are fairly consistent with this setup.

[Luke]

I'll look into that Dennis.

[sub3R]

Luke, not sure if this helps. I just got a slightly different type of failure when trying the same sequence as previously, but I was downloading to .tvwiz format instead of .ts format (getWizPnP.exe 0.5.3).

After pausing & clicking ‘resume download’, the download resumed after approx 15 seconds & continued downloading almost the complete recording before failing (Windows Explorer shows 306MB of ~326MB downloaded).

Part of the log at the bottom showed:
...
Downloading Motor Mate-test...
Download paused.
Downloading Motor Mate-test...
Error, unable to download E:\test\Motor Mate-test 2012-05-03.tvwiz.
getWizPnP STDOUT:7mate Taree: Motor Mate-test/Jaguar spearheaded Britain's entry into the world of supercars, previously dominated by Italian stylists and engineers. *AC3 - Copy
getWizPnP STDERR:
Error: Unable to delete E:\test\Motor Mate-test 2012-05-03.tvwiz

If you need any log files, or if the earlier posted log file isn’t clear, let me know.

[sub3R]

Interesting ... when I look further at that last .tvwiz download failure, the failure wasn’t near the end it was at data file 0004 which was 12,088KB instead of 32,768KB. This would have been about where it was paused or resumed.
Compared to a successful uninterrupted download of the same recording this was the only non complete data file. The last data file (0010) was 6,180MB in both instances (successful & unsuccessful).

[prl]

Luke, I tried again to replicate the problem you're having on my Mac running Win7. I downloaded 23.5GB in 6 recordings without any issue.

I'll make up a debug version of getWizPnP that prints more information from the LWP package, which handles the HTTP connection, when it gets a 400 error from the server. I'll also add an option to insert a delay before each HTTP request.

[Half Round]

Still playing with the XP machine.

Tried to turn on debugging but it crashes Yardwiz each time I try.

Code: Select all

DEBUG __init__._ApplyConfig: Devices="192.168.1.150;192.168.1.155"
DEBUG __init__._ApplyConfig: Devices="['192.168.1.150', '192.168.1.155']"
DEBUG utilities.__init__: Adding new Device
DEBUG utilities.__init__: Device IP,Port,Name="192.168.1.150,49152,"
DEBUG utilities.__init__: Device display="192.168.1.150"
DEBUG utilities.__init__: Device args="['-H', '192.168.1.150', '-p', '49152']"
DEBUG utilities.__init__: Device str="192.168.1.150"
DEBUG utilities.__init__: Adding new Device
DEBUG utilities.__init__: Device IP,Port,Name="192.168.1.155,49152,"
DEBUG utilities.__init__: Device display="192.168.1.155"
DEBUG utilities.__init__: Device args="['-H', '192.168.1.155', '-p', '49152']"
DEBUG utilities.__init__: Device str="192.168.1.155"
DEBUG __init__._ApplyConfig: 192.168.1.150;192.168.1.155
DEBUG __init__._ApplyConfig: OrderedDict([('192.168.1.150', <yardwizgui.utilities.Device object at 0x01C51810>), ('192.168.1.155', <yardwizgui.utilities.Device object at 0x01C51A10>)])
DEBUG __init__._ApplyConfig: [<yardwizgui.utilities.Device object at 0x01C51810>, <yardwizgui.utilities.Device object at 0x01C51A10>]
DEBUG __init__._ApplyConfig: Window size: xmin 353, ymin 126, xsize 927, ysize 742
DEBUG __init__._ApplyConfig: Window resolution: xres 1280, yres 990
DEBUG __init__._ApplyConfig: CanSetTransparent: True
DEBUG __init__._ApplyConfig: VLC path: vlc
DEBUG utilities.subproc: getWizPnP.exe --version
DEBUG utilities.subproc: ['getWizPnP.exe', '--version']
ERROR utilities.write: Traceback (most recent call last):
ERROR utilities.write: File "yardwizgui\__init__.pyc", line 1416, in mitPreferences_OnSelect
ERROR utilities.write: File "yardwizgui\__init__.pyc", line 385, in _ApplyConfig
ERROR utilities.write: KeyError
ERROR utilities.write: :
ERROR utilities.write: 'tempfile'
ERROR utilities.write: 

Otherwise Yardwiz with getwizpnp 0.5.2 seems to be working OK for me.
When watching the network through Task Manager I see the network rate drop to zero very occasionally but it keeps going and completes the download.

[prl]

I'm not sure if this might be contributing to the YARDWiz problems but in 0.5.2 and 0.5.3 there was an unintended change from the behaviour of 0.5.1 in the --verbose output of getWizPnP when copying. In earlier versions, there was a blank line between the progress bar of one recording copy and the information for the next. In 0.5.2 and 0.5.3 that blank line disappears.

That also means that if there's a copy error in 0.5.2 or 0.5.3 , you'll see something like:

Code: Select all

|==================================================| 3.1MB/s 100% 74/74MBCopy failed: some lame excuse

where it should be

Code: Select all

|==================================================| 3.1MB/s 100% 74/74MB
Copy failed: some lame excuse

The progress bar is on getWizPnP's stdout, while the error message is on its stderr, so that may or may not cause problems for YARDWiz, depending on just how YARDWiz deals with getWizPnP's output.

However, the difference that Dennis is reporting appears to be between 0.5.2 and 0.5.2.

The blank line will be restored in the next release and in the debug version I'm working on for Tony (Half Round).

[sub3R]

Interesting ... when I look further at that last .tvwiz download failure, the failure wasn’t near the end it was at data file 0004 which was 12,088KB instead of 32,768KB. This would have been about where it was paused or resumed.

To clarify this – on further investigation it looks like I paused the YARDWiz download when data file 0004 was part way through the download & that file didn’t resume downloading, therefore only from the beginning up to the paused part of the file was downloaded. The download resumed at the start of 0005.

Hi Peter. Yes I was testing YARDWiz download/pause between getWizPnP.exe 0.5.3 & 0.5.2 – just dropping these into YARDWiz 0.4.2.0.
I couldn’t try getWizPnP.exe 0.5.1 in YARDWiz 0.4.2 – YARDWiz crashes when the download option is changed to .ts format with this version.
The 0.5.3 version was as supplied with YARDWiz 0.4.2.
I have 3 different 0.5.2 versions; (8,043,597 bytes 12-Jun-11), (8,044,146 bytes 15-Jun-11) & (5,255,845 bytes 16-Jun-11). A couple of these were for specific YARDWiz versions, the version I used was the one supplied with YARDWiz 0.3.9 (8,043,597 bytes 12-Jun-11).

[sub3R]

... I just got a slightly different type of failure when trying the same sequence as previously, but I was downloading to .tvwiz format instead of .ts format (getWizPnP.exe 0.5.3).
After pausing & clicking ‘resume download’, the download resumed after approx 15 seconds & continued downloading almost the complete recording before failing (Windows Explorer shows 306MB of ~326MB downloaded).

I just got the same type of download/pause failure with getWizPnP.exe 0.5.2 in YARDWiz 0.4.2 (I didn’t try this .tvwiz download/pause test with 0.5.2 yesterday). Downloading the same test recording I paused a fraction later & the incomplete data file was 0005 instead of 0004 – all other data files were correct.

A bit more feedback on the different getWizPnP.exe versions in YARDWiz 0.4.2:
After the above download failure I now find YARDWiz crashes every time I try to toggle the download option from .tvwiz to .ts (except with 0.5.3), even after restarting YARDWiz. With yesterday’s tests I was only getting this with getWizPnP.exe 0.5.1, not with 0.5.2 – but now I also get this with 0.5.2 as well as 0.5.1. At one stage I managed to get YARDWiz to start up with .ts as the download option but it crashed when I tried to toggle this to .tvwiz.
I don’t get this problem with getWizPnP.exe 0.5.3 in YARDWiz – it just isn’t happy with getWizPnP.exe 0.5.2 or 0.5.1.