getWizPnP - a command-line WizPnP uploader

craigh · Post by **craigh** » Thu Jan 01, 2009 20:17

Hi Peter

I have processed 50+ tvwiz reciordings using the --indir and --move options.

A few observations.

It handled a drive filling up ok and gave a message of
"No Space left on drive"

Then luckily "Delete Failed Unauthorized" on the source file

After emptying the drive and starting the script again it seems it always gets "Delete Failed Unauthorized" when it tries to delete teh source files.

They are on an SMB drive and it has full admin rights.

prl · Post by **prl** » Thu Jan 01, 2009 21:42

craigh wrote: It handled a drive filling up ok and gave a message of
"No Space left on drive"

Then luckily "Delete Failed Unauthorized" on the source file

That's good; I don't think I ever tested that.

craigh wrote:After emptying the drive and starting the script again it seems it always gets "Delete Failed Unauthorized" when it tries to delete teh source files.

They are on an SMB drive and it has full admin rights.

Unix errno.h type errors get aooed to HTTP status codes so that the error returns for remote and local files can be handled uniformly. Of course, in Windows, there's another mapping from the WIndows error to the Unix error code.

The HTTP error code RC_UNAUTHORISED can represent any of the following on delete:
EACCESS - Permission denied. An attempt was made to access a file in a way forbidden by its file access permissions.
EPERM - Operation not permitted. An attempt was made to perform an operation limited to processes with appropriate privileges or to the owner of a file or other resources.
ENOTEMPTY - Directory not empty. A directory with entries other than `.' and `..' was supplied to a remove directory or rename call. (when it tries to delete the recording folder)

On the folders where you get the error message are there any files left in the directory? In particular, has the trunc file been deleted, and there are still some recording files (0000, 0001, etc...) or some other files?

craigh · Post by **craigh** » Fri Jan 02, 2009 07:28

Hi Peter

On the folders where I get the "Delete Failed: Unauthorized" nothing at all gets deleted.

It copies the entire contents teh fails to delete anything.

If I do it manually it all deletes fine.

As I said they are on smb drives.

Once the latest script finishes I will test the delete from within its shell instance but it will probably be the same.

prl · Post by **prl** » Fri Jan 02, 2009 08:41

craigh wrote:Hi Peter

On the folders where I get the "Delete Failed: Unauthorized" nothing at all gets deleted.

It copies the entire contents teh fails to delete anything.

If I do it manually it all deletes fine.

As I said they are on smb drives.

Once the latest script finishes I will test the delete from within its shell instance but it will probably be the same.

By manual delete, do you mean from within Windows Explorer?

I'd be interested in what you see using getWizPnP direct from the command-line. Even if it has the same error (and I've no reason to suppose that it won't) it will print the name of the file that it had problems with, as well as the Unix error message. This will be a bit more informative than the bald "Delete Failed: Unauthorized" that gets printed at the higher level of the code. You should get something like "Recording file/directory recordingName at fileName: UnixErrorMessage".

craigh · Post by **craigh** » Fri Jan 02, 2009 09:08

Peter

Script still has a few hours to go but this is teh exact error from --Move

PRIME HD: bones/The Final Push - Move
In the Season 12 finale of The Amazing Race, the three remaining
teams set off from Taiwan in a final push to win the million bucks.
After flying to Anchorage in Alaska, there's a messy Detour involving
live crabs and dead fish to contend with before a final Roadblock
that tests everyone's memory.
Index name: bones_12 Sep.20.2008_19.48
Thu Jul 31 21:30:00 2008 - Thu Jul 31 21:32:41 2008
playtime: 2:41 recording size: 211.4 MB
|==================================================| 0.3MB/s 100% 211/212MB
Recording file/directory bones - The Final Push - Thu Jul 31 2008 at \\hhomens\
beyonwiz\bones\bones_12.tvwiz\header.tvwiz: Permission denied
Delete failed: Unauthorized

And yes I deleted the tvwiz directory previously using Windows Explorer.

Will try the delete option on getWizPnP when it finishes

prl · Post by **prl** » Fri Jan 02, 2009 10:18

Hi Craig.

"Permission denied" is an error in performing an operation, but not one that has to do with file access control.

A possibility is that getWizPnP isn't closing header.tvwiz in some execution path. That wouldn't be a problem on Unix systems, because deleting an open file isn't an error in Unix (it has well-defined semantics). On Windows, it's an error to try to delete an open file. It's odd, though, that the error only happens occasionally.

Edit: Craig, could you make a copy of a recording that's giving you this problem, and try both --move and --delete st see if there's any difference?

craigh · Post by **craigh** » Fri Jan 02, 2009 11:23

Hi Peter

happens on every tvwiz directory.

I tried the following

-- move specific recording (moved fine but failes to delete)
--delete specific recording(deleted fine)

So you could be correct and your holding open a file.

prl · Post by **prl** » Fri Jan 02, 2009 16:07

craigh wrote:Hi Peter

