getWizPnP - Beyonwiz recording downloader
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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?
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?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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:
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
- 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)
- 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.
Last edited by prl on Wed Apr 03, 2013 13:18, edited 1 time in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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:
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
- 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)
- 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.
Last edited by prl on Wed Apr 03, 2013 13:19, edited 1 time in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Even with the minimum amount of code executing, say, "getWizPnP --version" or "--help"?Luke wrote:The canned OSX version crashes when executed, the error message is "Illegal instruction".
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$
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
OK, so it seems to be dying well before any user code gets executed.Luke wrote: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.
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$
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
Code: Select all
bnls-Mac:~ bnl$ md5 getWizPnP
MD5 (getWizPnP) = ff5970cb4a81f75745be77d4119bca12
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.
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.
Last edited by Luke on Fri Feb 08, 2013 11:27, edited 1 time in total.
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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.Luke wrote: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.
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?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Thanks, Luke. Seen it.Luke wrote:I'm too slow editing... see edit in previous post
However
Luke wrote:... 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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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.
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.
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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.
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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...
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Sounds unpleasant. Fortunately, I'm in no rush to do this.Luke wrote:... 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...
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Well, I posted the links and a short release note. New copy to follow shortly.Luke wrote: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)?
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"...
Last edited by prl on Wed Mar 06, 2013 17:30, edited 3 times in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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:
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
- 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.
- 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.
- 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.
Last edited by prl on Wed Apr 03, 2013 13:15, edited 3 times in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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.
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.
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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).Luke wrote:... I noticed that getwizpnp.conf is included in the canned linux zipfile instead of .getwizpnp, was that intentional? ....
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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 getWizPnPLuke wrote:...
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
End of the line for 32-bit prepackaged getWizPnP?
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.
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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.
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.
Hi IanIanSav wrote:Windows 7 was always way too expensive and has now been withdrawn from sale.
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.
Cheers
Gully
_____________
Beyonwiz U4
Logitech Harmony Elite
Google Pixel 6 Pro
Gully
_____________
Beyonwiz U4
Logitech Harmony Elite
Google Pixel 6 Pro
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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.
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
Hi Gully,
I was waiting for the Australian price to come down to about $50 like it is/was in the USA.
Regards,
Ian.
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.Gully wrote: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 was waiting for the Australian price to come down to about $50 like it is/was in the USA.
Regards,
Ian.
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).
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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 ...Luke wrote: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.
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?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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).
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).
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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:
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.
- 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.
Last edited by prl on Wed Apr 03, 2013 14:32, edited 1 time in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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?
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?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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.
... 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.
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Hi, Luke. Thanks.Luke wrote:...
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'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).
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
I've been trying to reproduce how you built PAR::Packer, and I'm having trouble with installing MinGW with gcc 4.6.2.Luke wrote: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 installed a fresh copy of AS Perl, and then ran
Code: Select all
mingw-get install gcc=4.6.2-1
Then I ran
Code: Select all
cpan install Win32::Exe
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?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV