getWizPnP - a command-line WizPnP uploader

Advanced Discussions on Programing for & Modifying Beyonwiz Products.

Moderators: Gully, peteru

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Post by IanSav » Wed Jan 28, 2009 09:26

Hi Peter,
prl wrote:As for dealing with the complaints from users that IanSav alluded to, I think that he's the only one to complain about this so far. :)
How many people have 3 Beyonwiz units at their disposal? How many of them are using getWizPnP? ;)

I offered my comments and advice as a courtesy to try and help make the application more bulletproof of real world situations. It currently isn't often that you get people with so many units in the one place on the one network at the same time. While there may not currently be many people with multiple Beyonwiz units I expect that DPG and Beyonwiz hope this situation will change. :) I was hoping that you would preempt any potential issues.

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Wed Jan 28, 2009 09:41

Hi, Ian.

So far, you've been the only one with more than one Beyonwiz with the same name to use getWizPnP and comment on this problem. You also decided that changing the name of one of the units wasn't a viable option, because they weren't yours.

If I follow peteru's suggestion, getWizPnP will suggest that devices are renamed if it finds multiple units with the same names. It will also support WizZilla in allowing access to devices with the same name, but that's a decision that's up to Dave? and alwayslooking.

I do appreciate the fact that you let me know about the problem, and that you've put forward a possible solution. I'm simply in a position where I don't really like any of the solutions suggested so far.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
tonymy01
Uber Wizard
Posts: 6373
Joined: Fri Jun 01, 2007 15:25
Location: Sydney, Australia DP-S1-1TB, DP-P2-2TB, DP-T4-2TB, DP-T4-BB... too many!
Contact:

Post by tonymy01 » Wed Jan 28, 2009 11:22

I should read PeterU's message again, but didn't he then suggest that access to the device should always be via the IP address and not the arbitrary name, in which case you can deal with two devices just fine, and it is simply the nice presentation of the information/device name listing showing the name rather than IP address that will cause end user ambiguity?
Regards
Tony

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Wed Jan 28, 2009 12:52

tonymy01 wrote:I should read PeterU's message again, but didn't he then suggest that access to the device should always be via the IP address and not the arbitrary name, in which case you can deal with two devices just fine, and it is simply the nice presentation of the information/device name listing showing the name rather than IP address that will cause end user ambiguity?
Regards
On re-reading peteru's suggestion, there's a bit that I'm not sure I understand, and it's
peteru wrote: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.
It's always been possible to tell getWizPnP to connect to a device at a specific IP,port address. In fact, that used to be the only way that getWizPnP worked under Windows.

The way that it currently works is like this:
  • getWizPnP (or any other WizPnP client) asks: Are there any WizPnP servers out there?
  • All the WizPnP servers respond with a packet that contains (among other stuff): My name is X and my presentationUrl is http://my.bw.ip.ad:port/index.txt.
  • getWizPnP waits until it has received maxdevs responses, or if maxdevs is 0, it waits until it's timed out (currently the default --wizpnpTimeout=0.3 sec).
  • The above is repeated up to --wizpnpPoll=3 times, or until maxdevs devices have responded.
  • Each response is stored in an associative array indexed by the device's name in the response packet (which is taken from SETUP>Network>WizPnP>Name, and which defaults to 'beyonwiz') if there isn't already an entry in the array under that name.
If there is more than one entry in the array, the user must specify which device they want to use using the --device option. When getWizPnP connects to the device it uses the scheme and login parts of the presentationUrl to establish the connection, so no further ambiguity is introduced here.

This gives peteru's initial suggested behaviour:
peteru wrote: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
The problem with this (and recognised later in peteru's post), is that the first response for a particular name doesn't necessarily come from the same device on each run of getWizPnP, so if you do a --list operation, and select a recording, and then do a --delete operation on the same device name, the second operation might be attempted on a different device from the first, because different devices with the same name may have responded first.

So, peter suggested:
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
If I use peter's suggestion (his first part is what getWizPnP already does), then I will implement this, too.

I will also implement this part of peter's suggestion:
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
If I implement it this way, the result of doing a --discover on a network with devices "DP-S1" (10.1.1.2:49152), "DP-S1" (10.1.1.3:49152) and "DP-H1" (10.1.1.4:12345) will be something like:

Code: Select all

DP-S1    10.1.1.2:49152
DP-S1    10.1.1.3:49152 Duplicate device name: not accessible
DP-H1    10.1.1.4:12345
The list will be ordered by name, than IP address, then port number. This gives the WizZilla authors the option of only using the first (or any entry) for each name, or using all discovered devices.

getWizPnP is a command-line tool, not GUI-based, so that some things that are simple and natural to do in a GUI can be ugly and inconvenient to do from the command line.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Post by peteru » Wed Jan 28, 2009 13:44

prl wrote:Each response is stored in an associative array indexed by the device's name in the response packet (which is taken from SETUP>Network>WizPnP>Name, and which defaults to 'beyonwiz') if there isn't already an entry in the array under that name.
An alternative approach may be to only allow specifying devices using (ip_addr|hostname):[port] and ignore the name. You would then implement a separate discovery command that generates a list of "ip_addr:port-name" mappings. Any UIs that wish to list the devices by name could still do so, but the underlying addressing would still use the full device address.

I see very little value in using the WizPnP protocol to perform name resolution at the network level. The PVR name is purely a cosmetic label, it really has no network level function.

"Beauty lies in the hands of the beer holder."
Blog.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Post by IanSav » Wed Jan 28, 2009 15:26

Hi,

I think PeterU is experessing my thoughts better than I did. :)

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Wed Jan 28, 2009 15:29