happens on every tvwiz directory.

I tried the following

-- move specific recording (moved fine but failes to delete)
--delete specific recording(deleted fine)

So you could be correct and your holding open a file.

Thanks, that will help localise it.

Edit: I found that I wasn't normally closing the header file when I read it to decode it (get recording name, etc), and I've fixed that, but I don't see now how it is that deleting with --delete would work, since in both cases the header.tvwiz file would have been held open.

Anyway I'll check --indir --move on a PC before I do the release and check that I've dealt with this bug. Thanks for helping track it down.

Re-edit: I put getWizPnP on a PC, and I can make the "Permission denied" problem come and go by removing and putting in the extra "close" statement in the code that decodes the header.tvwiz code.

I've finished coding and documenting the major change in the next version of getWizPnP, the caching of the Beyonwiz device location information. It's had a bit of testing on Windows & cygwin, but now I need to do some burnin tests to optimise the cache lifetime to the minimum lifetime that prevents failed searches.

prl · Post by **prl** » Sun Jan 04, 2009 07:18

prl wrote:
craigh wrote:Hi Peter

Its all working with the indir option now on Windows XP.

Also it finds the server without Host 2 in 5 times on my setup

Thanks
Great. I've started working on cacheing the WizPnP searches. That may improve things the reliability.

I've found the bug (problem, indiscrepency, Windows Wierdness) that was causing WizPnP device search to fail a lot of the time on Windows.

I discovered when I was trying to tune the cache lifetime for discovered devices that even for relatively long times between successive searches (up to 5 minutes), the rate of search failure remained pretty much constant. This wasn't what I'd expected from the discussion about packet reassembly and TIME_WAIT state in the WizZilla topic. TIME_WAIT state is typically held for about 3 minutes. I had expected that the probability of failure should go down to pretty much zero when the interval between requests was greater than any state delays in the OS IP system.

On reflection, I guess that it shouldn't have been surprising, since the ports involved were UDP, and TIME-WAIT is a TCP connection state.

The SSDP protocol sends out a "ssdp:discover" UDP request on an IP multicast address to a specified port (239.255.255.250:1900). Any devices that match the request respond by sending a UDP reply containing the URL of an XML device descriptor (and some other stuff), back to the originating port on the originating host. The originating port is chosen essentially randomly by the host OS, and is typically not 1900.

The old code for WizPnP search in getWizPnP created the multicast request socket, requested that socket's port number and created the directed response socket on the same port number. I probably should have realised at the time I wrote it that that was a bit daft, but somehow in OSX (my main development environment), the incoming response packets were always delivered to the right socket. Not so on Windows (and consequently also on Cygwin, which is simply a light Unix-ish veneer applied on top of Windows). The response messages appear to have only been delivered to the right socket sometimes. That's where I think the Windows Wierdness comes in. Why only sometimes? I'd have hoped for "all or never". Anyway, my excuse is that it's a long time since I've had to get my hands dirty in IP plumbing.

The fix is to create the request socket, save its port number, send the request, close the socket, and create the response socket on the request socket's port number and listen for responses.

Anyway, it appears that WizPnP device search now works (tried in rapid succession a couple of thousand times) flawlessly (or as flawlessly as UDP can work). No caching is required, and I've removed the caching code from the version of getWizPnP that I'll distribute. Being an incorrigible code packrat, I'll hold onto the caching code in case it ever turns out to be useful on performance grounds. Given the (lack of) speed of most of the other important parts of WizPnP, I doubt it will ever be necessaery.

I just wish I'd done the timings before I wrote the code

tonymy01 · Post by **tonymy01** » Sun Jan 04, 2009 09:40

Nice bit of work! How did you test in the Windows environ? Did you dig out an old dinosaur you had hiding somewhere

?

prl · Post by **prl** » Sun Jan 04, 2009 10:09

tonymy01 wrote:Nice bit of work!

Thanks!

tonymy01 wrote:How did you test in the Windows environ? Did you dig out an old dinosaur you had hiding somewhere ?

No, it's a fairly new Dell Laptop, but I don't own it

I've never owned a PC.

IanSav · Post by **IanSav** » Sun Jan 04, 2009 10:41

Hi Peter,

Does this mean that getWizPnP now has *all* the functionality of WizFX plus more?

Regards,
Ian.

prl · Post by **prl** » Sun Jan 04, 2009 12:05

IanSav wrote:Hi Peter,

Does this mean that getWizPnP now has *all* the functionality of WizFX plus more?

Regards,
Ian.

No, it has some functionality that WizFX doesn't have (--move, --delete, resume download), but lacks some functionality that WizFX has (copy media files other than BW recordings).

And, of course, its user interface is a little bit unfriendly, though for Windows users that should be taken care of by WizZilla.

The latter is next on the ToDo list. It's not completely trivial, because large media files on the BW are split into 1GB chunks, and there's yet another header file to decode. However, that one looks fairly straightforward.

