Beyonwiz Australia

bpratt wrote:%APPDATA% as in c:\users\brendan\appdata\yardwiz\config.ini ?

Yes, that location. But this won't exist if this is the first time you've installed yardwiz as it only gets created when your preferences get saved. I incorrectly assumed you had a previous version installed.

Try the latest beta version, that bug has been fixed.

Latest version works fine now, although I don't always get all of the files as I'm getting Copy Failed : Bad request ... although restarting the download eventually gets it.

When I eventually get it down as a .ts file, I can't load it in to Vegas Pro v9, so what else do I need to do to get this to work ? I might go and see if I can find an answer to this elsewhere on the forum.

I'm glad that resuming the download now works properly. There was a bug in getWizPnP that was causing that.

I still don't know what's causing the Bad Request errors in Windows. I haven't been able to reproduce them.

Latest version works fine now, although I don't always get all of the files as I'm getting Copy Failed : Bad request ... although restarting the download eventually gets it.

When I eventually get it down as a .ts file, I can't load it in to Vegas Pro v9, so what else do I need to do to get this to work ? I might go and see if I can find an answer to this elsewhere on the forum.

Vegas doesn't recognise Beyonwiz TS files or from memory Topfield REC files. You will need to convert them to stock standard mpeg first. You could use ProjectX to demux them into video mpv. audio mpa and subtitles srt if needed or use MPEGStreamclip etc

If you use Vegas as your video editor of choice then you are better off using ProjectX in demux mode to give you the individual tracks with the advantage that ProjectX cleans up most transmission errors if any --- you can bank on it listing 9 in most cases.

netmask wrote:... Vegas doesn't recognise Beyonwiz TS files or from memory Topfield REC files...

Your memory is correct. Topfield 7xxx PVRs, like Beyonwiz, simply copy out the broadcast stream as a pruned (services not being recorded are stripped out) MPEG2 Transport Stream (TS) file. Topfield 5xxx PVRs do the same, but put a header at the front of the TS file.

Here's another thing I've noticed, but I've got a lot of files which have the exact same name as far as yardwiz is concerned, so whenever I transfer the file across is writes over another of the same name.

Well they aren't all the same name, as as the P2 has a longer name that includes a timestamp to differentiate, but yardwiz only seems to only get as far as the file date.

The reason why these files look the same is because I have been recording multiple segments of the one show, and without the full filename, it gets saved with the shortened filename overwriting the .ts or .tvwiz of that similar name.


What I am saying is that it would be great if yardwiz was able to save the full filename by default.

My downloads using YardWiz are like this

Prophets Of Science Fiction 2012-04-15.ts
Prophets Of Science Fiction 2012-04-22.ts
Prophets Of Science Fiction 2012-04-29.ts
etc etc

Same series name followed by the date

The filenames are generated entirely by YARDWiz, and the date is normally enough differentiation, but perhaps something additional could be added. I'm not sure what Beyonwiz does with the start time of an edited recording (if something is cut off the start).

Netmask, bpratt's problem appears to be caused by a program that's been recorded in pieces (or perhaps edited that way), and so all the pieces have the same date. Hence the overwriting.

The "full filename" isn't really a useful concept for Beyonwiz recordings, both YARDWiz and the underlying getWizPnP construct the filename from metadata in the recording's header. getWizPnP allows quite a bit of control over how the names are generated, but YARDWiz over-rides those features. Certainly the full name of the recording folder on the Beyonwiz is not a pretty sight, even though it is unique (e.g. something like 7TWO_Canberra_Feb.3.2013_23.7+56326.83220.tvwiz).

The suggested filename is just that, a suggestion. You can change it to anything you like in the 'save as' dialog.

I'm not going to change the default, but I'll look into adding some sort of preference to specify the default if you want to change it.

Luke

Are you going to release a new update to include Peter's new version and other changes, if any?

Yes, once prl releases GetWizPnP 0.5.4.

prl wrote: Netmask, bpratt's problem appears to be caused by a program that's been recorded in pieces (or perhaps edited that way), and so all the pieces have the same date. Hence the overwriting.

The "full filename" isn't really a useful concept for Beyonwiz recordings, both YARDWiz and the underlying getWizPnP construct the filename from metadata in the recording's header. getWizPnP allows quite a bit of control over how the names are generated, but YARDWiz over-rides those features. Certainly the full name of the recording folder on the Beyonwiz is not a pretty sight, even though it is unique (e.g. something like 7TWO_Canberra_Feb.3.2013_23.7+56326.83220.tvwiz).

