Yet Another Recording Downloader for the Wiz

prl · Post by **prl** » Thu May 10, 2012 17:18

If you've been having problems with "400 Bad request" errors in the Windows version of getWizPnP, and would like to help find the cause of the bug, there's a debug version of 0.5.3 available.

When it gets a 400 error, it will print the contents of the HTTP request and response on stderr. If you try the debug version and get a 400 error, please post this output.

The debug version also has an option --delay=delaySecs to insert a delay in seconds before each HTTP request, to allow HalfRound's sugestion that the problem may be due to getWizPnP making requests too fast after each other for the Beyonwiz HTTP server to cope can be checked. The option may take floating point values (e.g. --delay=0.5).

The debug version also has a fix to the "Unknown subroutine" error that HalfRound found when getWizPnP encounters the 400 Bad Request error. This isn't a fix for the underlying error, it just fixes getWizPnP's error message printing when one happens. It also ensures that a newline is printed between the progress bar in --verbose and the error message.

Luke · Post by **Luke** » Sat May 12, 2012 18:55

I've fixed the Wiz Server box font/size issue and added the option to automatically retry failed downloads. This will be in the next release.

Re. the incomplete tvwiz data files when resuming a download that Dennis reported, it looks like getWizPnP resumes the download starting from the next datafile so the datafile that was downloading before the transfer was interrupted is left incomplete. I've added some code to my dev version of YARDWiz to delete the last NNNN tvwiz datafile after a pause or failed download, but that's really a bandaid solution and won't help getWizPnP command line users. prl, would it be possible to modify getWizPnP so it will resume a partially downloaded tvwiz datafile (assuming the BW http server supports the Range: header)?

prl · Post by **prl** » Sat May 12, 2012 19:13

Luke wrote:... prl, would it be possible to modify getWizPnP so it will resume a partially downloaded tvwiz datafile (assuming the BW http server supports the Range: header)?

It's supposed to do just that. I'll check. And yes, the Beyonwiz http server has the Range: header. Every datafile request uses it.

sub3R · Post by **sub3R** » Sat May 12, 2012 20:30

Luke wrote:I've fixed the Wiz Server box font/size issue and added the option to automatically retry failed downloads. This will be in the next release.

Thanks Luke.
In regards to the fix you mentioned for the incomplete data file after a download pause/resume, does that also fix the download pause/resume issue when downloading to .ts format (YARDWiz waiting for 6min after resuming from a pause then deleting the partially downloaded file)?

I realise Peter’s debug version of getWizPnP.exe 0.5.3 wasn’t intended to fix both the above issues (.tvwiz & .ts format download) but I thought I would try that version in YARDWiz 0.4.2 & I still got the same download issues after pausing then resuming as I reported earlier.

Luke · Post by **Luke** » Sat May 12, 2012 22:02

No, I'm afraid not. I think you've discovered another (or related) getWizPnP bug though

Using getWizPnP (0.5.3) from the command line, I started downloading a recording in TS format. I killed it after 30 sec. then restarted (--resume). I didn't check network activity, but I could hear HDD activity on the PVR however the file size didn't start increasing until 30 seconds had passed. I deleted the downloaded file and started the download over again, letting it run for a minute this time before killing it. I restarted the download and the file size didn't start increasing until a minute later. Same thing when I let the download run for 3 minutes, resuming took 3 minutes before file size increased. I think perhaps the file is getting downloaded from the beginning instead of resuming from the end.

Edit: I just tried 0.5.2 and resuming starts straight away.

prl · Post by **prl** » Sat May 12, 2012 23:05

Luke wrote:... I think perhaps the file is getting downloaded from the beginning instead of resuming from the end.

From what you've described, that seems likely. It may be a bug introduced by the --stdout option.

sub3R · Post by **sub3R** » Sun May 13, 2012 10:55

Luke wrote:No, I'm afraid not. I think you've discovered another (or related) getWizPnP bug though

Just a guess, but I think the two download pause/resume issues (.tvwiz & .ts) may be related.