prl · Post by **prl** » Sun Jan 04, 2009 15:25

getWizPnP 0.3.3 released

At last WizPnP device discovery seems to work properly for Windows and Cygwin/Windows!

Release notes

New:

New option --discover to just run the device discovery algorithm and print a list of discovered WizPnP servers and their IP addresses. Mainly for WizZilla support.
Added IP address of device in the "Connecting to..." line. Mainly for WizZilla support.
Changes MB in verbose output to the more correct MiB.
Configuration file now searched for in %APPDATA%\Prl\getWizPnP in Windows.
Configuration file now searched for in %APPDATA%\Prl\getWizPnP in Windows, and called getwizpnp.conf in Windows, rather than the .getwizpnp in Unix-like systems.

Bugs:

Uses bignum package for 64-bit integers, even when the underlying Perl integers are 64 bits.
When resuming a download, may fetch up to 32MB more data than is necessary.
Minor known problems that deleting a recording can cause are documented in the BUGS section of the docuentation. It is not known whether deleting a recording using getWizPnP can cause any major problems on the Beyonwiz.
Does not allow operations on media files from the Beyonwiz contents folder (access to the contents folder is available only in Beyonwiz firmware versions 01.05.261 and later).
Folder operations only work on firmware 1.05.280 and later
Sort on title only works on firmware 1.05.280 and later

Fixed:

Fixed some inaccuracies in recording size printouts.
File not being closed on non-error exit from Beyonwiz::Recording::FileHeader::readHdrChunk() was causing recording deletion to fail in --move on Windows. Fixed.
Fixed the problem of frequent WizPnP device search failures on Windows by ensuring that the request and response sockets, which are bound to the same port, don't remain open at the same time.

DaveR · Post by **DaveR** » Sun Jan 04, 2009 15:33

tonymy01 wrote:Nice bit of work!

Agreed.

prl · Post by **prl** » Sun Jan 04, 2009 15:36

Dave? wrote:
tonymy01 wrote:Nice bit of work!
Agreed.

Thanks again.

I've PM'd you and alwayslooking about some minor changes to the format of --verbose info that you may need to check against your --list parser.

alwayslooking · Post by **alwayslooking** » Mon Jan 05, 2009 09:21

Dave? wrote:
tonymy01 wrote:Nice bit of work!
Agreed.

Awesome prl

prl · Post by **prl** » Tue Jan 06, 2009 08:24

Thanks for the kind words, everyone.

Unfortunately, it looks as though in my haste to get the Windows fixes out the door, I've broken WizPnP device search on MacOS (and possibly on Linux, too), in much the sam way as it was broken on Windows -- searching fails to find any devices quite a lot of the time.

I'm not sure how it happened, because I did test the search on MacOS before I posted the new version. I think that I probably forgot to clear the PERLLIB variable, so that I was running the tests against an older installed Beyonwiz::WizPnP module instead of the one with with the Windows fix.

I'll try to get a patch version out ASAP. In the meantime, it's probably best for MacOS users to stay with version 0.3.2 or use the --host option with 0.3.3. Linux users, too, if 0.3.3 has problems with device search.

Can anyone using getWizPnP with Linux tell me whether getWizPnP device search works reilably on Linux? I'll try to give it a go under Ubuntu before I do the next release.

Unknown · Post by **Unknown** » Thu Jan 08, 2009 16:15

Hello. prl, thanks for this utility. I have been using the wizilla .exe of this to transfer stuff around but was wondering if anyone had any success getting this going on an icebox2?

The problem for me is my limited linux knowledge. I do have optware on mine, is it possible to use this to get the required perl libraries (?) ?

prl · Post by **prl** » Thu Jan 08, 2009 16:36

Unknown wrote:Hello. prl, thanks for this utility. I have been using the wizilla .exe of this to transfer stuff around but was wondering if anyone had any success getting this going on an icebox2?

The problem for me is my limited linux knowledge. I do have optware on mine, is it possible to use this to get the required perl libraries (?) ?

Thanks, I'm glad you've found it useful. All kudos for the WizZilla GUI must go to alwayslooking and Dave?, though.

I have no idea what's available on an icebox2 beyond it being a Linux box, possibly uClinux. You'll need to have a Perl installation on the box and a couple of Perl modules downloaded from CPAN. I think that one of the CPAN modules (IO::Socket::Multicast) requires a gcc installation, too, though it is possible (though slightly less convenient) to use getWizPnP without IO::Socket::Multicast. If it's uClinux, it may not be possible to get Perl running on it.

I think that download has been able to get getWizPnP running on a Linux-based NAS, but I don't think it was an icebox2.

Good luck with the venture, though!

Unknown · Post by **Unknown** » Fri Jan 09, 2009 15:48

that is my other option - I am using a mybook world which has been loaded with debian.... still takes me a long time to work through these things (days) because of my skill less ness.

Also - dont know if this is an accident or design but the wiz zilla release includes an exe of getwizpnp which you can run with all the switches from the command line without cygwin or any of that - which is what I am using with the windows task scheduler.