That's exactly it, I record the sohws I want to keep in pieces, as it means I don't need as much HD space for the recording, as I eventually edit all the bits together the way I want and then put it on to DVD (it's all SD so it's not big loss).

The full filename as you've said is pretty damn ugly, but it certainly is unique.

Whilst Luke says you change the suggested filename, you certainly can, but it's easier to trim down a filename, than it is to add the extra appropriate characters when you are trying to save multiple files.

I'm hoping Luke can do an update to allow the longer by default, or at least allow people to choose a default naming, be that long like what I'm after or the current default perhaps ?

You can have the time included in your filename
Tools > Options > Date format for filenames
Default is
%Y-%m-%d
but you can add the hours and minutes
%Y-%m-%d-%H%M

Luke wrote:Yes, once prl releases GetWizPnP 0.5.4.

Thanks

Gully wrote:Luke

Are you going to release a new update to include Peter's new version and other changes, if any?

The file name formatting options in getWizPnP aren't new. I don't think the file name formatting options in YARDWiz are, either.

The main changes (apart from bug fixes) in getWizPnP 0.5.4 are not yet supported by YARDWiz (at least not in the last beta I downloaded).

I'll release what I hope will be the last beta of 0.5.4 as soon as I can.

glow wrote:You can have the time included in your filename
Tools > Options > Date format for filenames
Default is
%Y-%m-%d
but you can add the hours and minutes
%Y-%m-%d-%H%M

I'd completely forgotten about that! Thanks, that should sort bpratt's issue.

prl wrote:The file name formatting options in getWizPnP aren't new. I don't think the file name formatting options in YARDWiz are, either.

The main changes (apart from bug fixes) in getWizPnP 0.5.4 are not yet supported by YARDWiz (at least not in the last beta I downloaded).

I'll release what I hope will be the last beta of 0.5.4 as soon as I can.

Sorry, I wasn't thinking about the naming when I posted that just some of the other updates and fixes.

Thanks Peter.

glow wrote:You can have the time included in your filename
Tools > Options > Date format for filenames
Default is
%Y-%m-%d
but you can add the hours and minutes
%Y-%m-%d-%H%M

DOH DOH DOH !!!!!

That'll do what I want to do... thanks !

Didn't notice that in the config until you pointed it out to me, thanks.

There is a limited release of getWizPnP 0.5.4 beta3 now available for download.

I hope that this will be the last beta for 0.5.4, and that I can get a distribution copy out so that Luke can do a proper release of YARDWiz.

The original post of the beta release announcement and my post here to let YARDWiz users know about it seem to have disappeared in the Great Database Restore of March 2013.

Yes Minister - Open Government wrote:Jim Hacker MP: How am I going to explain the missing documents to the Mail?
Sir Humphrey: Well this is what we normally do, in circumstances like these. [hands over a file]
Jim: [reading] This file contains the complete set of papers, except for a number of secret documents, a few others which are part of still active files, a few others lost in the flood of 1967. [to Humphrey] Was 1967 a particularly bad winter?
Sir Humphrey: No, a marvellous winter, we lost no end of embarrassing files.
Jim: [reading] Some records which went astray in the move to London, and others when the War Office was incorporated in the Ministry of Defence, and the normal withdrawal of papers whose publication could give grounds for an action for liable or breach of confidence, or cause embarrassment to friendly governments. [to Humphrey] Well that's pretty comprehensive. How many does that normally leave for them to look at? [Humphrey says nothing] How many does that actually leave? About a hundred? Fifty? Ten? Five? Four? Three? Two? One? Zero?
Sir Humphrey: Yes Minister.

Hi, Luke. How is the stability of getWizPnP 0.5.4beta3 looking? I'm ready to roll out a 0.5.4 release if the beta looks OK to you.

I've just implemented the --delay and --wizpnpTimeout arguments as YARDWiz options (in Windows) and haven't spent a great deal of time testing getWizPnP but I haven't come across any issues. Seems very stable.

I've done a bit more testing and no issues with getWizPnP beta 3.

Just thanks for this great little program.

I wish i could program

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 story is over in the getWizPnP topic.