peteru wrote:
prl wrote:Each response is stored in an associative array indexed by the device's name in the response packet (which is taken from SETUP>Network>WizPnP>Name, and which defaults to 'beyonwiz') if there isn't already an entry in the array under that name.
An alternative approach may be to only allow specifying devices using (ip_addr|hostname):[port] and ignore the name. You would then implement a separate discovery command that generates a list of "ip_addr:port-name" mappings. Any UIs that wish to list the devices by name could still do so, but the underlying addressing would still use the full device address.

I see very little value in using the WizPnP protocol to perform name resolution at the network level. The PVR name is purely a cosmetic label, it really has no network level function.
There is already a command-line option to generate a list of IP/port address to WizPnP name mappings (--discover). At the moment, though, it only allows for unique names. What I described above as the function of --discover is an extension, not an entirely new function. If you know the IP address and port number, getWizPnP already allows you to specify them as an alternative to the search. If --host is used in the command line no search is done.

I think that the WizPnPname is a convenient shorthand, especially when a large proportion of users haven't set up their systems to give names to their Beyonwiz devices via /etc/hosts or similar. A number of users wanted to be able to be use the WizFX name. That's why I've spent some effort in getting it device search working across as many platforms as I can to allow the use of the WizPnP name to select devices in getWizPnP. It's also why I've asked for suggestions about how name conflicts can best be resolved or worked around.

I agree that the WizPnP name is not a network level function, but then neither is DNS (in the ISO stack). The WizPnP name is more presentation layer. It's used as the main identification of devices in the Beyonwiz device client and in WizFX, and I think that getWizPnP should fully support the naming of the device using it where it's unambiguous.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
DaveR
Wizard
Posts: 2527
Joined: Tue May 29, 2007 01:24
Location: Sydney

Post by DaveR » Sat Jan 31, 2009 17:40

IanSav wrote:It will probably mean I will stick with WizFX which appears to handle all identity cases without issue.
Actually it doesn't. Someone (you?) mentioned a problem when more than one wiz had the same wizpnp name where wizfx only showed the files from one of them, and it kept switching between (getting confused by) the two wizzes.

I recently saw wizfx get very confused when there were 2 wizzes on the LAN with the same IP (!?!?!). One wiz had a user set IP and another had been assigned the same IP by the DHCP server (!?!?). The only reason I could tell that there were 2 wizzes with the same IP on the LAN was because the files being listed by wizfx as being from a wiz with that IP were not the same file list that I was looking at on the TV screen from the wiz that I knew had that IP. IMHO the DHCP server should never have assigned the same IP to a second device... but whoever manually set the IP should also have never used an IP within the range of IPs controlled by the DHCP server. Or better yet, set this IP as fixed to that particular wiz's MAC address within the router's admin settings.

I'm not sure exactly what wizfx is doing now... but for the 'fixed IP wiz' it is showing 3(!) files as currently recording and has done so for a few days now. It also shows some epg.000, epg.001 and epg.002 files in the file list. Both of these issues are probably a problem with this particular wiz's index file rather than wizfx itself.

IMHO all getwizpnp needs to do in cases of duplicate wizpnp names (or IPs if it can detect such a thing) is to warn the user. An incorrectly configured network should never be worked around by software. Instead the error condition should reported to the user so that the user can correct the problem. But the only thing that matters is the IP and port numbers.

EDIT: Added missing word to sentence above (that completely changed the meaning!)
Last edited by DaveR on Sat Jan 31, 2009 18:59, edited 1 time in total.
cheers
DaveR

IceTV, T4, T3, T2, P2, S1, FV-L1(P1 fw), TRF-2460, HDR-7500 and Skippa

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Post by IanSav » Sat Jan 31, 2009 18:43

Hi Dave,
Dave? wrote:Actually it doesn't. Someone (you?) mentioned a problem when more than one wiz had the same wizpnp name where wizfx only showed the files from one of them, and it kept switching between (getting confused by) the two wizzes.
See my post earlier in this thread ( http://www.beyonwiz.com.au/phpbb2/viewt ... 8169#48169 ). The DP-P1 running old firmware had the issue. WizFX was fine.
Dave? wrote:I recently saw wizfx get very confused when there were 2 wizzes on the LAN with the same IP (!?!?!). One wiz had a user set IP and another had been assigned the same IP by the DHCP server (!?!?). The only reason I could tell that there were 2 wizzes with the same IP on the LAN was because the files being listed by wizfx as being from a wiz with that IP were not the same file list that I was looking at on the TV screen from the wiz that I knew had that IP. IMHO the DHCP server should never have assigned the same IP to a second device... but whoever manually set the IP should also have never used an IP within the range of IPs controlled by the DHCP server. Or better yet, set this IP as fixed to that particular wiz's MAC address within the router's admin settings.
Duplicate IPs is a fatal network flaw that must be fixed. No default or automated system will ever do this. The error is caused by a user forcing a fixed IP that is incorrect.
Dave? wrote:IMHO all getwizpnp needs to do in cases of duplicate wizpnp names (or IPs if it can detect such a thing) is to warn the user. An incorrectly configured network should never be worked around by software. Instead the error condition should reported to the user so that the user can correct the problem. But the only thing that matters is the IP and port numbers.
Duplicate IPs is an unresolvable network flaw. Duplicate device names is easily resolved with some simple programming. WizFX appears to cope very well with duplicated device names.

Regards,
Ian.

User avatar
DaveR
Wizard
Posts: 2527
Joined: Tue May 29, 2007 01:24
Location: Sydney

Post by DaveR » Sat Jan 31, 2009 19:09

Hi Ian,
IanSav wrote:WizFX appears to cope very well with duplicated device names.
The only reason that wizfx copes with duplicate names is because I believe that (after wizfx insists that each wiz's wizpnp name is not null) it then totally ignores the name. For each wizpnp server found by wizfx the user is shown the following:

- WizPNP name (for user's info only)
- IP address
- WizPNP port

I assume, without having read the source, that when the user clicks on one of these "Name, IP, Port" entries that WizFX then uses only the IP address and Port number for all interaction with the selected wiz.
cheers
DaveR

IceTV, T4, T3, T2, P2, S1, FV-L1(P1 fw), TRF-2460, HDR-7500 and Skippa

User avatar
DaveR
Wizard
Posts: 2527
Joined: Tue May 29, 2007 01:24
Location: Sydney

Post by DaveR » Sat Jan 31, 2009 19:52

prl wrote: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?
I prefer the 2nd method. Partly because it can be used either way, but mostly because we can then specify the folder specifically.

The 1st method would be extremely annoying for users with many, many files.
cheers
DaveR

IceTV, T4, T3, T2, P2, S1, FV-L1(P1 fw), TRF-2460, HDR-7500 and Skippa

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 01, 2009 08:01

Dave? wrote:Hi Ian,
IanSav wrote:WizFX appears to cope very well with duplicated device names.
The only reason that wizfx copes with duplicate names is because I believe that (after wizfx insists that each wiz's wizpnp name is not null) it then totally ignores the name. For each wizpnp server found by wizfx the user is shown the following:

- WizPNP name (for user's info only)
- IP address
- WizPNP port

I assume, without having read the source, that when the user clicks on one of these "Name, IP, Port" entries that WizFX then uses only the IP address and Port number for all interaction with the selected wiz.
Yes. My question has never been about whether an individual WizPnP server can be found and uniquely addressed despite name collisions; it obviously can be. My question is about whether this can be done in a way that is simple to use from a command-line interface. I don't think I've seen a suggestion that I feel is simple enough, is consistent no matter how many of the devices with colliding names are active, and that doesn't unnecessarily clutter things when unique names are used for the servers.

I've pretty much determined that if there are name collisions, getWizPnP will issue a warning, and always address the lowest IP address of the devices with the same name. It doesn't meet all the consistency criteria I mentioned, but it does most of them, and is simplest to use when there are no name collisions. I will add IanSav's suggestion that the shortest unique name prefix should be usable in --device, because that's a good idea anyway.

The output of the --discover option will list all devices found even where there are name collisions so that independent decisions can be made by the Two Wizards about how this problem can be addressed in WizZilla.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 01, 2009 08:03

Dave? wrote:...
I prefer the 2nd method. Partly because it can be used either way, but mostly because we can then specify the folder specifically.

The 1st method would be extremely annoying for users with many, many files.
Yes, I think that's how I'll go (with 'recording' as the default folder). I may also add folder names to --list where --all isn't used.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Tue Feb 17, 2009 07:37

Hi Peter

I am using the following command to return recording names

getwizpnp.pl --device=Fish_Room_BW --maxdevs=5 --List

ite returns a list containg

Seven News Feb.16.2009_17.59

Then I use that name a sbelow

getwizpnp.pl --device=Fish_Room_BW --maxdevs=5 --delete --BWName "Seven News Feb.16.2009_17.59" -v 4

However it just get

Searching for at most 5 devices
Connecting to Fish_Room_BW (192.168.0.152:49152)

and the file is not deleted

In one case it worked after many attempts with same command line.

Any ides what I am doing wrong (It is latest build 1.3.4)
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Tue Feb 17, 2009 09:02

craigh wrote:Hi Peter

I am using the following command to return recording names

getwizpnp.pl --device=Fish_Room_BW --maxdevs=5 --List

ite returns a list containg

Seven News Feb.16.2009_17.59

Then I use that name a sbelow

getwizpnp.pl --device=Fish_Room_BW --maxdevs=5 --delete --BWName "Seven News Feb.16.2009_17.59" -v 4

However it just get

Searching for at most 5 devices
Connecting to Fish_Room_BW (192.168.0.152:49152)

and the file is not deleted

In one case it worked after many attempts with same command line.

Any ides what I am doing wrong (It is latest build 1.3.4)
Strange. Have you had problems with deletion using the normal program title, or only when you use --BWName; and is this the only recording you've had problems with, or has it happened with others?

PS: If you want to do an exhaustive search of your devices, you can use --maxdevs=0. In the next release, that will be the default. You can use the config file (see the FILES section of the documentation) to change a lot of the default behaviour of getWizPnP if you don't like my choices.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Tue Feb 17, 2009 09:38

prl wrote:
craigh wrote:Hi Peter

I am using the following command to return recording names

getwizpnp.pl --device=Fish_Room_BW --maxdevs=5 --List

ite returns a list containg

Seven News Feb.16.2009_17.59

Then I use that name a sbelow

getwizpnp.pl --device=Fish_Room_BW --maxdevs=5 --delete --BWName "Seven News Feb.16.2009_17.59" -v 4

However it just get

Searching for at most 5 devices
Connecting to Fish_Room_BW (192.168.0.152:49152)

and the file is not deleted

In one case it worked after many attempts with same command line.

Any ides what I am doing wrong (It is latest build 1.3.4)
Strange. Have you had problems with deletion using the normal program title, or only when you use --BWName; and is this the only recording you've had problems with, or has it happened with others?

PS: If you want to do an exhaustive search of your devices, you can use --maxdevs=0. In the next release, that will be the default. You can use the config file (see the FILES section of the documentation) to change a lot of the default behaviour of getWizPnP if you don't like my choices.
Hi Peter

I tried it against my S1 and P1 and had problems with both. But I did get one to delete on the P1 using BWName.

Have only tried BWName as It seems to be best for absolute names.

I only added maxdevs as it was not finding the server one in every 2 times.

Will play a bit more with other files and see if its consistant.
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Tue Feb 17, 2009 10:08

craigh wrote:...
Hi Peter

I tried it against my S1 and P1 and had problems with both. But I did get one to delete on the P1 using BWName.

Have only tried BWName as It seems to be best for absolute names.

I only added maxdevs as it was not finding the server one in every 2 times.

Will play a bit more with other files and see if its consistant.
Anything that helps me reproduce the problem will be enormously helpful. 0.4 is in alpha release, and if we can find out what's causing the problem, I can probably get a fix into the next release (which allows you to access the content folder as well as the recordings folder).

The default is --maxdevs=1, which means that if you don't use --maxdevs, getWizPnP should never find more than one device even if there is more than one accessible. Which one it finds will be random (it returns the first responder to the search request). You should never need to set --maxdevs to any more than the number of BWs that are currently accessible. If you set it to less, you get a random selection of the ones that are there. If you set it to 0, you should always get all of them, but the search will take 0.9 sec to time out. If that doesn't work, the parameters to tweak are --wizpnpPoll and --wizpnpTimeout.

--maxdevs=0 is the default in version 0.4.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Tue Feb 17, 2009 16:05

Hi Peter

Did a bit more testing with copy and all files worked except the seven news one

Went back and tried delete again with ' or " surrounds and a few other things withy no luck.

then went to BW and wnt to file player and seven news was still there but is selected came up with a media error then unsupported format.

Did a disk check and it was fixed - as it was gone.

I wonder if delete and 183 dont go well together.
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Tue Feb 17, 2009 16:31

craigh wrote:Hi Peter

Did a bit more testing with copy and all files worked except the seven news one

Went back and tried delete again with ' or " surrounds and a few other things withy no luck.

then went to BW and wnt to file player and seven news was still there but is selected came up with a media error then unsupported format.

Did a disk check and it was fixed - as it was gone.

I wonder if delete and 183 dont go well together.
183! Don't get me started on 183! (:) there, that's better :))

The problem generally with delete (and as a consequence move) is that I'm using part of the WizPnP mechanism that isn't intended to be used. getWizPnP can delete the files that make up the recording on the Beyonwiz, but the Beyonwiz firmware doesn't "know" that the files have been deleted.

On firmware before 183, these were the problems that delete was known to cause:
getWizPnP documentation wrote:--move and --delete use undocumented features of WizPnP. This has a number of consequences:
  • A recording can be deleted while it is being played on the Beyonwiz. Normally, the playback will simply finish abruptly. The same happens if getWizPnP deletes a recording on the WizPnP server while another Beyonwiz is playing the recording remotely using WizPnP.
  • If the Beyonwiz is displaying the name of the deleted recording in the file player when it is deleted, the file player view won't be updated. Navigating away from that folder and back again will display the folder correctly again.
  • The WizPnP's index of recordings (see --index) on the Beyonwiz doesn't get updated when the recording on the Beyonwiz is deleted (directly or after the copy for a move). If you view the recordings on the Beyonwiz using WizFX, entries for deleted recordings appear in the WizFX list of recordings. These entries have no name, a date of 17/11/1858, and a size of 256kB. They can't be copied using WizFX. A recording deleted using getWizPnP on a Beyonwiz WizPnP server will appear normal in the file player on a Beyonwiz WizPnP client, but the recording cannot be played.
Problems caused by errors in the WizPnP index can be fixed by either starting a recording on the Beyonwiz, or by shutting it down to standby, then restarting it.
In 183, the second dot point changes to simply: "Recordings deleted by getWizPnP remain in the FilePlayer index. If you try to play them you get the error an error indicating that the recording file doesn't exist." I haven't tested the other dot points, but I can't think why they've changed.

The workaround becomes: "The Beyonwiz index of media & recordings will be updated and the inconsistencies mentioned will be fixed if you run a HDD check, for example from SETUP>System>Hdd>Check HDD."

I'm still a bit puzzled by your original description of the problem, because the first time you tried to do the delete the recording should have printed at least the recording name and "- Delete".

These bugs are there for any successful delete or move operation, not just with --BWName. The bugs can only be fixed by changes in the firmware.

The changes in the behaviour in 183 are due to changes in the way that the Beyonwiz handles the maintenance of its internal index over the media & recording data.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Tue Feb 17, 2009 17:09

Hi Peter I agree

In my testing the delete failed numerous times against 180 P1 and then worked.

on 283 i dont recall ever seeing the success from getwizpnp but one of the test must have worked.

I was probably confused as on the P1 (280) when i opened file manager the file was gone, on 283 it was not.

If the BW cant recover from the delete easily on 283 that makes its use a bit unclean, shame.

I have written a UI to manage both my BW's and NAS so I will be doing lots more testing.
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Tue Feb 17, 2009 17:43

Hi Craig. Can we call this one "probably explained", then?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Thu Feb 19, 2009 18:57

prl wrote:
craigh wrote:...
I wonder if delete and 183 dont go well together.
...
The workaround [for the deleted recording still being visible in the FilePlayer] becomes: "The Beyonwiz index of media & recordings will be updated and the inconsistencies mentioned will be fixed if you run a HDD check, for example from SETUP>System>Hdd>Check HDD."
...
A recent post by Hanjo in the Beta forum indicated that there should be a simpler way of doing this, and there is: in the FilePlayer, press the Soundtrack button on the remote (the speaker/question mark button). That starts a rebuild of the index, and just rebuilding the index doesn't need to stop recordings as Check HDD does.

NB: this discussion only refers to firmware version 01.05.183 beta (and probably later).
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Thu Feb 19, 2009 19:09

prl wrote:
prl wrote:
craigh wrote:...
I wonder if delete and 183 dont go well together.
...
The workaround [for the deleted recording still being visible in the FilePlayer] becomes: "The Beyonwiz index of media & recordings will be updated and the inconsistencies mentioned will be fixed if you run a HDD check, for example from SETUP>System>Hdd>Check HDD."
...
A recent post by Hanjo in the Beta forum indicated that there should be a simpler way of doing this, and there is: in the FilePlayer, press the Soundtrack button on the remote (the speaker/question mark button). That starts a rebuild of the index, and just rebuilding the index doesn't need to stop recordings as Check HDD does.

NB: this discussion only refers to firmware version 01.05.183 beta (and probably later).
Thats interesting

Was it added to the button for a reason. ?

I would not mind it to be added to a new remote id that has no UI action ( like sound) so you could program it before any press of the file player button. That would hide it completely.

If you have a universal remote that is.
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Thu Feb 19, 2009 19:15

craigh wrote:...
Thats interesting

Was it added to the button for a reason. ?

I would not mind it to be added to a new remote id that has no UI action ( like sound) so you could program it before any press of the file player button. That would hide it completely.

If you have a universal remote that is.
I guess it was added for a reason :) but I don't know for sure what the reason is. There have been some bugs in the beta (as you know), where the index wasn't updated correctly after some fileplayer file operations, and the button is useful for that, and that's where Hanjo mentioned its new function.

Just a note, though: to start the index rebuild, the sequence is FilePlayer, Soundtrack, and I don't think I'd want to add it for every entrance into the file player (if that's what you were thinking). The rebuild takes several seconds, and throws up popup panels. A UI button could be labelled RebuildIndex, and do FilePlayer, Soundtrack on one button.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Sat Feb 21, 2009 16:56

Hi Peter

question about getwizpnp and --indir

I am using --recursive and getting a list of all recordings stored in the following format

command used
getwizpnp.pl --indir="E:\V8 Supercars" --List --recursive >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

Result example

2008/Round 1 Clipsal 500/V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53

However wizpnp does not accept the above as a valid recording name in conjunction with the previous used indir.

Other than parsing the string and adding the rest of the directory to the indir argument (which works) is there any getwizpnp option that would accept it in the format it is returned as above.

Hope that makes sense !
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sat Feb 21, 2009 17:38

Warning: serious bug in getWizPnP --move version 0.3.4

:!: Except in limited circumstances for local recordings on your computer, in version 0.3.4, getWizPnP --move is equivalent to getWizPnP --delete :!:

I will be posting a bug fix tomorrow Sun 22 Feb.

This bug may affect versions of WizZilla that use getWizPnP 0.3.4.

This bug does not affect versions of getWizPnP before 0.3.4.

My apologies to anyone who has lost recordings because of this bug. I'm quite surprised I haven't been yelled at over this one :)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sat Feb 21, 2009 17:44

craigh wrote:Hi Peter

question about getwizpnp and --indir

I am using --recursive and getting a list of all recordings stored in the following format

command used
getwizpnp.pl --indir="E:\V8 Supercars" --List --recursive >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

Result example

2008/Round 1 Clipsal 500/V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53

However wizpnp does not accept the above as a valid recording name in conjunction with the previous used indir.

Other than parsing the string and adding the rest of the directory to the indir argument (which works) is there any getwizpnp option that would accept it in the format it is returned as above.

Hope that makes sense !
It makes sense. The output names from --List are intended to be used in conjunction with --BWNames, not as normal match arguments. I think you may be one of the first people to use --List on local recordings. It should work (in conjunction with --BWNames), WizZilla exercises these two options extensively for Beyonwiz recordings, but it wouldn't surprise me hugely if it didn't work.

You will need to quote the spaces and any other metacharacters for the names to match when you run getWizPnP with those names.

I'll try to get a fix into the next release (the next proper release, not the bugfix for --move) if there is a problem.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Sat Feb 21, 2009 20:11

prl wrote:
craigh wrote:Hi Peter

question about getwizpnp and --indir

I am using --recursive and getting a list of all recordings stored in the following format

command used
getwizpnp.pl --indir="E:\V8 Supercars" --List --recursive >"D:\Downloads\Beyonwiz\BeyonwizToolsBuild\files.txt"

Result example

2008/Round 1 Clipsal 500/V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53

However wizpnp does not accept the above as a valid recording name in conjunction with the previous used indir.

Other than parsing the string and adding the rest of the directory to the indir argument (which works) is there any getwizpnp option that would accept it in the format it is returned as above.

Hope that makes sense !
It makes sense. The output names from --List are intended to be used in conjunction with --BWNames, not as normal match arguments. I think you may be one of the first people to use --List on local recordings. It should work (in conjunction with --BWNames), WizZilla exercises these two options extensively for Beyonwiz recordings, but it wouldn't surprise me hugely if it didn't work.

You will need to quote the spaces and any other metacharacters for the names to match when you run getWizPnP with those names.

I'll try to get a fix into the next release (the next proper release, not the bugfix for --move) if there is a problem.
Thanks Peter

It works fine if i strip away the forward directory items that are returned by --List

2008/Round 1 Clipsal 500/ V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53


and add them to the original indir value

E:\V8 Supercars + \2008/Round 1 Clipsal 500/

with recursive it makes sense to return it that way so you know where it is on the file system.

Is all working well at present .

Lucky I gave up on Delete and Move and focussed on copy and post processing of the TS files based on your previous post :-)
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 22, 2009 06:05

craigh wrote:...

It works fine if i strip away the forward directory items that are returned by --List

2008/Round 1 Clipsal 500/ V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53


and add them to the original indir value

E:\V8 Supercars + \2008/Round 1 Clipsal 500/

with recursive it makes sense to return it that way so you know where it is on the file system.

Is all working well at present .
That all sounds a bit wierd. I'll try to get it fixed to the way it's supposed to work for the next release.
craigh wrote:Lucky I gave up on Delete and Move and focussed on copy and post processing of the TS files based on your previous post :-)
Delete should work just fine on public firmware, within the limitations of the published BUGS in the documentation. The delete bugs change slightly with 01.05.283, as we discussed earlier (force update of Beyonwiz index using FILEPLAYER, then SOUNDTRACK).