It would be much nicer to run from the nas or icebox with cron...

prl · Post by **prl** » Fri Jan 09, 2009 16:03

Unknown wrote:...
Also - dont know if this is an accident or design but the wiz zilla release includes an exe of getwizpnp which you can run with all the switches from the command line without cygwin or any of that - which is what I am using with the windows task scheduler.

It's by design, and with my willing consent. WizZilla is a GUI front end for a fully functional version of getWizPnP. Dave? and alwayslooking have always made that clear. It makes getWizPnP functionality (or at least most of it) available to people who otherwise might have decided not to use it.

You don't need Cygwin to run getWizPnP on a Windows machine, though if you don't use Cygwin, you will need a Perl installation (I test getWizPnP with ActivePerl 10.0 on Windows).

I do plan to try making and distributing a compiled-for-Windows version of getWizPnP, but probably only after I get downloading of files from the content directory working.

Unknown wrote:It would be much nicer to run from the nas or icebox with cron...

Without doubt.

craigh · Post by **craigh** » Sun Jan 11, 2009 18:05

Hi Peter

A couple of observations and a question re getWizPnP.

I have started writing an application that links getWizPnP and VideoRedo together and have noticed that my BW has been brought to its knees two days in a row after lots of testing.

The command lines used in my application were

getwizpnp.pl --discover >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\servers.txt"

getwizpnp.pl --list >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

getwizpnp.pl --List >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

These commands would have bee run a large number of times but it looks like the BW may have a memory leak with the protocol.

Prior to this testing my BW has never acted like this and after a reboot was fine for over 24 hours till another period of testing.

Not sure if you have seen something like this.

Also I wanted to know if there is any simple way to know when getwizpnp has finished its task. I am piping the output as i dont believe there is an option to output the results to a file but I cant tell when the output file is closed.

prl · Post by **prl** » Sun Jan 11, 2009 18:46

craigh wrote:Hi Peter

A couple of observations and a question re getWizPnP.

I have started writing an application that links getWizPnP and VideoRedo together and have noticed that my BW has been brought to its knees two days in a row after lots of testing.

The command lines used in my application were

getwizpnp.pl --discover >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\servers.txt"

getwizpnp.pl --list >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

getwizpnp.pl --List >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

These commands would have bee run a large number of times but it looks like the BW may have a memory leak with the protocol.

Prior to this testing my BW has never acted like this and after a reboot was fine for over 24 hours till another period of testing.

Not sure if you have seen something like this.

Also I wanted to know if there is any simple way to know when getwizpnp has finished its task. I am piping the output as i dont believe there is an option to output the results to a file but I cant tell when the output file is closed.

I'll give my BW a bit of a thrashing on those commands. I'm pretty sure that it's not --discover, because I've been doing testing of the discovery protocol, and I've run several thousand

searches against my DP-S1 without any problems. But it could be the others.

What should I be looking for specifically in bringing my BW "to its knees"?

craigh · Post by **craigh** » Sun Jan 11, 2009 19:32

Hi Peter

Dont spend too much time on it as I may have tracked the issue to my WD5000 hard drive.

It has been in the BW for over a year and looks like it may be showing its age......if I disable timeshift it gets a lot better.

I normally shut BW over night except on weekends so it would have been running for a few days on timeshift.

All the disk lookups may have just been a contributor to the drive problem.

Will keep playing but it may have been a coincidence.

prl · Post by **prl** » Sun Jan 11, 2009 21:50

OK. I might run my BW through a few hundred --discover, --List, --list operations and see if it breaks anything, anyway. I guess I'm just that kind of guy

By the way, if you'd like access to getWizPnP alphas, PM me with details about how I can get them to you. I hope to have a new release in the next week or so.

prl · Post by **prl** » Sun Jan 18, 2009 08:27

New version 0.3.4 of getWizPnP available on beyonwizsoftware.net.

Beyonwiz device search now verified to work on Wondows, Mac OSX and Linux (tested on Ubuntu Live CD for PC). Search timeouts fine-tuned (thanks to Dave? for much assistance), and adjustable from the commandline.

Some other options and minor changes for better interoperation with WizZilla.

Release notes:

New:

Added --dryrun option for copy move & delete.
Added --wizpnpPoll and --wizpnpTimeout to control search timeout and number of search polls.
Added recording name information to move and copy when --Verbose >= 1.
Added device port number to IP address in Connecting to... line when --Verbose >= 1.
Tuned search timeouts for multiple devices (with lots of assistance from Dave(R) from the Beyonwiz forum).

Bugs:

