getWizPnP - Beyonwiz recording downloader

[prl]

I've been wondering about the progress bar in getWizPnP when --resume is used. At the moment, if you resume after downloading half a recording, it treats the progress as though it's a new download half the size of the recording (resume showing 0% and shows the data to be copied as half the recording size).

Would it make more sense if when a recording was resumed, the progress bar started looking as it was when the original download was interrupted (in the example above, resume showing 50%, the data to be copied as the whole recording size and the data already copied as half the recording size)?

This is an easy change to make. Would it break anything in YARDWiz?

[Luke]

Would it break anything in YARDWiz?

No, YARDWiz has it's own progress function - it simply checks filesize on disk against total filesize reported by getWizPnP.

[Luke]

--resume does not work properly in 0.5.3. Work is under way to fix this.

Apologies for the bump, but any progress?

[prl]

Version 0.5.4 beta1 limited release

This release is being made using Ubuntu One to host the files. It's my first use of Ubuntu One, so please let me know, in this topic or by PM, if you have problems doing the downloads.
16/1/13 Changed the download links to point to the files' permanent homes in U1. Unpublished the old links.

Version 0.5.4 has been released. The 0.5.4 beta versions are no longer available.

A new limited release beta version of getWizPnP is available. Only the canned versions are available:

• Windows
• Cygwin
• OS X
• Linux

Changes from the last full release (0.5.3) are:

• Fixed bug which caused a Perl internal error message instead of the intended getWizPnP error message if an error occurred in a recording copy or move.
• Fixed several bugs that contributed to getWizPnP --resume not resuming recording correctly.
• The test to avoid seeking on stdout if it was a pipe or socket was incorrect. It failed if the output file was a newly-created file (-s used instead of -S). Fixed.
• Added options --before and --since 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. This changes the default format of the match date.
• In the progress bar on --resume, show progress for the whole recording, not just the progress over the part being resumed.
• Added undocumented --delay option. Adds delays between HTTP requests, which some users thought might help with download failures. --delay=s.ss (e.g --delay=0.5 for 0.5 secs between reqests)

Known bugs in 0.4.5 beta1:

• On Windows 7, sometimes getWizPnP fails to discover Beyonwiz servers on the network. The reason is not clear, but it can sometimes be worked around by specifying a larger timeout. Try --wizpnpTimeout=2.
• getWizPnp sometimes fail part-way through a recording copy with a HTTP 400 - Bad Request error. WizFX also seems to have similar problems on Windows 7. The cause of the problem is not clear, but it may be something common to both getWizPnP and WizFX.
• The changes to the file indexing from 01.05.283 mean that if you delete a recording on the Beyonwiz (--delete/--move), it will remain in the internal index (i.e. visible in the file player, and visible in WizFX) until you start a recording index rebuild using FILEPLAYER, SOUNDTRACK on the remote, or a HDD check is done. This can only be fixed in the Beyonwiz firmware.
• In free-to-air EPGs, the information used by getWizPnP for the episode name is sometimes actually the program synopsis.
• Only Australian time zones are available for use by --before and --since.

[prl]

Version 0.5.4 beta2 limited release

Version 0.5.4 has been released. The 0.5.4 beta versions are no longer available.

A new limited release beta version of getWizPnP is available. Only the canned versions are available:

• Windows
• Cygwin
• OS X
• Linux

Changes from the last full release (0.5.3) are:

• Allow the use of GETWIZPNPCONF environment to specify the getWizPnP configuration file rather than use the programmed default. If GETWIZPNPCONF is set to an empty string, then no configuration file is loaded at startup. Intended to allow the use os alternative configuration files, especially for programs like YARDWiz and WizZillathat provide GUI interfaces to getWizPnP.
• Fixed bug which caused a Perl internal error message instead of the intended getWizPnP error message if an error occurred in a recording copy or move.
• Fixed several bugs that contributed to getWizPnP --resume not resuming recording correctly.
• The test to avoid seeking on stdout if it was a pipe or socket was incorrect. It failed if the output file was a newly-created file (-s used instead of -S). Fixed.
• Added options --before and --since 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. This changes the default format of the match date.
• In the progress bar on --resume, show progress for the whole recording, not just the progress over the part being resumed.
• Documentation of new features in getWizPnP documentation.
• Some tidying-up of getWizPnP documentation.
• Added undocumented --delay option. Adds delays between HTTP requests, which some users thought might help with download failures. --delay=s.ss (e.g --delay=0.5 for 0.5 secs between reqests)