I discovered the --move bug the hard way in using the new version (which has a fairly major re-arrangement of the lower levels of the classes that do the file handling). Fortunately, another bug meant that it only deleted the header files, and not the actual recording data, so I could recofer the recording data using telnet/cp, but the released 0.3.4 version isn't that kind.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 22, 2009 06:51

prl wrote:Warning: serious bug in getWizPnP --move version 0.3.4

:!: Except in limited circumstances for local recordings on your computer, in version 0.3.4, getWizPnP --move is equivalent to getWizPnP --delete :!:
...
A new version of getWizPnP, 0.3.4b, that fixes this problem is available on BeyonwizSoftware.

The new version also fixes a cosmetic problem that causes the progress bar to go over 100% sometimes.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 22, 2009 10:39

craigh wrote:...

Thanks Peter

It works fine if i strip away the forward directory items that are returned by --List

2008/Round 1 Clipsal 500/ V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53


and add them to the original indir value

E:\V8 Supercars + \2008/Round 1 Clipsal 500/

with recursive it makes sense to return it that way so you know where it is on the file system.

Is all working well at present .
...
I was able to make this work on OS X, Cygwin/Windows and Windows by using '--BWName --all' in the command that uses the output of --List.

Now that I know what's happening (folder selection is being applied when --BWName is in use), I'm not certain that what's happening is a bug. What do you think?