If there are two (or more) Beyonwiz PVRs with the same name on the network, getWizPnP will only find one, and which one it finds is unpredictable. Workaround: ensure that al beyonwiz devices have different WizPnP names (in SETUP>Network>WizPnP>Name). A name only needs to be set if SETUP>Network>WizPnP>NameServer is Enable.
Uses bignum package for 64-bit integers, even when the underlying Perl integers are 64 bits.
When resuming a download, may fetch up to 32MB more data than is necessary.
Minor known problems that deleting a recording can cause are documented in the BUGS section of the docuentation. It is not known whether deleting a recording using getWizPnP can cause any major problems on the Beyonwiz.
Does not allow operations on media files from the Beyonwiz contents folder (access to the contents folder is available only in Beyonwiz firmware versions 01.05.261 and later).
Folder operations only work on firmware 1.05.280 and later
Sort on title only works on firmware 1.05.280 and later

Fixed:

Fixed bug in --discover where discovery failed if multiple devices were returned.

IanSav · Post by **IanSav** » Sun Jan 18, 2009 13:25

Hi Peter,

I just fixed my Perl environment so I thought I would give getWizPnP a whirl. Unfortunately it is having issues discovering the three Beyonwiz units that are currently here. I was speaking to Dave on another issue and mentioned this issue. He had me try out TextMX.pl and it only reports 2 units being found at about 1 second to find them.

When I used "getWizPnP --discover" it only ever finds 1 unit at a time but the unit it discovers is random among the three units available.

Dave suggested that I mention to you that the two DP-S1 units are both called "Beyonwiz DP-S1". If you are indexing by this name then you may be overwriting one unit with the other during the discovery process. If this is the case then I suggest that you record the name, IP and port as a unique data triplet to ensure that all devices can be uniquely and reliably accessed.

Is there anything I can do to help you fix this? The other units will be going home tomorrow.

Regards,
Ian.

prl · Post by **prl** » Sun Jan 18, 2009 13:56

IanSav wrote:Hi Peter,

I just fixed my Perl environment so I thought I would give getWizPnP a whirl. Unfortunately it is having issues discovering the three Beyonwiz units that are currently here. I was speaking to Dave on another issue and mentioned this issue. He had me try out TextMX.pl and it only reports 2 units being found at about 1 second to find them.

When I used "getWizPnP --discover" it only ever finds 1 unit at a time but the unit it discovers is random among the three units available.

Dave suggested that I mention to you that the two DP-S1 units are both called "Beyonwiz DP-S1". If you are indexing by this name then you may be overwriting one unit with the other during the discovery process. If this is the case then I suggest that you record the name, IP and port as a unique data triplet to ensure that all devices can be uniquely and reliably accessed.

Is there anything I can do to help you fix this? The other units will be going home tomorrow.

Regards,
Ian.

Hi, Ian. Shortly after you posted about the problem caused by BWs with the same WixPnP name when WizPnP is used between BWs, I posted this in the same topic:

prl wrote:getWizPnP has a problem with this, too. I think it's possible to fix in getWizPnP, though I tend to agree with Htnut that this is a use problem, rather than a bug. After all, I don't think anyone here would be surprised that DNS lookup would do odd things if two different computers had the same DNS name. This, after all, is the basis for DNS spoofing attacks on internet protocols

So it's a known issue. How about I promise to fix it before Beyonwiz issues a fix

There are issues in fixing this that are easy to get around in a GUI that are more difficult to do in a command-line interface, especially to retain consistent naming between runs of getWixPnP. I am, as you guessed, indexing by name. It would be easy to call the two BWs found "Beyonwiz DP-S1-1" and "Beyonwiz DP-S1-2", but you wouldn't want the association of the two names changing between runs of getWIzPnP. I think I know how to fix it, but in the meantime, it's just going to go into the bug list.

I'm not sure why it only ever finds two of your units when there are two different names. Have you tried increasing the timeout, with --wizpnpTimeout=3, for example? That will give a total 9-second timeout; try trimming back from there. There are also some simple discovery test scripts in the distribution directory.

In the meantime, as with the Beyonwiz implementation on the Beyonwiz, I suggest that as a workaround, use different names for different devices.

IanSav · Post by **IanSav** » Sun Jan 18, 2009 14:16

Hi Peter,