Known bugs in 0.4.5 beta2:

• On Windows 7, sometimes getWizPnP fails to discover Beyonwiz servers on the network. The reason is not clear, but it can sometimes be worked around by specifying a larger timeout. Try --wizpnpTimeout=2.
• getWizPnp sometimes fail part-way through a recording copy with a HTTP 400 - Bad Request error. WizFX also seems to have similar problems on Windows 7. The cause of the problem is not clear, but it may be something common to both getWizPnP and WizFX.
• The changes to the file indexing from 01.05.283 mean that if you delete a recording on the Beyonwiz (--delete/--move), it will remain in the internal index (i.e. visible in the file player, and visible in WizFX) until you start a recording index rebuild using FILEPLAYER, SOUNDTRACK on the remote, or a HDD check is done. This can only be fixed in the Beyonwiz firmware.
• In free-to-air EPGs, the information used by getWizPnP for the episode name is sometimes actually the program synopsis.
• Only Australian time zones are available for use by --before and --since.

[Luke]

I played with getWizPnP 0.5.4 beta1 in YARDWiz over the w/end and had no issues in Windows, OSX or Linux (I extracted the source from a canned version to run it on Linux). I'll try out beta2 and the GETWIZPNPCONF addition shortly.

[prl]

Thanks, Luke.

[Luke]

The canned OSX version crashes when executed, the error message is "Illegal instruction".

[prl]

The canned OSX version crashes when executed, the error message is "Illegal instruction".

Even with the minimum amount of code executing, say, "getWizPnP --version" or "--help"?

I downloaded the ZIP file from Ubuntu, unpacked it, deleted the par cache, and I can't reproduce it.

The binaries for getWizPnP and perl don't seem to have anything unexpected in their executable type

Code: Select all

Cambyses:getWizPnP prl$ file ./getWizPnP
./getWizPnP: Mach-O universal binary with 2 architectures
./getWizPnP (for architecture i386):    Mach-O executable i386
./getWizPnP (for architecture x86_64):  Mach-O 64-bit executable x86_64
Cambyses:getWizPnP prl$ which perl
/usr/bin/perl
Cambyses:getWizPnP prl$ file /usr/bin/perl
/usr/bin/perl: Mach-O universal binary with 2 architectures
/usr/bin/perl (for architecture i386):  Mach-O executable i386
/usr/bin/perl (for architecture x86_64):        Mach-O 64-bit executable x86_64
Cambyses:getWizPnP prl$

I still need to do the same for all the shared libraries in the ZIP, though I'd have expected a different kind of error message if there was an incompatible architecture stuck in there somewhere.

[Luke]

I redownloaded in case of a corrupted download, removed the par cache and called getWizPnP --version and got the same error. The getWizPnP executable doesn't get unpacked to $TMPDIR either.

Code: Select all

bnls-Mac:~ bnl$ ls $TMPDIR
par-bnl
bnls-Mac:~ bnl$ rm -r $TMPDIR/par-bnl
bnls-Mac:~ bnl$ ./getWizPnP --version
Illegal instruction
bnls-Mac:~ bnl$ ls $TMPDIR
bnls-Mac:~ bnl$ ls -l getWizPnP
-rwxr-xr-x  1 bnl  staff  15361679  5 Feb 13:06 getWizPnP
bnls-Mac:~ bnl$ file ./getWizPnP
./getWizPnP: Mach-O universal binary with 2 architectures
./getWizPnP (for architecture i386):    Mach-O executable i386
./getWizPnP (for architecture x86_64):  Mach-O 64-bit executable x86_64