If it stays the way it is, it probably needs to be documented better.

Dave?, alwayslooking, this is, in some sense, "your" feature. What do you think?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Sun Feb 22, 2009 12:14

prl wrote:
craigh wrote:...

Thanks Peter

It works fine if i strip away the forward directory items that are returned by --List

2008/Round 1 Clipsal 500/ V8 Supercars on Prime 2008 _live_ Nov.9.2008_12.53


and add them to the original indir value

E:\V8 Supercars + \2008/Round 1 Clipsal 500/

with recursive it makes sense to return it that way so you know where it is on the file system.

Is all working well at present .
...
I was able to make this work on OS X, Cygwin/Windows and Windows by using '--BWName --all' in the command that uses the output of --List.

Now that I know what's happening (folder selection is being applied when --BWName is in use), I'm not certain that what's happening is a bug. What do you think?

If it stays the way it is, it probably needs to be documented better.

Dave?, alwayslooking, this is, in some sense, "your" feature. What do you think?
Hi Peter

I dont think its a bug either.

Just a lack of understanding on my part.

Did not realise you needed --recursive on the command line when you were passing it the directory and absolute file reference with --BWName.

Now that I do I will go and get rid of all the string manupulation code I have added

I knew from testing that --recursive worked with --indir even though the notes say "Has no effect if --indir is used"