What you found by running the command line tests does sound similar to what’s happening in YARDWiz, however the 6 minutes I’m getting seems to be too long, unless this is some other timeout (it is less than 1min before I click pause then 30sec before I click resume download) (See my post here & the very next post). After the 6min period I find the download resumes or starts again for approx 20sec then YARDWiz deletes the file, brings up the error message & doesn’t restart or resume again (this is how it appears watching YARDWiz’s feedback & Windows Explorer). I’ll do some more tests downloading to .ts with YARDWiz & vary the period before pausing to see if the 6min period changes.

When I first discovered this I was going to see what happens running getWizPnP.exe from the command prompt, but off the top of my head I couldn’t think how to pause the download – I didn’t think of just stopping the download with <Ctrl C> then running the command again.

Luke · Post by **Luke** » Sun May 13, 2012 11:58

sub3R wrote:What you found by running the command line tests does sound similar to what’s happening in YARDWiz, however the 6 minutes I’m getting seems to be too long, unless this is some other timeout (it is less than 1min before I click pause then 30sec before I click resume download). After the 6min period I find the download resumes or starts again for approx 20sec then YARDWiz deletes the file, brings up the error message & doesn’t restart or resume again

I've just run a few tests, letting a download run for various lengths of time in YARDWiz before pausing and resuming. The resume time was within a few seconds of the previous download time every time, same as I got running getWizPnP from the command line.

YARDWiz (0.5.2) will only delete the file if the getWizPnP process exits early, i.e. if there's some sort of error. Whatever is going on there for you I can't reproduce as YARDWiz always (eventually) resumes and keeps downloading for me. The next version (0.5.3) will retry the download a (user specified, default=3) number of times before giving up and (optionally, user preference setting) deleting the failed file.

prl · Post by **prl** » Sun May 13, 2012 16:25

In doing all this, I've found another bug in --resume - it won't work properly if the recording has been edited. In particular, this bug will affect resuming topped-and-tailed recordings. I now need to go back and check for problems in --resume where the recording hasn't been edited!

Fixing --resume on edited recordings is going to take a bit of recoding, so I'll try to get a test version for any bugs I can find on resuming unedited files.

Luke, I can fairly easily add a retry option into getWizPnP (when the bugs have been sorted). When that's done, you can seamlessly change your retry to use the getWizPnP retry option.

prl · Post by **prl** » Sun May 13, 2012 18:17

I've found the bugs that were causing problems with --resume on unedited and top/tailed recordings, but there are still some unresolved problems with recordings with internal edits.

There were two bugs fixed so far; an operation being performed on the wrong object and fixing a -s test (size non-zero) on a file handle to the intended -S (is a socket).

sub3R · Post by **sub3R** » Sun May 13, 2012 21:57

prl wrote:In doing all this, I've found another bug in --resume - it won't work properly if the recording has been edited. In particular, this bug will affect resuming topped-and-tailed recordings. I now need to go back and check for problems in --resume where the recording hasn't been edited!

Good work - that gives me a few things to try in YARDWiz.

For the record: In this test, the recording ‘Minuscule’ I used wasn’t edited.
In this test & all following tests to date, the short test file called ‘Motor Mate-test’ was A-B copied to a new file from a ‘keep A-B only’ edited recording called ‘Motor Mate’.

sub3R · Post by **sub3R** » Mon May 14, 2012 18:10

Post deleted ... test results taking up a lot of space & a fix is already underway.

prl · Post by **prl** » Mon May 14, 2012 19:02

--resume in getWizPnP 0.5.3 is irredeemably broken, whether on .ts or .tvwiz downloads, edited or not [resists temptation to quote something from the dead parrot sketch].

I'll be releasing 0.5.3debug2 soon, which should fix these strange resume problems. The fix is tested on OS X, but not yet on Windows.

In doing this, I've realised that if you start a recording download, interrupt it, edit the recording, and then resume the download, things might go very strange indeed. This problem is probably fixable for .tvwiz downloads, but not for .ts downloads. But I think the best "fix" is to put a note in the documentation.