[prl]

I redownloaded in case of a corrupted download, removed the par cache and called getWizPnP --version and got the same error. The getWizPnP executable doesn't get unpacked to $TMPDIR either.

OK, so it seems to be dying well before any user code gets executed.

What md5 checksum do you get on the getWizPnP binary in the ZIP file?

I get:

Code: Select all

Cambyses:getWizPnP prl$ md5 getWizPnP
MD5 (getWizPnP) = ff5970cb4a81f75745be77d4119bca12
Cambyses:getWizPnP prl$ 

[Luke]

Code: Select all

bnls-Mac:~ bnl$ md5 getWizPnP
MD5 (getWizPnP) = ff5970cb4a81f75745be77d4119bca12

[prl]

Looks like it's something in the environment, then. But is it because of the processor, 10.6 or because of the VM?

[Luke]

Have you made any changes to your environment since you pp'd the previous beta?

[prl]

Have you made any changes to your environment since you pp'd the previous beta?

Update 10.7 to 10.8 and update of XCode.

[Luke]

I don't know if it would make any difference to pp'd executables but a bit of googling suggests that the OS X 10.6 SDK was dropped as of Xcode 4.4. Apparently an unsupported workaround is to copy the 10.6 SDK from Xcode <= 4.3.

I've built an OS X 10.8 VM and confirmed that the canned getWizPnP 0.5.4beta2 runs correctly.

If you want to drop support for 10.6 that would not cause me to lose any sleep. I'm going to package the next YARDWiz release on 10.8 and tend* to be of the opinion that supporting current OS version and immediate predecessor is all that is required so will drop 10.6 support anyway.

* With the exception of Windows XP as that's now the only Windows I have access to since I replaced Win 7 with Ubuntu on my PC.

[prl]

I don't know if it would make any difference to pp'd executables but a bit of googling suggests that the OS X 10.6 SDK was dropped as of Xcode 4.4. Apparently an unsupported workaround is to copy the 10.6 SDK from Xcode <= 4.3.

I've built an OS X 10.8 VM and confirmed that the canned getWizPnP 0.5.4beta2 runs correctly.

Thanks for confirming that the canned getWizPnP 0.5.4beta2 works on 10.8, and apologies for the fact that it was broken on 10.6.

I hadn't thought about 10.6 support being dropped in XCode for 10.8, but IIRC, that's Apple policy - that they only support the current and immediate previous major release.

Strange, though, that the symptom would be SIGILL (Illegal Instruction) in a pp executable, though.

Soapbox time - should I try to make getWizPnP 10.6 compatible?

[Luke]

I'm too slow editing... see edit in previous post

[prl]

I'm too slow editing... see edit in previous post

Thanks, Luke. Seen it.

However

... tend* to be of the opinion that supporting current OS version and immediate predecessor is all that is required so will drop 10.6 support anyway.

* With the exception of Windows XP as that's now the only Windows I have access to since I replaced Win 7 with Ubuntu on my PC.

I hope that the latter doesn't cause any problems. I only have Win 7 on my Mac* and I've been contemplating to upgrading to 8. However, I could probably stay with the same Perl version if I did that.

* Triple boots OS X, Windows & Ubuntu.

[Luke]

I've rolled my own getWizPnP canned versions with perl 5.8 - 5.14 and they ran fine in XP. I wouldn't worry about that. And I can always pull my finger out and get Microsoft to unlock my legitimate retail Win 7 Pro license code that refuses to activate...

Edit: 5.10-5.14 as I remember not being able to get it to compile with perl 5.8. I only bothered trying as that was the perl version that was used to compile getWizPnP 0.4.3a for Wizilla and this was when I was trying to figure out what was causing the antivirus false positives ages ago.

[prl]

Speaking of OS versions, my Ubuntu installation (currently 11.10) is offering to update me to 12.04.01 LTS. I don't know whether that involves a Perl upgrade.