There is no difference netween --recursive and -- all is there ?

:-)
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 22, 2009 12:25

craigh wrote:...
I knew from testing that --recursive worked with --indir even though the notes say "Has no effect if --indir is used"
That's a bug in the documentation. It was true once.
craigh wrote:There is no difference netween --recursive and --all is there ?
No, they're synonyms. This is the getOpT setup for them in the code:

Code: Select all

        'a|recursive|all!'      => \$recursive,
-> '-a', --recursive, and --all are reversible (i.e. also allow --norecursive, etc) Boolean options that all operate on the $recursive variable, so they all have the same effect.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Feb 22, 2009 13:11

craigh wrote:
prl wrote:...
Now that I know what's happening (folder selection is being applied when --BWName is in use), I'm not certain that what's happening is a bug. What do you think?

If it stays the way it is, it probably needs to be documented better.

Dave?, alwayslooking, this is, in some sense, "your" feature. What do you think?
Hi Peter

I dont think its a bug either.

Just a lack of understanding on my part.

Did not realise you needed --recursive on the command line when you were passing it the directory and absolute file reference with --BWName.

Now that I do I will go and get rid of all the string manupulation code I have added

I knew from testing that --recursive worked with --indir even though the notes say "Has no effect if --indir is used"
...
Both issues fixed by changing the documentation :)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