I'm still using 32 bit XP and Windows 7 with YARDWiz but don't use getWizPnP directly.
So it would be a shame if I couldn't get the latest features or bug fixes.
However I'm very happy with YARDWiz 0.4.2.0 and getWizPnP 0.5.3 today so if that was the last 32 bit version I could certainly get by.

I guess if somehow there were later versions of Beyonwiz firmware released that needed changes in getWizPnP then it could be a problem for us 32 bit users.

Luke has posted that he was able to get a working version of 32-bit PAR-Packager running in 32-bit ActivePerl. So things may not be as dire as I first thought.

Anyway, I intend staying on my current 32-bit version of Perl 5.12 for as long as I can.

I don't forsee problems with changes caused by the Beyonwiz firmware.

But I still have some improvements in mind for getWizPnP.

A new version of getWizPnP, 0.5.4, is available.

Beta versions of 0.5.4 are no longer available.

I can't find a solution on the forums.. When I scan I get the following that doesn't display anything. Having the same issues with WizFX, where that used to work a long time ago.

The WizPnP server is online.
Finished listing programs on the WizPnP server
Connecting to lounge (192.168.1.7:49152)...
The WizPnP server is online.
Finished listing programs on the WizPnP server

Try the most recent beta. I'm about to release a new version, but can't until I set my PC up again (packed up due to house renovations).

You can also try enabling debug logging (Tools->Options->Debug) and PM me the output log file.

Can you also provide info on what PC operating system and Beyonwiz firmware you are using.

Got the log via PM, thanks Yorto.

The log seems to indicate getWizPnP is not returning anything. Can you try two things for me?

1. Open a browser and navigate to http://192.168.1.7:49152/index.txt and PM to me.
2. Open a command prompt in the YARDWiz install directory (in Windows Explorer navigate to "C:\Program Files (x86)\YARDWiz" if you have Win 7 64bit or "C:\Program Files\YARDWiz" if you run 32 bit, hold the Shift key and right click then select "Open command window here"). Enter the following command: getWizPnP.exe --all -l --index -H 192.168.1.7 -p 49152 and PM to me.

Thanks, sent PM with 1. In CMD it is not doing much at all..

I can't see anything sensitive in that index.txt so I will quote here.

Yorto wrote:C:\Program Files\YARDWiz>getWizPnP.exe --all -l --index -H 192.168.1.7 -p 49152

C:\Program Files\YARDWiz>

That is the reply with the CMD.

Following is the text.

## DO NOT EXPORT OUTSIDE PVRs ## ## 3998 ## CE82F2F...really long string of gibberish (7996 chars)...455D7B4 idehdd/contents

I've never seen that before... I assume this is running on the "unlocked" Freeview Wiz?

It looks to me like techguys "unlocked freeview firmware 1.7.350 free ur freeview" isn't as unlocked as he claims...

I don't think there's anything I can do I'm afraid.

YARDWiz and getWizPnP should work fine on your P2 though.

Luke wrote:
YARDWiz and getWizPnP should work fine on your P2 though.

Yep, should have tried the beta on the dpp2 first.
Thanks.

Luke wrote:I can't see anything sensitive in that index.txt so I will quote here.

Yorto wrote:C:\Program Files\YARDWiz>getWizPnP.exe --all -l --index -H 192.168.1.7 -p 49152

C:\Program Files\YARDWiz>

That is the reply with the CMD.

Following is the text.

## DO NOT EXPORT OUTSIDE PVRs ## ## 3998 ## CE82F2F...really long string of gibberish (7996 chars)...455D7B4 idehdd/contents

I've never seen that before... I assume this is running on the "unlocked" Freeview Wiz?

It looks to me like techguys "unlocked freeview firmware 1.7.350 free ur freeview" isn't as unlocked as he claims...

I don't think there's anything I can do I'm afraid.

YARDWiz and getWizPnP should work fine on your P2 though.

I think you're right. My understanding is that the FV-L1's index.txt file is encrypted (and that that is all that secures WizPnP on an FV-L1). I suspect that it uses a hidden shared private key, but I'm not certain.

It may be hackable, but I don't intend to try to.

Yorto, just for information, I wrote getWizPnP, which is a WizPnP file transfer client that's used by both YARDWiz and its predecessor WizZilla to do their communication with Beyonwizes.

I'm actually quite surprised that getWizPnP produced any output from an FV-L1.