Is their any reason anyone can think of from the point of view of getWizPnP/YARDWiz for me not to upgrade?

I don't intend to do either this upgrade or upgrade from Win7 to Win 8 until the current getWizPnP beta has gone into public release.

[Luke]

12.04 comes with perl 5.14.2 (https://launchpad.net/ubuntu/+source/perl). I don't see why that would be an issue. However, ubuntu upgrades are not always smooth sailing... I've only had 1 upgrade 'just work' since 2009. The last upgrade from 12.04-12.10 I had to reinstall the bootloader from a livecd as the pc wouldn't boot after upgrading...

[prl]

... I've only had 1 upgrade 'just work' since 2009. The last upgrade from 12.04-12.10 I had to reinstall the bootloader from a livecd as the pc wouldn't boot after upgrading...

Sounds unpleasant. Fortunately, I'm in no rush to do this.

[Luke]

Did you post a new beta release before the database restore which has since gone missing? Or am I imagining things (not out of the question at the moment)?

[prl]

Did you post a new beta release before the database restore which has since gone missing? Or am I imagining things (not out of the question at the moment)?

Well, I posted the links and a short release note. New copy to follow shortly.

It's annoying at times like these that, unlike the old distribution source, I can't give meaningful names to the UbuntuOne file export URLs so knowledgeable users can no longer just look in the distribution folder for getWizPnP and get whatever versions are there.

"[T]here shall be wailing and gnashing of teeth"...

[prl]

Version 0.5.4 beta3 limited release

Version 0.5.4 has been released. The 0.5.4 beta versions are no longer available.

A new limited release beta version of getWizPnP is available. Only the canned versions are available:

• Windows
• Cygwin
• OS X
• Linux

Changes from the last full release (0.5.3) are:

• Allow the use of GETWIZPNPCONF environment to specify the getWizPnP configuration file rather than use the programmed default. If GETWIZPNPCONF is set to an empty string, then no configuration file is loaded at startup. Intended to allow the use os alternative configuration files, especially for programs like YARDWiz and WizZillathat provide GUI interfaces to getWizPnP.
• Fixed bug which caused a Perl internal error message instead of the intended getWizPnP error message if an error occurred in a recording copy or move.
• Fixed several bugs that contributed to getWizPnP --resume not resuming recording correctly.
• The test to avoid seeking on stdout if it was a pipe or socket was incorrect. It failed if the output file was a newly-created file (-s used instead of -S). Fixed.
• Added options --before and --since to limit downloads by recording times.
• Fixed lack of error reporting when syswrite() fails during a HTTP GET request.
• Change all the HTTP_BAD_REQUEST error returns generated in getWizPnP to HTTP_FORBIDDEN to avoid triggering --retry re-fetches when the error didn't come from the Beyonwiz.
• --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.**This changes the default format of the match date.**
• In the progress bar on --resume, show progress for the whole recording, not just the progress over the part being resumed.
• Documentation of new features in getWizPnP documentation.
• Some tidying-up of getWizPnP documentation.
• Added undocumented --delay option.

Changes from 0.5.4 beta2 are:

• Fixed bug which caused a Perl internal error message instead of the intended getWizPnP error message if an error occurred in a recording copy or move.
• Change all the HTTP_BAD_REQUEST error returns generated in getWizPnP to HTTP_FORBIDDEN to avoid triggering --retry re-fetches when the error didn't come from the Beyonwiz.

Known bugs in 0.5.4 beta3:

• On Windows 7, sometimes getWizPnP fails to discover Beyonwiz servers on the network. The reason is not clear, but it can sometimes be worked around by specifying a larger timeout. Try --wizpnpTimeout=2.
• getWizPnp sometimes fails part-way through a recording copy with a HTTP 400 - Bad Request error. WizFX also seems to have similar problems on Windows 7. The cause of the problem is not clear, but it may be something common to both getWizPnP and WizFX.
• The changes to the file indexing from 01.05.283 mean that if you delete a recording on the Beyonwiz (--delete/--move), it will remain in the internal index (i.e. visible in the file player, and visible in WizFX) until you start a recording index rebuild using FILEPLAYER, SOUNDTRACK on the remote, or a HDD check is done. This can only be fixed in the Beyonwiz firmware.
• In free-to-air EPGs, the information used by getWizPnP for the episode name is sometimes actually the program synopsis. This is in the broadcast data and so is not strictly a getWizPnP bug.
• Only Australian time zones are available for use by --before and --since.

[Luke]

Looks good from some minimal testing on XP and Ubuntu. The GETWIZPNPCONF env var fix works well when --episode is set in .getwizpnp/getwizpnp.conf (I noticed that getwizpnp.conf is included in the canned linux zipfile instead of .getwizpnp, was that intentional?). The --delay option showed up a small bug in YARDWiz on XP which I think I've fixed, will do more testing next week (away this w/end).

I think I'll add options into the YARDWiz preferences to set some getWizPnP arguments to try and workaround the Win 7 issues (--delay,--wizpnpTimeout), in my working copy they're currently just hardcoded, then I can release another YARDWiz version.

[prl]

... I noticed that getwizpnp.conf is included in the canned linux zipfile instead of .getwizpnp, was that intentional? ....

Yes, that's intentional. If it were named .getwizpnp, it would be invisible to 'ls' (without -a, -A or -f) in Unix-like CLIs and invisible in the Finder on OS X. It's the same in all the canned zipfiles, in both the Windows one and in the Unix-like ones (Linux, OS X, Cygwin).

It still needs to be installed as ~/.getwizpnp in Unix-like systems (for its default location).

This is covered in the FILES section of the getWizPnP documentation.

[prl]

...
I think I'll add options into the YARDWiz preferences to set some getWizPnP arguments to try and workaround the Win 7 issues (--delay,--wizpnpTimeout), in my working copy they're currently just hardcoded, then I can release another YARDWiz version.

When that's been tested, I'll roll out a release version provided no further problems show up. If you're going to expose an interface to --delay in YARDWiz, I guess I'd better document what it does in getWizPnP

[prl]

tl;dr: The most recent version (for Perl 5.16) of the PAR-Packager Perl package that I use to make pre-packaged Windows distributions is now only supported on 64-bit versions of Windows. I still have Perl 5.12 that I can continue to use to make getWizPnP distributions, but sometime in the future, that may become untenable.

How much of a problem would it be if (sometime in the future) I distributed only a 64-bit prepackaged Windows getWizPnP? I assume that it would not run on 32-bit machines.

How much of a problem is that likely to be for getWizPnP users, including people who use it indirectly through YARDWiz? I assume that the longer I hold off the switch from (32-bit) Perl 5.12 to (64-bit) 5.16, the fewer people there will be for whom this would cause difficulties.


The full catastrophe:

Over the weekend, the USB drivers on my Windows/Boot Camp Mac stopped working on me. This was possibly due to a problem with Boot Camp 4.0, which is supposed to be for Win7, which I run.

The only hint I got about how to fix it was to remove the Intel USB3 driver to get USB working again. Unfortunately, all the user interface devices on my MacBook Pro (built-in keyboard, built-in trackpad, external keyboard & mouse, and even Bluetooth) all run off USB. I was able to boot off my Windows distribution DVD, but none of the options to repair the OS or restore to a previous update checkpoint worked. I wouldn't be surprised if it were possible to remove the driver from the HDD using the install DVD, but it's a level of Windows knowledge that's way beyond me.

So, I saved all my installers and the installed Perl folder (the latter turned out to be quite fortuitous), and reinstalled Win7. I then reinstalled Boot Camp 4.0, and started the process of doing the WIndows Updates. Part-way through, I lost USB again.

So, back to reinstalling Win7. A day and a half later, I'd caught up with all the Windows updates (for a good bit of the time I was downloading at < 10kb/s - something in the path was a bit overloaded), reinstalled Boot Camp and got things running again (I'm typing this from inside Win IE9).