indir with root dirctories

Post by craigh » Thu Mar 19, 2009 17:40

Hi Peter

With the latest betas has the issue of indir returning an error on root directories been resolved

getwizpnp.pl --indir="E:\" --List --recursive

Can't find E:" --List --recursive : No such file or directory
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: indir with root dirctories

Post by prl » Thu Mar 19, 2009 21:40

craigh wrote:Hi Peter

With the latest betas has the issue of indir returning an error on root directories been resolved

getwizpnp.pl --indir="E:" --List --recursive

Can't find E:" --List --recursive : No such file or directory
I don't recall that problem, but I'll try it on the new version.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: indir with root dirctories

Post by prl » Sat Mar 21, 2009 07:15

prl wrote:
craigh wrote:Hi Peter

With the latest betas has the issue of indir returning an error on root directories been resolved

getwizpnp.pl --indir="E:" --List --recursive

Can't find E:" --List --recursive : No such file or directory
I don't recall that problem, but I'll try it on the new version.
It works in the new version under Windows. It even works on Cygwin :)

However:

getwizpnp.pl --indir="E:" --List --recursive

doesn't work in Windows, and in Cygwin it's interpreted as equivalent to:

getwizpnp.pl --indir="E:" --List --recursive

But should "E:" be best interpreted as "E:" or "E:."? Windows "dir" command interprets as "E:.", where '.' is relative to the current directory for the "E:" drive. I think that's wierd, but that's how it is.

Either way, it's easy to fix.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Re: indir with root dirctories

Post by craigh » Sat Mar 21, 2009 08:22

prl wrote:
prl wrote:
craigh wrote:Hi Peter

With the latest betas has the issue of indir returning an error on root directories been resolved

getwizpnp.pl --indir="E:" --List --recursive

Can't find E:" --List --recursive : No such file or directory
I don't recall that problem, but I'll try it on the new version.
It works in the new version under Windows. It even works on Cygwin :)

However:

getwizpnp.pl --indir="E:" --List --recursive

doesn't work in Windows, and in Cygwin it's interpreted as equivalent to:

getwizpnp.pl --indir="E:" --List --recursive

But should "E:" be best interpreted as "E:" or "E:."? Windows "dir" command interprets as "E:.", where '.' is relative to the current directory for the "E:" drive. I think that's wierd, but that's how it is.

Either way, it's easy to fix.
Hi Peter

From your note above are you saying it is fixed in the new version or will be fixed in the new version ?

As for how should E: be interpreted I would have thought as E:\
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: indir with root dirctories

Post by prl » Sat Mar 21, 2009 09:58

craigh wrote:...
From your note above are you saying it is fixed in the new version or will be fixed in the new version ?

As for how should E: be interpreted I would have thought as E:\
"E:" worked in the new version when I tested it after your post. "E:" didn't work. I've since modified the new version so that "E:" means the asme as "E:".

My personal feeling is that on Windows "E:" should be interpreted as "E:.", because that's how DIR treats it.

However, on Cygwin "E:" is treated as equivalent to /cygwin/c, so "E:" is the same as "E:" (and "E:/").

Perhaps your wishes should over-ride my feelings here, because you actualy use Windows GetWizPnP in earnest. :)

Coding either option is trivial.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Re: indir with root dirctories

Post by craigh » Sat Mar 21, 2009 13:37

prl wrote:
craigh wrote:...
From your note above are you saying it is fixed in the new version or will be fixed in the new version ?

As for how should E: be interpreted I would have thought as E:\
"E:" worked in the new version when I tested it after your post. "E:" didn't work. I've since modified the new version so that "E:" means the asme as "E:".

My personal feeling is that on Windows "E:" should be interpreted as "E:.", because that's how DIR treats it.