Luke · Post by **Luke** » Mon May 14, 2012 19:39

prl wrote:But I think the best "fix" is to put a note in the documentation.

Sounds fair enough to me. No need for anyone to register a complaint. Sorry, couldn't resist.

prl · Post by **prl** » Wed May 16, 2012 10:04

A new debug version of getWizPnP, 0.5.3debug2 is available. It includes the debugging code added for the 400 Bad Request problem, and fixes for --resume.

It should be drop-in compatible in YARDWiz as a replacement for getWizPnP 0.5.3.

sub3R · Post by **sub3R** » Wed May 16, 2012 22:19

So far I’ve come up with two unusual .tvwiz pause/resume download results with YARDWiz 0.4.2 using getWizPnP.exe 0.5.3debug2.

The first time I tried to download a test recording (one of the test recordings I had listed in my previous post) YARDWiz hung after I paused & resumed the download. When I initiated the resume download after the pause, YARDWiz’s progress indicator didn’t update but Windows Explorer showed the data files being updated (although Windows Explorer was very slow to respond to any selection). Some minutes after the download had completed (as shown by Windows Explorer) I suspected YARDWiz had hung but I found I could highlight other recordings in the recordings list. YARDWiz was shut down by clicking on the top right hand corner ‘Close’ X, but Windows Explorer was still very slow to respond (Process Explorer showed pskill.exe taking up 98% of the CPU usage). When I tried to log off from Windows, a dialog box indicated YARDWiz was still running – the close option was selected & YARDWiz closed.

The next time I found YARDWiz didn’t pause the download when I selected pause - Windows Explorer showed the data files still updating. After waiting for approx one minute I selected resume download & YARDWiz’s paused progress indicator jumped to the right to the approximate current downloaded position. The progress indicator continued updating & YARDWiz indicated a download. The download was successful.

So far these have been the only two hiccups, all other pause/resume downloads have been successful.

prl · Post by **prl** » Thu May 17, 2012 09:46

I'm not sure why pskill took over processor use in your first case. The user code in getWizPnP (i.e. not standard or CPAN/ppm libraries) doesn't try to intercept signals. I'm not sure what Windows mechanism Perl uses as the equivalent of Unix signals, but I guess that's what pskill is trying to use to shut down getWizPnP.

It appears that both of these problems lie in the mechanism that YARDWiz uses to stop getWizPnP when it pauses a recording. That doesn't rule out the problem being in getWizPnP, but if the problem is there, I'm not sure what it is.

Good to know that when the recording downloads are resumed, they do it correctly.

Luke · Post by **Luke** » Thu May 17, 2012 09:47

I'll look into it.

sub3R wrote:(Process Explorer showed pskill.exe taking up 98% of the CPU usage).

Are you running Windows XP Home edition? Pskill should no longer be required since YARDWiz 0.4.2. I rather cryptically mentioned this in the release notes (* Include psutil in py2exe build. Resolves Issue 3).

prl · Post by **prl** » Thu May 17, 2012 10:13

If the problems with pausing recording downloads in YARDWiz are resolved (or at least shown to not be the fault of getWizPnP), I'll move on to a new beta of 0.5.4. Proposed improvements are:

--before, --after and --between to limit downloads by recording times;
--retry to retry downloads automatically after some causes of failure (especially 400 Bad Request);
Allow user control of the format of the date string used for matching recordings; and
In the progress bar on --resume, show progress for the whole recording, not just the progress over the part being resumed

Luke · Post by **Luke** » Thu May 17, 2012 11:47

prl wrote:I'm not sure why pskill took over processor use in your first case. The user code in getWizPnP (i.e. not standard or CPAN/ppm libraries) doesn't try to intercept signals. I'm not sure what Windows mechanism Perl uses as the equivalent of Unix signals, but I guess that's what pskill is trying to use to shut down getWizPnP.

It appears that both of these problems lie in the mechanism that YARDWiz uses to stop getWizPnP when it pauses a recording. That doesn't rule out the problem being in getWizPnP, but if the problem is there, I'm not sure what it is.

Good to know that when the recording downloads are resumed, they do it correctly.

YARDWIz tries to send SIGINT as a first resort. This works works fine on unix-like OS's and Windows when running as a console application. The problem with pp exes (like getWizPnP) on Windows is they spawn a child process which (when running with no console) doesn't respond to signals even when the parent process is created using the Windows flag "CREATE_NEW_PROCESS_GROUP". It's a bit of a pain. I don't know exactly how PSKill works as it's closed source, though I'm pretty sure it uses fairly low level Windows API functions. Essentially the same as what happens when you "End Process Tree" from Windows Task Manager.

sub3R · Post by **sub3R** » Thu May 17, 2012 13:03

Luke wrote:Are you running Windows XP Home edition? Pskill should no longer be required since YARDWiz 0.4.2. ...

Yes Luke, I’m running Windows XP Home Edition with sp3. I always put pskill.exe in the ‘c:\program files\YARDWiz’ by habit after some shutdown problems with earlier versions.

A bit more info that may be helpful - I got the following results with the first download I tried today:

After deleting pskill.exe from the ‘c:\program files\YARDWiz’ directory I tried downloading a test recording ‘test-3 no edit’ in .tvwiz format & after a short period initiated pause (6 bars were showing on YARDWiz’s progress indicator). Windows Explorer showed the download didn’t pause & continued a successful complete download.
Part of YARDWiz’s bottom log showed:
Downloading test-3 no edit...
##########
Your version of Windows does not include the "taskkill" command, you will need to end all GetWizPnP.exe processes manually using the Windows Task Manager (Ctrl-Alt-Delete).

If you wish to make use of the stop and pause functionality, download PsTools.zip from http://technet.microsoft.com/en-us/sysi ... s/bb896683 and copy PsKill.exe to the YARDWiz directory
##########
Download paused.

I then selected resume download in YARDWiz & the timeline indicator jumped fully to the RHS, the download complete chime sounded, & the following two lines were added to YARDWiz’s bottom log.
Downloading test-3 no edit...
Download of E:\test-5\test-3 no edit 2012-05-14.tvwiz complete.
I could shut down YARDWiz normally.

I got the same result when I tried to download & pause the same recording in .ts format. This is the first time I have tried downloading to .ts format with this YARDWiz/getWizPnP combination.
Details of test recording ‘test-3 no edit’: 321.4MB, 5min duration, timer recorded from 7mate, not edited.

prl wrote:I'm not sure why pskill took over processor use in your first case. ...

It seems that YARDWiz appeared to have shut down but it hadn’t – it was eventually shut down when I tried to log out from the current user. Prior to this, pskill.exe appeared to be trying to shut down YARDWiz for some minutes but it seems it couldn’t, even though the YARDWiz window had closed.
The other part I can’t explain is the very slow response from Windows Explorer when I paused the download – this wasn’t normal.

Luke · Post by **Luke** » Thu May 17, 2012 13:20

Drat, the psutil package doesn't work on XP Home. Time to upgrade Dennis? Win 7 sucks a lot less than XP and Vista.

Sorry, nothing I can do about PSKill.

sub3R · Post by **sub3R** » Thu May 17, 2012 14:20

Win7 is definitely on the list when I build the next PC. Pausing isn’t an issue for me at all – I have only used it for testing.

Ignoring the tests in my last post, it’s funny this is the first time I have come across the intermittent issues with YARDWiz not pausing (with pskill.exe in YARDWiz directory) – YARDWiz 0.4.2 with getWizPnP 0.5.3 (pre debug2) always paused but of course the getWizPnP resume problem was there.

sub3R · Post by **sub3R** » Thu May 17, 2012 20:32

sub3R wrote:The other part I can’t explain is the very slow response from Windows Explorer when I paused the download – this wasn’t normal.