I think you would solve the issue permanently if you use the name, IP address and port number as a complex key into your data. This can *never* go wrong as you are never dependant on the whims of people putting strange or identical data into the WizPNP name field. The IP address and then the port number would force every device discovered to be unique regardless of what is (or isn't) in the name field. WizFX appears to do this now and doesn't have an issue with the all devices now connected here. WizFX lists the devices sorted by name then IP then port number.

I am still confused why "getWizPnP --discover" only finds and list 1 unit at a time. Shouldn't the two unique devices out of the three available be listed?

Regards,
Ian.

prl · Post by **prl** » Sun Jan 18, 2009 14:42

IanSav wrote:Hi Peter,

I think you would solve the issue permanently if you use the name, IP address and port number as a complex key into your data. This can *never* go wrong as you are never dependant on the whims of people putting strange or identical data into the WizPNP name field. The IP address and then the port number would force every device discovered to be unique regardless of what is (or isn't) in the name field. WizFX appears to do this now and doesn't have an issue with the all devices now connected here. WizFX lists the devices sorted by name then IP then port number.

I am still confused why "getWizPnP --discover" only finds and list 1 unit at a time. Shouldn't the two unique devices out of the three available be listed?

Regards,
Ian.

Try --maxdevs=3 or --maxdevs=0 (exhaustive search). On your setup, this should find two devices, but the device found for the two devices with the same name will be the first responder.

Maxdevs is the maximum number of devices getWizPnP will try to find. It should noramally be set to the number of Beyonwizes on your network, or zero. It defaults to 1, which I think is correct for most people. The behaviour is documented in The Fine Manual:

maxdevs

--maxdevs=devs
-D devs

In a WizPnP search, stop searching when the number of WizPnP devices found is devs, rather than waiting for the search to time out (currently 9 seconds). Devs defaults to 1. If set to zero, there is no limit; the search continues looking for devices until it times out.

I know how to distinguish between BWs with the same name in the code. What I want to have is a short way of doing it in the command line that's consistent from run to run. I don't want the user to have to enter --device=MyBeyonwiz-10.1.1.3-49152 to distinguish the device. As I said, this is a problem that's easy to do in a GUI (as in WizFX), and easy to forget the need to do (getWizPnP and the Beyonwiz device client). What I want to do is generate names line MyBeyonwiz-1 and MyBeyonwiz-2 where more than one device responds with the same name, and to have it consistent, at least while the IP addresses and port numbers stay the same. As I said, I promise to fix this before Beyonwiz release a fix for the device client.

In the meantime, there's a simple workaround. Rename one of the devices. This will mean that streaming between them will work properly, too.

IanSav · Post by **IanSav** » Sun Jan 18, 2009 14:58

Hi Peter,

prl wrote:Try --maxdevs=3 or --maxdevs=0 (exhaustive search). On your setup, this should find two devices, but the device found for the two devices with the same name will be the first responder.

Maxdevs is the maximum number of devices getWizPnP will try to find. It should noramally be set to the number of Beyonwizes on your network, or zero. It defaults to 1, which I think is correct for most people. The behaviour is documented in The Fine Manual:
maxdevs

--maxdevs=devs
-D devs

In a WizPnP search, stop searching when the number of WizPnP devices found is devs, rather than waiting for the search to time out (currently 9 seconds). Devs defaults to 1. If set to zero, there is no limit; the search continues looking for devices until it times out.

That fixed it. Now 2 units are being found. I used the 0 option as it does its job fast enough and I will never trip over having the search limited again.

prl wrote:I know how to distinguish between BWs with the same name in the code. What I want to have is a short way of doing it in the command line that's consistent from run to run. I don't want the user to have to enter --device=MyBeyonwiz-10.1.1.3-49152 to distinguish the device. As I said, this is a problem that's easy to do in a GUI (as in WizFX), and easy to forget the need to do (getWizPnP and the Beyonwiz device client). What I want to do is generate names line MyBeyonwiz-1 and MyBeyonwiz-2 where more than one device responds with the same name, and to have it consistent, at least while the IP addresses and port numbers stay the same. As I said, I promise to fix this before Beyonwiz release a fix for the device client.

In the meantime, there's a simple workaround. Rename one of the devices. This will mean that streaming between them will work properly, too.

I can't (won't) rename a device that doesn't belong to me. I like the name I chose for my unit.

If the name matching algoritm used a minimum unique approach then the full name entered and indexed by the program could be the fully distinguished name (name+IP+port) but the user need only enter enough of the name on the command line to uniquely identify the device. Thus under normal circumstances the name would be enough unless there are duplicate names in which case more of the name, like the IP, would also be required. If there were ever two services on the same Beyonwiz then you would need to go further and also specify the port.

These are just suggestions. I would like to help make the program work no matter how simple or complicated the environment is.

Regards,
Ian.

Gully · Post by **Gully** » Sun Jan 18, 2009 15:02

Ian

I think you are making it unduly complicated for a rather unique situation.

Most people with more than one Wiz would be happy to change the name as long as people are aware of the issue.

IanSav · Post by **IanSav** » Sun Jan 18, 2009 15:09

Hi Gully,

Gully wrote:I think you are making it unduly complicated for a rather unique situation.

Most people with more than one Wiz would be happy to change the name as long as people are aware of the issue.

This is exactly my point. The defaults should work out any environment and just work.

The fact that I needed to set maxdevs to make the program work properly is just wrong. The program failed when it didn't need to. Yes, people could make it go faster if they force a maximum search of 1 device but the default should be to find what ever is out there. Don't assume the person has only one unit. Functionality and reliability should be the first priority, speed and optimisation should come next.

Regards,
Ian.

Gully · Post by **Gully** » Sun Jan 18, 2009 15:20

IanSav wrote:This is exactly my point. The defaults should work out any environment and just work.

The fact that I needed to set maxdevs to make the program work properly is just wrong. The program failed when it didn't need to. Yes, people could make it go faster if they force a maximum search of 1 device but the default should be to find what ever is out there. Don't assume the person has only one unit. Functionality and reliability should be the first priority, speed and optimisation should come next.

I think that is a fair point though my post was clearly about the issue of naming for WizPnP which I don't think needs to be addressed by getWizPnP.

prl · Post by **prl** » Sun Jan 18, 2009 15:54

IanSav wrote:Hi Peter,
...
If the name matching algoritm used a minimum unique approach then the full name entered and indexed by the program could be the fully distinguished name (name+IP+port) but the user need only enter enough of the name on the command line to uniquely identify the device. Thus under normal circumstances the name would be enough unless there are duplicate names in which case more of the name, like the IP, would also be required. If there were ever two services on the same Beyonwiz then you would need to go further and also specify the port.

These are just suggestions. I would like to help make the program work no matter how simple or complicated the environment is.

Regards,
Ian.

I'll probably end up assigning names made up from the device name and the host part of the net.subnet.host address where there are multiple devices with the same name. The search is set up not to go past routers (TTL=1), so that should work until someone develops a PC-based WizPnP server where multiple instances can run on the same machine. Perhaps the port can be added only if it's not the default 49152. That's a bit of a pain, too, because port numbers on the Beyonwiz device server have to be 1024 and above.

It all seems to me to be a lot of bother for what, in my opinion, is a misconfiguration.

This problem is now listed in the Bugs section of the release notes.

IanSav · Post by **IanSav** » Sun Jan 18, 2009 20:39

Hi Gully and Peter,

While you are free to consider my setup a misconfiguration I do think that the program should be coded defensively and cope with any possible configuration that may be out there. Remember that the default WizPNP name used by Beyonwiz will be the same for all devices so that any naive user who purchases more than one unit and doesn't change the defaults will end up in exactly the same position I am in now. A naive user is going to be less able to work out the issue and solve it themselves, they are going to need support. If the program works all the details out itself then there will be no issue and no need for support.

I strongly recommend defencive programming.

Regards,
Ian.

prl · Post by **prl** » Sun Jan 18, 2009 21:48

I didn't say I wasn't going to change the code. Indeed, I've already said that I will, and I'm sure I can make good my promise that I will have a fix before Beyonwiz can deliver a fix on essentially the same limitation in the Beyonwiz device client.

I still think that multiple devices with the same name is a misconfiguration.

As for maxdevs, I think that the setting of 1 was the correct choice when the default search timeout was long. Now that it's a little less than a second, an exhaustive setting as the default is probably better, and that will be what I do in the next release provided the search timeouts can stay about the same.

The maxdevs beheviour is, as I said before, documented.

I recommend defensive spelling

madmax · Post by **madmax** » Sun Jan 18, 2009 22:15

prl wrote:I recommend defensive spelling

Did you find Ian's spelling offensive?

IanSav · Post by **IanSav** » Sun Jan 18, 2009 23:46

Hi,

I blame ieSpell for any and all spelling mistakes.

Sometimes I pick up when it makes mistakes or goes back to its American roots but sometimes I bugger up or just forget to recheck.

Regards,
Ian.

dg · Post by dg » Mon Jan 19, 2009 04:48

madmax wrote:
prl wrote:I recommend defensive spelling
Did you find Ian's spelling offensive?

I didn't find it offencive!

DG

prl · Post by **prl** » Mon Jan 26, 2009 17:40

I'm currently coding the transfer of media files from the contents folder in getWizPnP.

Currently, the code ignores whether recordings/media files are in the contents folder or in the recording folder.

The advantage of this is that the interface remains unchanged, but the contents of all folders on either side will be "folded" together. They will still be distinguishable, because media files have an extension to say what media type they are (.mpg, .wmv, etc). This means that if you only have recordings in the recording folder, then the code changes will be invisible.

An alternative is to have that upper level of folder hierarchy appear in getWizPnP's interface, and perhaps have the default search folder be 'recording'. That would mean that the behaviour of getWizPnP would be unchanged if no folders are specified, but now instead of specifying '--folder=Movies' to get recordings in recording/Movies, you'd have to specify '--folder=recording/Movies', but it would be distinct from '--folder=content/Movies'. To see all recordings and content, you'd use '--folder= --all'.

So, any preferences? Alternatives?

There was earlier discussion about whether the device search should continue to default to just look for the first device found, or should it always do an exhaustive device search; and what to do if the user gave Beyonwiz devices the same name as each other, for example by leaving them all (mis)configured with the default name "beyonwiz".

In the first case, the default search is now exhaustive, rather than stopping after finding one device. The rationale for stopping at the first device is that most people only have one WizPnP server, and the search timeout was long. The search timeout is now 0.9sec, so an exhaustive search now completes quickly enough that there's no reason to avoid it.

In the second case, I'm proposing to always give each device a unique name derived from the WizPnP name, its host address on the network (so if the IP address is 10.1.1.4 and the netmask is 255.255.255.0, the host address is 4), and the WizPnP port number. So if there were two WizPnP servers with default WizPnP settings, one at 10.1.1.4 and one at 10.1.1.5 (netmask 255.255.255.0) with the default WizPnP settings their names would be beyonwiz-4-49152 and beyonwiz-5-49152. They could be referred to in the --device option by the shortest minimum unique prefix: for example '--device=beyonwiz-4'. I think that this is more-or-less along the lines that IanSav suggested. The names would always be in this expanded form, even if only one of the devices with the same name is actually on the network, so that the name of the machine remains the same.

For the technically minded, the host address is sufficient to identify the IP address, because the search discovery multicast has TTL=1, which means that it will not pass from one (sub)network to another in a router, so all responders will have the same (sub)network address as the machine running the request.

The port number is added as a precaution against a future possibility that a non-Beyonwiz WizPnP server might be written, and it may be possible for a single machine to run multiple WizPnP services on different ports. I'm not convinced that this is necessary (at least not yet).

My personal feeling is that this is an ugly solution to what I view as a network misconfiguration, and I think that it would be better handled by making the configuration issue more obvious in the documentation.

In particular, I think it could be confusing for people using DHCP with dynamically-assigned addresses, because the names would change each time the IP addresses were reassigned.

This has not yet been coded, though it's not difficult to do. I'm happy to hear any comments about it, especially ones that say "Just don't do it"

IanSav · Post by **IanSav** » Mon Jan 26, 2009 20:48

Hi Peter,

Just do it!

This is defensive programming and will avoid future problems if the expansion scenarios come into being.

As for the folder question, I suggest that you observe and propagate the folder structure. This will avoid all the issues if people have contents with the same file name in different folders.

Regards,
Ian.

peteru · Post by **peteru** » Tue Jan 27, 2009 12:35

The host/port appended seems like an ugly hack to me. As far as I am concerned, the behaviour should be similar to DNS.

Your application should perform a single discovery at the start of a run and remember the name to address mapping for the remainder of that execution. If one name resolves to multiple addresses, you should use the first response and ignore the others - this is exactly the same as round robin / load balanced DNS.

If you feel that it is important to deal with misconfigured networks (multiple devices with same name), then I would suggest that you print a warning for any duplicates. (It may be possible to have a dual homed configuration, where the same device is visible from different interfaces.)

At the end of the day, the device name is only a user visible label that should play no role in the network traffic portion of the application. The key used for all the lookups should be ip_addr:port, not the device name.

P.S. - For slightly better predictability, you could have a policy that always selects the lowest numbered ip_addr:port in cases where you get name collisions.

IanSav · Post by **IanSav** » Tue Jan 27, 2009 19:37

Hi PeterU,

I think it is important for the software to deal with units with the same name. Pragmatically this is not hard to do and the UI can be made to cope without making things to difficult. In fact, if the names are all assigned correctly then the UI would show no difference at all to what it does now. The name extensions that Prl suggested only come into play if duplicates are found..

Regards,
Ian.

prl · Post by **prl** » Tue Jan 27, 2009 20:06

IanSav wrote:Hi PeterU,

I think it is important for the software to deal with units with the same name. Pragmatically this is not hard to do and the UI can be made to cope without making things to difficult. In fact, if the names are all assigned correctly then the UI would show no difference at all to what it does now. The name extensions that Prl suggested only come into play if duplicates are found..

Regards,
Ian.

As I said, I'm not at all happy with that solution, like peteru, I think it's an ugly hack. I'm inclining more toward what peteru suggested (and I'd been thinking of something like it before he posted).