Then I started re-installing all the bits I need to build pre-packaged getWizPnP on both native Windows and Cygwin. I decided I'd try to start from clean installs so that I'd have installs that contained only the bits I really needed to build getWizPnP.

I reinstalled my old Perl 5.12 from the distribution, and then reinstalled all the modules getWizPnP depends on without any problems. But when I came to install PAR-Packager, the package manager told me that the download was unauthorised. A but of Web searching revealed that 5.12 is now only fully supported for Paying ActivePerl users (which I am not).

I then decided I'd try the next available ActivePerl version, 5.14, but it didn't have PAR-Packer available at all.

The version matrix in the PAR-Packer link shows that PAR-Packer is available for Perl 5.16, but only in a 64-bit version (for use with 64-bit Perl).

I retrieved the Perl 5.12 installed folder from my backups, which already contains all the required extra modules to build getWizPnP. I can use this Perl to continue to make getWizPnP distributions, but sometime in the future, that may become untenable, for example, if I need to use a module that I don't have in that copy of Perl, and I can't download it from the repository..

How much of a problem would it be if (sometime in the future) I distributed only a 64-bit prepackaged Windows getWizPnP? I assume that it would not run on 32-bit machines.

How much of a problem is that likely to be for getWizPnP users, including people who use it indirectly through YARDWiz? I assume that the longer I hold off the switch from (32-bit) Perl 5.12 to (64-bit) 5.16, the fewer people there will be for whom this would cause difficulties.