This may have been caused by a process called ‘CaptureLibService.exe’ using approx 42% of the CPU usage when getWizPnP.exe downloads via the command prompt or via YARDWiz (getWizPnP.exe uses a similar percentage).
Process Explorer shows CaptureLibService.exe drop to 0% when the download is paused or completed but if still downloading it stays around the 42% mark & has been seen to go as high as 52%. The slow response from Windows Explorer was when the download hadn’t paused after a pause was initiated from YARDWiz.

CaptureLibService.exe is in ‘..\Freemake\CaptureLib’, ‘Freemake’ being a top directory of ‘Freemake Video Converter’ which I sometimes use for extracting MP3s from downloaded YouTube music video clips. It appears that this service runs whenever a wiz recording download is occurring, & even when downloading from the internet.
Suspending CaptureLibService.exe in Process Explorer improves the response of Windows Explorer during a getWizPnP download.
Some info about this Microsoft file here: http://systemexplorer.net/filereviews.php?fid=3051703

Luke · Post by **Luke** » Thu May 17, 2012 21:42

prl wrote:A new debug version of getWizPnP, 0.5.3debug2 is available. It includes the debugging code added for the 400 Bad Request problem, and fixes for --resume.

It should be drop-in compatible in YARDWiz as a replacement for getWizPnP 0.5.3.

--resume is working again for me. Tested on Win XP/7 Pro.

sub3R · Post by **sub3R** » Fri May 18, 2012 10:13

Ignoring the previous pause hiccups, I can’t fault --resume with YARDWiz 0.4.2 & getWizPnP.exe 0.5.3debug2 on WinXP Home sp3 (Ethernet LAN to DP-S1 running 01.05.350 f/w).
Tested on YARDWiz using ‘pause’ & also by unplugging then reconnecting Ethernet LAN to S1.
Tested via command prompt by stopping with <Ctrl C> to give ‘Terminating on signal SIGINT (2)’ then re-running the same command again, & also by unplugging then reconnecting Ethernet LAN to S1.

prl · Post by **prl** » Fri May 18, 2012 10:21

One thing I noticed when I was testing --resume in getWizPnP on Windows 7 using the Control-C method was that occasionally I'd get what appeared to be an internal Perl error before exiting. "Out of memory" on a couple of occasions, and something else (can't recall what) on one other occasion. I did a lot of these Control-C terminations. The Perl internal error happened pretty infrequently.

Not sure if that's relevant to the pskill problems, but it could be that Perl is catching some signals internally even when the %SIG signal control hash is left in its default state.

prl · Post by **prl** » Fri May 18, 2012 12:02

A caution about signal handling in Perl on Windows from the Fine Perl Manual:

Signal handling may not behave as on Unix platforms (where it doesn't exactly "behave", either . For instance, calling die() or exit() from signal handlers will cause an exception, since most implementations of signal() on Windows are severely crippled. Thus, signals may work only for simple things like setting a flag variable in the handler. Using signals under this port should currently be considered unsupported.

[my emphasis]

Not sure if that is relevant to the pskill problem.

sub3R · Post by **sub3R** » Fri May 18, 2012 14:45

Either of those could have something to do with the pskill.exe problem, but Luke would know more about that. Nothing would surprise me with Windows.
I also noticed the comment about Norton AntiVirus under the Perl ‘Bugs & Caveats’ you linked to.

I’ll hammer getWizPnP.exe download with <Ctrl C>/re-run & see if I get any error messages, assuming the message appears in the command prompt window or in a Windows pop-up.

prl · Post by **prl** » Fri May 18, 2012 17:31

sub3R wrote:...
I’ll hammer getWizPnP.exe download with <Ctrl C>/re-run & see if I get any error messages, assuming the message appears in the command prompt window or in a Windows pop-up.

If you're running getWizPnP from a command window, the error message appears in the same command window.

sub3R · Post by **sub3R** » Sat May 19, 2012 21:52

So far, after quite a lot of downloads, I haven’t seen any unusual error messages running getWizPnP.exe downloads from the command prompt with resume initiated by <Ctrl C> then a re-run.
I’ve been using both .tvwiz & .ts download formats with a ‘keep A-B only’ edited recording & using the same getWizPnP commands Luke uses in YARDWiz.

At times I’ve been stopping one of these downloads when partially downloaded, then partially downloading the same recording in a different format, & then returning to resume the download in the previous format (using <Ctrl C> then re-run a number of times in both downloads).
Also, partially downloading in the same format to two different locations, going back & forth between the two (changing the target in the command) & alternating stopping and resuming a number of times on each one.
Also, completing a download, trying to download the same again (expected error message comes up), & then adding --force to the command to delete the previous download & start the download again (using <Ctrl C> then re-run in both downloads).

I can’t fault any of these operations - they all work quite well.
If I do get any unusual error message I’ll post the details.

prl · Post by **prl** » Sat May 19, 2012 23:39

Thanks.

raymondjpg · Post by **raymondjpg** » Wed Jul 25, 2012 14:02

The issue I had with premature termination of file transfers under Win 7 appears to have been resolved. Recent transfers using Yardwiz 0.4.2 have completed without any errors in the log. I haven't done enough transfers yet to be completely sure.

Changed since I last used Yardwiz:

1. A number of Microsoft updates, I don't follow the details of what is addressed with each update.
2. Installation of the updated MSE client.
3. Update of Outpost Security Suite Free v7.1.1 to Outpost Firewall Pro v7.5.3. This became necessary for Java 7 support.

I suspect the main culprit was Outpost Free. Even when disabled there was always something about it lurking in the background.

I don't completely discount MS or MSE updates, particularly if others who had similar issues with premature termination of transfers under Win 7 may not have had Outpost Free installed.

prl · Post by **prl** » Wed Jul 25, 2012 14:33

Thanks for the feedback. If it was Outpost Free, that'd explain why I never saw early terminations, because I just use the Microsoft security products that are bundled with Win7.

raymondjpg · Post by **raymondjpg** » Wed Jul 25, 2012 15:01

prl wrote:If it was Outpost Free, that'd explain why I never saw early terminations...

Or Outpost Free in combination with MSE? How many issues can be tracked back to an interaction between a third party firewall and antivirus product from different sources?

I would be interested to know how people also experiencing file transfer issues with Yardwiz under Win 7, and did not have Outpost Free installed, are faring.

netmask · Post by **netmask** » Wed Jul 25, 2012 17:43

I have no problems with Yardwiz - I have Windows 7 Ultimate 32bit, AVG free and Windows Firewall. So far no virus or malware problems. I use CCleaner nightly as I switch or log off.

netmask · Post by **netmask** » Sat Jan 12, 2013 12:30

A friend has emailed me with a problem he is experiencing using YardWiz.
A variety of errors basically

Unable to contact the WizPnP server
and in the WinServer drop down menu in Yardwiz he has the following entry's
(from memory the last one is the correct one for his setup)
beyonwiz
http://192.168.1.5/tvdevicedesc.xml
192.168.1.5
192.168.1.3:49152

I have asked the obvious question via email "Is the Beyonwiz powered up?"

Awaiting a reply

EDIT: Fired up WizFX and it showed address as 192.168.1.4:49152 so somehow it has changed from .3 to .4

All is working now.

prl · Post by **prl** » Sat Jan 12, 2013 15:30

netmask wrote:...
EDIT: Fired up WizFX and it showed address as 192.168.1.4:49152 so somehow it has changed from .3 to .4
...

Possibly the Beyonwiz got assigned a new DHCP address and the ones that YARDWiz was caching didn't match. The fact that there are .3 and .5 addresses lying around in the list adds some evidence to the possibility.

I don't know how the http://192.168.1.5/tvdevicedesc.xml URL got in the YARDWiz devices list. It's a value returned by the SSDP response to the SSDP broadcast query and isn't used by getWizPnP. If YARDWiz is picking it up from the output of getWizPnP, I don't know how or why.

Yet another good reason for having fixed Ethernet address->IP address mappings in the DHCP server.

netmask · Post by **netmask** » Sat Jan 12, 2013 15:33

Thanks - my friend is an inveterate deleter of files etc and other no no's. I will be visiting next week

prl · Post by **prl** » Sat Jan 12, 2013 18:18

netmask wrote:Thanks - my friend is an inveterate deleter of files etc and other no no's. I will be visiting next week

For once, perhaps, this may well be the result of leaving things in their default settings

Luke · Post by **Luke** » Sun Jan 13, 2013 21:08

The YARDWiz WizPnP server list only lists either what is typed in or what getWizPnP returns, so I can only think that tvdevicedesc.xml got in the list because someone typed/pasted it in.

As is documented in the help, clearing the server list and pressing the 'connect' button makes YARDWiz search (via getWizPnP) for WizPnP servers.

I might add an option to disable address caching in the preferences.

prl · Post by **prl** » Mon Jan 14, 2013 07:28

Luke wrote:The YARDWiz WizPnP server list only lists either what is typed in or what getWizPnP returns, so I can only think that tvdevicedesc.xml got in the list because someone typed/pasted it in.
...
I might add an option to disable address caching in the preferences.

It seems unlikely that someone would be aware of that URL unless they knew a lot more than most people do about WizPnP and SSDP.

Adding an option to avoid caching of IP addresses sounds like a good idea. My inclination would be to make non-caching the default. Early on in the development of getWizPnP, I experimented with client address caching, but I abandoned it when I made lookup faster instead.

I have a new beta of getWizPnP and I hope to put it up on another file access site sometime in the next few days. I still can't access the old ozi4ums.org site where alwayslooking gave me space. Fortunately I have my own archive of old versions.

prl · Post by **prl** » Mon Jan 14, 2013 11:49

Sigh. Why is this always such a pain?

I got myself a Ubuntu One account and downloaded the client, which crashes every time I try to run it. From the crash log, it looks like a reference through a null pointer.

Anyone seen this, or seen any useful reports about it?

I'm running OS X Mountain Lion 10.8.2. I've sent a report in to Ubuntu helpdesk, but it's still Sunday where they live.

Luke · Post by **Luke** » Mon Jan 14, 2013 21:59

You can upload files from the UbuntuOne web page.

prl · Post by **prl** » Tue Jan 15, 2013 07:34

Luke wrote:You can upload files from the UbuntuOne web page.

Thanks. I discovered that by accident after I posted.

Next, to find out how to export files so that they download with sensible names.

prl · Post by **prl** » Tue Jan 15, 2013 10:16

Luke wrote:You can upload files from the UbuntuOne web page.

Version 0.5.4 beta1 limited release now available, with files hosted on Ubuntu One.

Luke · Post by **Luke** » Wed Jan 16, 2013 12:02

prl wrote:Version 0.5.4 beta1 limited release now available, with files hosted on Ubuntu One.

Seems to work fine with YARDWiz. Only limited testing though, mainly just downloading and pausing/resuming.

If anybody else wants to test getWizPnP version 0.5.4 beta1 with YARDWiz, you can simply replace the existing getWizPnP.exe in the YARDWiz install folder with the beta version from the above link.

prl · Post by **prl** » Wed Jan 16, 2013 12:15

prl wrote:...I got myself a Ubuntu One account and downloaded the client, which crashes every time I try to run it. From the crash log, it looks like a reference through a null pointer.
...

Seems to have been caused by my home directory path having a space in one of its elements. Who's been naughty and not checked an error return value in Ubuntu One, then? Worked around for now.

I've uploaded all my Beyonwiz software releases to U1, and I'll gradually start fixing the links in OpenWiz, newest first.

DavidR · Post by **DavidR** » Sat Jan 26, 2013 11:23

I've just got YardWiz installed on a Mac running Mountain Lion but I don't get the option to play in VLC. Is this a bug / known issue?

Yet Another Recording Downloader for the Wiz

About the Forum

Join us