As for the "defensive programming", that's perfectly well covered by an error message that says that the devices should be named differently.

I still think that units named the same is a configuration error.

IanSav · Post by **IanSav** » Tue Jan 27, 2009 21:07

Hi Peter,

I am far to tired to argue the merits of this. At least I don't have to deal with complaints and problems when issues crop up. I believe that it is the computers that should do the hard work and not the users. I was trying to offer suggestions that make life easier for everyone at the cost of a little extra programming.

It will probably mean I will stick with WizFX which appears to handle all identity cases without issue.

Regards,
Ian.

tonymy01 · Post by **tonymy01** » Tue Jan 27, 2009 22:10

I thought it didn't? Didn't someone say that it was one minute showing files on one unit while trying to initiate downloads on the other?
Regards

IanSav · Post by **IanSav** » Tue Jan 27, 2009 22:38

Hi Tony,

tonymy01 wrote:I thought it didn't? Didn't someone say that it was one minute showing files on one unit while trying to initiate downloads on the other?

I made the original observation. WizFX always got the list right. It was a Beyonwiz DP-P1 in client mode that got it wrong. As it turned out the firmware, at the time of the tests on that DP-P1, was quite old. I can't re-test now as all the other Beyonwiz units are back with their original owners.

Regards,
Ian.

getWizPnP - a command-line WizPnP uploader

About the Forum

Join us