[IanSav]

Hi Peter,

I still use 32bit Windows XP. I intend to keep running this platform for as long as I can.

I have no intention of going to Windows 8 as I don't have a touch screen and the whole UI is biased towards touch (and the UI is VERY ugly). Windows 7 was always way too expensive and has now been withdrawn from sale.

Regards,
Ian.

[Gully]

Windows 7 was always way too expensive and has now been withdrawn from sale.

Hi Ian

Not to challenge your decision but just to correct you as there are still plenty of shops selling Windows 7 and at a cost around $100-150 for an OEM edition.

Peter, I'm using 64bit Windows 7 so no problem here.

[prl]

I had no option but to get Win7, since by then XP was no longer for sale. At the moment I have no option to upgrade to Win8 even though it is sitting on a shelf beside me, because Boot Camp 5.0 doesn't support Win8 on my Mac.

Perhaps there'll be a hack that lets me do it sometime.

As for pre-packaged 32-bit getWizPnP releases, I intend to make an off-line copy of my Perl 5.12 installation in case of further problems, but I suspect that it will eventually suffer from bit rot and become untenable.

It's the availability of a 32-bit PAR-Packager that's causing me problems, not whether I'm running XP or Win7. If I were running XP, I'd still have a problem - either upgrade to Win7 (or Win8, theoretically) or not be able to make pre-packaged Windows versions at all, sometime down the track.

Since my post, I've also discovered that PAR-Packer is broken in Cygwin, too. I've been thinking of dropping Cygwin support for pre-packaged getWizPnP since I don't think it has many users, but perhaps it could be a fallback for 32-bit distributions, if PAR-Packager gets fixed.

[IanSav]

Hi Gully,

Not to challenge your decision but just to correct you as there are still plenty of shops selling Windows 7 and at a cost around $100-150 for an OEM edition.

I should have posted that I was talking about the retail editions. These OEM versions are not meant to be sold at retail *without* hardware though we all know that it happens.

I was waiting for the Australian price to come down to about $50 like it is/was in the USA.

Regards,
Ian.

[Gully]

I was waiting for the Australian price to come down to about $50 like it is/was in the USA.

Well we would all like that.

[Luke]

I just installed PAR::Packer in ActivePerl 5.16.3 on Win XP 32 bit via cpan. One small problem building a dependency (Win32::EXE) was caused by the version of mingw that cpan automatically installed, but that was easily fixed by installing an updated version from sourceforge (mingw-get-inst-20120426.exe).