However, on Cygwin "E:" is treated as equivalent to /cygwin/c, so "E:" is the same as "E:" (and "E:/").

Perhaps your wishes should over-ride my feelings here, because you actualy use Windows GetWizPnP in earnest. :)

Coding either option is trivial.

Hi Peter

Well my usage so far is fed from the windows file-dialog code and it returns x:\ when you select a root.

So the x: is up to you
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: indir with root dirctories

Post by prl » Sat Mar 21, 2009 15:05

craigh wrote:...

Hi Peter

Well my usage so far is fed from the windows file-dialog code and it returns x:\ when you select a root.

So the x: is up to you
I'll make x: maen x:\ for consistency with Cygwin and on the basis that (at least to me) x: means "all the device". And that's what I've coded already :)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Fri Mar 27, 2009 21:27

I'm on holidays for a month and I won't be accessing the forum. When I get back in late April, I'll make the new version of getWizPnP available.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Mon Apr 27, 2009 23:42

Details of a new (long-awaited) version of getWizPnP are available in a new topic in Content, Software and USB.

Bugs and enhancement requests should go in the new topic. I'll answer them there if they are posted here.

Discussion of implementation issues and internals is welcome to continue here.

Anyway, I think the new version makes getWizPnP the most feature-rich and capable WizPnP client currently publicly released :)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Tue Apr 28, 2009 21:44

Hi Peter

The change you made to --device

Matching device names using --device is now a case-insensitive substring match. Can be made a prefix match if people prefer.

This has caused all my scripts to fail as below

D:\Downloads\Beyonwiz\getWizPnP>getwizpnp.pl
Device name '' matches more than one device:
[FamilyRoom_BW-192.168.0.153-49152, FishRoom_BW-192.168.0.152-49152] were found

D:\Downloads\Beyonwiz\getWizPnP>getwizpnp.pl --device=FamilyRoom_BW
Device 'FamilyRoom_BW' isn't available.
[FamilyRoom_BW, FishRoom_BW] were found

have I missed something ?
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Tue Apr 28, 2009 22:29

Hi, Craig. The problem's mine. See my reply in Content, Software and USB.

Workaround posted in the linked post. Fix-it-yourself instructions there, too. I'll get a fixed version out ASAP.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Wed Apr 29, 2009 16:44

Thanks peter

That change to WizPnP.pl fixed the problem

Another item that we discussed further up this page re --indir and root directories does not seem to be resolved


D:\Downloads\Beyonwiz\getWizPnP>getwizpnp.pl --indir="E:\" --List --recursive
>"D:\Downloads\Beyonwiz\BwizTools\files.txt"
Can't find E:" --List --recursive : No such file or directory
Fetch of index for E:" --List --recursive failed

I tried stripping off the "\" etc
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Wed Apr 29, 2009 17:04

Hi Peter

I now notice that --indir returns all media not just tvwiz

Can this be masked to tvwiz, ts, avi ?
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Wed Apr 29, 2009 17:11

craigh wrote:Hi Peter

I now notice that --indir returns all media not just tvwiz

Can this be masked to tvwiz, ts, avi ?
Conceivably, yes, but the point of one of the major changes in 4.0 is to allow getWizPnP to copy any media types that might be in the contents folder on the Beyonwiz. I extracted the list of recognised media file extensions from the Beyonwiz firmware, and I used that as the mask for media files on the PC.

I could make this list of extensions configurable through the config file. It could also be made a command-line option, but that might be a bit cumbersome to use. But that way, you could change the list of recognised media file extensions to be anything you liked. It wouldn't be hard to do.

I could probably add this feature (if that would cover your needs) and fix the --device bug and release a new version on the weekend.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

craigh
Wizard
Posts: 1767
Joined: Tue Jul 03, 2007 08:41
Location: SouthEast

Post by craigh » Wed Apr 29, 2009 17:37

prl wrote:
craigh wrote:Hi Peter

I now notice that --indir returns all media not just tvwiz

Can this be masked to tvwiz, ts, avi ?
Conceivably, yes, but the point of one of the major changes in 4.0 is to allow getWizPnP to copy any media types that might be in the contents folder on the Beyonwiz. I extracted the list of recognised media file extensions from the Beyonwiz firmware, and I used that as the mask for media files on the PC.

I could make this list of extensions configurable through the config file. It could also be made a command-line option, but that might be a bit cumbersome to use. But that way, you could change the list of recognised media file extensions to be anything you liked. It wouldn't be hard to do.

I could probably add this feature (if that would cover your needs) and fix the --device bug and release a new version on the weekend.
Hi Peter

I have no issue with the files on the BW being handled that way.

Its just when I use --indir on a network drive that contains 1000+ files (but only 50 tvwiz) the list is a bit hard to handle.

Did you see my other post re root of drives as well ?
Craig
T4 + Kodi + Foxtel IQ2 > Yamaha RX-V2700 > Panasonic Plasma
T2 + Kodi Player > Pioneer Plasma
5 x Kodi + Enigma Plugin > LCD TV's
Retired - S1, P1, P1, FLV1, H1, H1
Foxtel IQ3 > Digi-MOD RL-DM1102 - SD DTV RF Modulator > All TV's
Remotes - Pronto TSU9400's + TSU7500's

Post Reply

Return to “Software Developers”