I probably should have paraphrased Yorto's PM, the reference to getWizPnP just demonstrated the empty output. The only output was from the index.txt.

Luke wrote:I probably should have paraphrased Yorto's PM, the reference to getWizPnP just demonstrated the empty output. The only output was from the index.txt.

Ah. That makes more sense

Been quite a while, but I've just released a new version of YARDWiz.

Version 0.4.3

Downloads:

• Windows
• OSX 10.8 (Note: 10.6 no longer supported. Untested on 10.7)
• Linux 32bit
• Linux 64bit

New in 0.4.3:

• Add getWizPnP --retry option to retry downloads automatically if they fail.
• Add option to disable WizPnP server address caching.
• Replace separate Play and Pause buttons with a single button that switches between Play/Pause.
• Add --delay and --wizpnpTimeout getWizPnP options for Windows.
• Update getWizPnP to 0.5.4 in downloads that include a compiled version.

Fixed in 0.4.3:

• Fix Wiz Server combobox size and font.
• Fix bug setting preferences when GetWizPnP < 0.5.3 (http://www.beyonwiz.com.au/phpbb2/viewt ... =345#96362)
• Don't use 0.0 speeds when calculating estimated download time.
• Fix Unicode errors
• Fix WizPnP server discovery loop bug
• Fix segfault on Kubuntu 12.04
• Resize Wiz Server combo box after discover
• Fix OSError: [Errno 17] File exists when running setup.py install on linux with an existing installation
• Fix crash when saving preferences and VLC is not installed.
• Fix logfile display in class Stderr on OSX
• Move '.' to end of path for security
• Hardcode VLC path on OSX
• Fix multiple --no-video-title arg when calling VLC
• Create a limited environment for getWizPnP with HOME/APPDATA stripped out/empty GETWIZPNPCONF environment variable (getWizPnP 0.5.4+) so .getwizpnp/getwizpnp.conf doesn't get used. Resolves Issue 2.

Known issues

Thanks to prl for his assistance testing on OSX (and for writing getWizPnP!).

I've just released a new version of YARDWiz.

Version 0.4.4
Windows
OSX 10.8 (Note: 10.6 no longer supported. Untested on 10.7)
Linux 32bit
Linux 64bit

Fixed in 0.4.4:

• Fix program list sorting (resolves issue 37).
• Fix misssing program info.

Note: this release has had very minimal testing. Go forth and test guinea pigs

Version 0.4.4 seems to work ok for me - downloaded a queue of 4 recordings on Win 7.
Just noticed some error messages for some files - may have been present with the previous version but I wasn't looking too closely.
example error messages

glow wrote:Version 0.4.4 seems to work ok for me - downloaded a queue of 4 recordings on Win 7.
Just noticed some error messages for some files - may have been present with the previous version but I wasn't looking too closely.
example error messages

Code: Select all

Downloading Kitchen Whiz - Kitchen Whiz...
Error, unable to download D:\temp\Kitchen Whiz 2013-06-27.ts.
getWizPnP STDOUT:GO!: Kitchen Whiz/Kitchen Whiz - Copy
getWizPnP STDERR:
Retrying (attempt 2).
Downloading Kitchen Whiz - Kitchen Whiz...
Download of D:\temp\Kitchen Whiz 2013-06-27.ts complete.

If the recording downloaded successfully on a subsequent attempt, don't worry, it's doing what it's supposed to if the download "drops out" for some reason (not uncommon with Win 7).

Hi Luke.

Edit: Not a problem. I've found the reason - see the last line.

I’ve just updated to YARDWiz 0.4.4 from 0.4.3 on the Win8 Notebook & the XP Desktop (I didn’t really get to try 0.4.3).
With 0.4.3 still on the XP Desktop & with 0.4.4 on the Win8 Notebook, one difference I noticed between the two; you appear to have rounded the size in MB to one decimal place in 0.4.4 whereas in 0.4.3 it isn’t rounded. In 0.4.3 (when it was still on my XP Desktop) I noticed the titles bar showed ‘Size (MB)’ whereas the titles bar in 0.4.4 (on my Win8 Notebook) showed ‘Size (...’.
On the Notebook there is still plenty of space between ‘Length’ & the scrollbars, & the ‘Size’ column can be dragged wider to display the title correctly.

I thought the reason for this was due to the size of a couple of recordings being displayed to more than one decimal place in 0.4.3 (one in particular was displayed as 383.0909729MB in 0.4.3, & displays as 383.1MB in 0.4.4). However when I upgraded to 0.4.4 on the XP Desktop I noticed the titles bar showed ‘Size (MB)’ even though all the same recordings had been rounded to one decimal place.

I then thought the reason was probably due to the different screen resolution between the Desktop monitor (1680 x 1050) & the Notebook screen (1366 x 768), but when I connected the Notebook to the Sony TV via HDMI I still got the truncated 'Size' title even with higher screen resolutions selected in Windows. The only doubt about the tests on the TV; the desktop images & text displayed on the TV screen became smaller as the resolution was increased up to 1920 x1080.

This isn’t an issue for me, just an observation - it looks a lot neater when rounded to one decimal place & the ‘Size (MB)’ title being truncated is here nor there.

BTW – ‘RELEASE’ in the YARDWiz directory is a bit hard to read with Windows Notepad – but not a problem with Progammer’s Notepad 2.

Edit: Solved ... On the little 11.6” Notebook I forgot I have the size of all items on the screen set to 125%. When I set it to 100% the ‘Size’ title displays correctly.

With 0.4.3 size was rounded to 1 decimal place in one bit of code and not another so I made it consistent.

I've just released a beta version of YARDWiz.
Versions for Windows, OSX (10.8) and Linux (32 & 64 bit) can be downloaded from the YARDWiz Bintray repository*

Version 0.4.5Beta1

Fixed in 0.4.5Beta1:

• Update getWizPnP to 0.5.5beta1 in downloads that include a compiled version.

New in 0.4.5Beta1:

• Fix sort after delete.
• Show error messages in a dialog box as well as in the log tab.

* YARDWiz downloads are now hosted on Bintray as Google Code has discontinued download hosting.

Hi Luke,
Thanks for the Beta Update. I just tried it and encountered an error in installing it. The installer advised it could not fine YARDWiz.exe. I Retried without success, and then Ignored, and the program installed. It starts, but then exhibits the same behavior as the previous version - freezing when updating the recording information from the PVR. I tried unistalling the program, downloading another copy of the Beta installer, and reinstalling, but the same issues occurred. The error message no longer comes up in YARDwiz, instead Windows advises that getWizPnP.exe has stopped working.
Sorry to be the bearer of bad news...
BTW - I tried an older version from a backup - Ver 3.8.1, and while it did report an error, it did a complete read of the PVR and would allow downloads etc.
Many thanks for your efforts.
Neil.

Ooops, the windows version contained an older getWizPnP.exe. New windows version uploaded to the YARDWiz repository

Hi, Luke.

I've just tried out YARDWiz 045 beta1 with the new version of getWizPnP, and it has no problems scanning a BW that has a recording doctored so that it would cause infinite recursion on the previous getWizPnP release.

However, I got a YARDWiz popup telling me there were error messages in a log file. I was expecting the messages to be the error message from getWizPnP about the truncated header.tvwiz, but they were YARDWiz errors, all like this: The index name for the recording is: The index.txt entry for the recording is The recordings that cause this are ones that don't have a date/time stamp in their index name. I can't recall what I did to the recordings that made them lose their date in the index name (they still have it in their recording folder name). Perhaps a rename?

The error means that the recordings don't appear in YARDWiz in the list of recordings for the device, and when the recordings list finishes updating, YARDWiz hangs still showing Connecting... in the status bar at the bottom and with the progress bar at the bottom with just the green highlight pulse drifting across it. It's not responsive to the EXIT button, File>Exit or the Windows red X button to exit. I need to use the task manager to kill it. The task manager doesn't show either getWizPnP.exe or perl.exe, so perhaps getWizPnP has exited, but YARDWiz still expects some more output from it?

Thanks Peter. Fixed in 0.4.5Beta2

Version 0.4.5Beta2

Versions for Windows, OSX (10.8) and Linux (32 & 64 bit) can be downloaded from the YARDWiz Bintray repository*

Fixed in 0.4.5Beta2:

• Handle recording index without date.

* YARDWiz downloads are now hosted on Bintray as Google Code has discontinued download hosting.

Happy to advise that this version has seemed to have resolved a discovery problem for me.
Previously, I generally had to insert the IP address.

Curious. There's been no change in the part of getWizPnP that handles discovery. I find that on Windows getWizPnP discovery seems to break and fix itself at random.