[prl]

Thanks, Luke.

[Luke]

I only tested by pp'ing a print "Hello World\n"; script (which is about the limit of my perl skills...), but that worked fine.

[prl]

I only tested by pp'ing a print "Hello World\n"; script (which is about the limit of my perl skills...), but that worked fine.

Hmmm... I'm currently having the problem that on Cygwin, a Hello World script compiles just fine, but pp on getWizPnP just runs and runs and runs ...

I'm going to go ahead with a release of 0.5.4 without a pre-packaged Cygwin version. The Cygwin version may follow.

Does anyone use the Cygwin version?

[Luke]

I don't/YARDWiz doesn't.

I'd wager that anyone who actually uses cygwin at home has the know how to install getWizPnP.pl dependencies and run from source anyway. I use it (cygwin) at work so I can write bash scripts instead of batch scripts but that's about it. You should be able to run the non-cygwin version of getWizPnP.exe from a cygwin bash prompt anyway (probably need to be careful about directory paths).

[prl]

Version 0.5.4

A new version of getWizPnP is available from the GetWizPnP Release page on the OpenWiz Software Pages.

Changes from the last release (0.5.3) are:

• Allow the use of GETWIZPNPCONF environment to specify the getWizPnP configuration file rather than use the programmed default. If GETWIZPNPCONF is set to an empty string, then no configuration file is loaded at startup. Intended to allow the use os alternative configuration files, especially for programs like YARDWiz and WizZillathat provide GUI interfaces to getWizPnP.
• Fixed bug which caused a Perl internal error message instead of the intended getWizPnP error message if an error occurred in a recording copy or move.
• Fixed several bugs that contributed to getWizPnP --resume not resuming recording correctly.
• The test to avoid seeking on stdout if it was a pipe or socket was incorrect. It failed if the output file was a newly-created file (-s used instead of -S). Fixed.
• Added options --before and --since to limit downloads by recording times.
• Fixed lack of error reporting when syswrite() fails during a HTTP GET request.
• Change all the HTTP_BAD_REQUEST error returns generated in getWizPnP to HTTP_FORBIDDEN to avoid triggering --retry re-fetches when the error didn't come from the Beyonwiz.
• --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.**This changes the default format of the match date.**
• In the progress bar on --resume, show progress for the whole recording, not just the progress over the part being resumed.
• Documentation of new features in getWizPnP documentation.
• Some tidying-up of getWizPnP documentation.
• Added undocumented --delay option.

Known bugs in 0.5.4:

• On Windows 7, sometimes getWizPnP fails to discover Beyonwiz servers on the network. The reason is not clear, but it can sometimes be worked around by specifying a larger timeout. Try --wizpnpTimeout=2.
• getWizPnp sometimes fails part-way through a recording copy with a HTTP 400 - Bad Request error. WizFX also seems to have similar problems on Windows 7. The cause of the problem is not clear, but it may be something common to both getWizPnP and WizFX.
• The changes to the file indexing from 01.05.283 mean that if you delete a recording on the Beyonwiz (--delete/--move), it will remain in the internal index (i.e. visible in the file player, and visible in WizFX) until you start a recording index rebuild using FILEPLAYER, SOUNDTRACK on the remote, or a HDD check is done. This can only be fixed in the Beyonwiz firmware.
• In free-to-air EPGs, the information used by getWizPnP for the episode name is sometimes actually the program synopsis. This is in the broadcast data and so is not strictly a getWizPnP bug.
• Only Australian time zones are available for use by --before and --since.

Thanks to several forum contributors for finding and helping locate the bugs fixed in this version.

[Luke]

Aaand openwiz.org appears to be down...
Edit, no it's not - your link is missing the "www" that seems to be required.

[prl]

Aaand openwiz.org appears to be down...
Edit, no it's not - your link is missing the "www" that seems to be required.

Fixed now...

[prl]

End of the line for compiled getWizPnP on 32-bit Windows?

I've just had to rebuild the Win7 installation on my Mac afer it was repaired with a replacement motherboard. I'd have expected I'd have to do that, though, I would have expected a nasty message from Windows rather than what happened - hanging during boot.

As a consequence my Perl installation was wiped out, and I've reinstalled ActivePerl 5.16.3 (32-bit), with the intention that I could build compiled versions of getWizPnP that would run on both 32-bit and 64-bit Windows.

Unfortunately the Perl PAR::Packager package needed to "compile" standalone Perl executables doesn't seem to be available for 32-bit Perl 5.16, only for the 64-bit version. I haven't yet installed 64-bit Perl to check whether I can compile getWizPnP on it, but I assume that I'll be able to.

I'm pretty ignorant about 32/64-bit architecture issues for Windows, but I'd guess that the 64-bit Perl executable in a "compiled" getWizPnP probably won't run on a 32-bit system. Is that correct?

If it is correct, can anyone think of a workaround?

How much of a limitation will it be if I can only produce a 64-bit version?

[Luke]

You could try installing PAR::Packer from cpan. Needs a bit of fiddling though. Win32::Exe won't build with the version of the MingW C compiler (gcc 3.*) that cpan installs. Nor will it compile with the latest MingW (gcc 4.8.1). I compiled it successfully by installing an older version of the MingW compiler suite (gcc 4.6.2).

... 20 minutes later ...

However, when trying to document the install steps to post here with a fresh MingW install of the older compiler,I can't reproduce it now. I think in all my stuffing around I had some sort of hybrid that just "magically" worked...

Anyway, if you want a copy of AS Perl (5.16.3 win32) with a working PAR::Packer, let me know and I'll PM you a download link.

[prl]

...
Anyway, if you want a copy of AS Perl (5.16.3 win32) with a working PAR::Packer, let me know and I'll PM you a download link.

Hi, Luke. Thanks.

I'll take up your offer of a "ready-to-go" AS Perl with PAR::Packer so I can get the beta out ASAP. I'll have a fiddle around with getting PAR::Packer to install from CPAN for me.

Perhaps the sequence was to install PAR::Packer part way (dependencies like Win::Exe) with one version of MingW, install another version of MingW, complete install (or some possibly more arcane variation).

[prl]

You could try installing PAR::Packer from cpan. Needs a bit of fiddling though. Win32::Exe won't build with the version of the MingW C compiler (gcc 3.*) that cpan installs. Nor will it compile with the latest MingW (gcc 4.8.1). I compiled it successfully by installing an older version of the MingW compiler suite (gcc 4.6.2).

... 20 minutes later ...

However, when trying to document the install steps to post here with a fresh MingW install of the older compiler,I can't reproduce it now. I think in all my stuffing around I had some sort of hybrid that just "magically" worked...

Anyway, if you want a copy of AS Perl (5.16.3 win32) with a working PAR::Packer, let me know and I'll PM you a download link.

I've been trying to reproduce how you built PAR::Packer, and I'm having trouble with installing MinGW with gcc 4.6.2.

I installed a fresh copy of AS Perl, and then ran

Code: Select all

mingw-get install gcc=4.6.2-1

That installed a bunch of stuff, and then I added C:\MinGW\bin to my PATH ahead of the Perl directories.

Then I ran

Code: Select all

cpan install Win32::Exe

which complained that I didn't have MinGW or dmake installed, and proceeded to install them using PPM.

It then started a build of Win32::Exe, but died when it tried to run gcc out of my hand-installed MinGW (with gcc 4.6.2), with a popup error saying it couldn't find libmpc-2.dll, which was right, because the only mpc2 DLL in C:\MinGW\bin was libmpc-3.dll. I wasn't able to get it to install a different libmpc DLL.

What am I doing wrong here?

[Luke]

Perhaps mingw-get isn't picking up a dependency that it should. I'm out of town until Tuesday, I'll have another go when I'm home.

[prl]

Thanks, Luke.

I'll go ahead and make a beta with the Perl I got from you.