getWizPnP - a command-line WizPnP uploader

Advanced Discussions on Programing for & Modifying Beyonwiz Products.

Moderators: Gully, peteru

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

getWizPnP - a command-line WizPnP uploader

Post by prl » Mon Mar 24, 2008 16:59

I'll be making it available on http://www.beyonwizsoftware.net/ soon.

It can upload either as a .tvwiz folder, or as a single .ts file.

Here's the current manual page:

Code: Select all

NAME

    getWizPnP - list and fetch recordings from a Beyonwiz DP series over the
    network using the WizPnP interface

SYNOPSIS

        getWizPnP [-h host|--host=host] [-p port|--port=port]
                  [-l|--list] [-|--date] [-t|--ts] [-v|--verbose]
                  [-r|--regexp] [-e|--expression]
                  [ patterns... ]

DESCRIPTION

    List or fetch the recordings on a Beyonwiz DP series PVR over the
    network using the WizPnP interface.

    If no pattern arguments are given, then all recordings are listed.
    Otherwise recordings matching any of the patterns are fetched (or
    listed, with --list).

    In the absence of --regexp or --expression a pattern matches if it is a
    substring of the string *servicename*#*title*#*date*, case sensitive.
    For example:

        SC10 Canberra#MOVIE: Pride & Prejudice#Fri Feb 15 20:28:00 2008

    To upload all recordings, an empty string will match everything:

        wizGetPnP ''

    Recordings are uploaded to a name corresponding to their event name
    (title) with any characters that are illegal in the file system changed
    to '_'. The --date option adds the day and date of the recording to the
    name, helpful for series recordings. Uploaded recordings are placed in
    the current directory.

ARGUMENTS

    GetWizPnP takes the following arguments:

    host
          --host=host
          -h host

        Connect to the *host* (DNS name or dotted-quad IP address) instead
        of the file default ("beyonwiz"), or the default set in the
        configuration file (see FILES below).

    host
          --port=port
          -p port

        Connect to the *port* instead of the file default (49152), or the
        default set in the configuration file (see FILES below).

    list
          --list
          -l

        List the matching recordings, rather than uploading them.

    date
          --date
          -d

        Add the recording day and date to the name of the recording when
        it's uploaded. Useful for uploading series.

    ts
          --ts
          -t

        Upload the recordings as single ".ts" (MPEG Transport Stream) files,
        rather than copying in the Beyonwiz internal recording format.

    verbose
          --verbose
          -v

        Provide more information. A single -v lists some more details about
        the recordings, and shows a progress indicator when copying. Two -v
        options list the sizes of the recording file chunks on the Beyonwiz.

    regexp
          --regexp
          -r

        Carry out the matches using the argument as a Perl regular
        expression. For example:

            getWizPnP --regexp 'ABC|SBS'

        will copy all recordings made from either the ABC or SBS.

    expression
          --expression
          -e

        Evaluates the match arguments as Perl expressions with $_ set to the
        *servicename*#*title*#*date* string. If any expression evaluates to
        true (in Perl terms), the recording is matched.

            getWizPnp --expression '/ABC|SBS/'

        is equivalent to the --regexp example above. Quite powerful; the
        Swiss Army knife approach.

PREREQUSITES

    Uses packages "Beyonwiz::Recording::Header",
    "Beyonwiz::Recording::Index", "Beyonwiz::Recording::IndexEntry",
    "Beyonwiz::Recording::Trunc", "Beyonwiz::Recording::TruncEntry",
    "File::Basename", "Getopt::Long", "HTTP::Status", "LWP::Simple", "URI",
    "URI::Escape"

BUGS

    File copy progress bar only updates after each (up to) 32MB chunk file
    is copied.

    It's not possible to restart interrupted transfers.

    If the *--ts* flag is given, uploading a recording to the same name will
    overwrite the original; if it's not given an error results. It's not
    completely clear what the correct behaviour should be.

    Can only upload to the current directory.

    Doesn't use the WizPnP protocol to find WixPnP servers.


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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Mon Mar 24, 2008 17:38

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

Re: getWizPnP - a command-line WizPnP uploader

Post by DaveR » Mon Mar 24, 2008 19:35

That was quick! :P
I haven't even looked at the source yet...
prl wrote:It can upload either as a .tvwiz folder, or as a single .ts file.

To upload all recordings, an empty string will match everything:

Recordings are uploaded to a name corresponding to their event name

name, helpful for series recordings. Uploaded recordings are placed in
List the matching recordings, rather than uploading them.

Add the recording day and date to the name of the recording when
it's uploaded. Useful for uploading series.

Upload the recordings as single ".ts" (MPEG Transport Stream) files,

If the *--ts* flag is given, uploading a recording to the same name will

Can only upload to the current directory.
Sorry to be pedantic, but you've adopted the Korean logic of calling downloads uploads. :?
IMHO if a file/packet is being transferred TO the application it is being Downloaded.
If a file/packet is being transferred FROM the application it is being Uploaded.

So a PC application:
Downloads FROM the PVR
and Uploads TO the PVR

And a PVR application:
Downloads FROM a PC
and Uploads TO a PC

prl wrote:ARGUMENTS

GetWizPnP takes the following arguments:

host
--host=host
-h host

Connect to the *host* (DNS name or dotted-quad IP address) instead

host
--port=port
-p port

Connect to the *port* instead of the file default (49152), or the[/code]
You've got host twice, instead of host and port.

prl wrote: It's not possible to restart interrupted transfers.

Doesn't use the WizPnP protocol to find WixPnP servers.[/code]
Any chance of implementing these in future?

Nice work, BTW.
cheers
DaveR

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

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

Re: getWizPnP - a command-line WizPnP uploader

Post by prl » Mon Mar 24, 2008 22:50

Dave? wrote:That was quick! :P
I haven't even looked at the source yet...
I had most of the real guts already written. All it needed really was to decode the header.tvwiz and trunc files properly, and use the filenumbers from the trunc file.
Dave? wrote:Sorry to be pedantic, but you've adopted the Korean logic of calling downloads uploads. :?
Wiktionary wrote:Verb

to upload (third-person singular simple present uploads, present participle uploading, simple past and past participle uploaded)

1. (transitive or intransitive) (computing) to transfer data or files from a peripheral or subordinate system to a larger or more central one; especially from a personal computer to an Internet server
That sounds like what getWizPnP does. :) I think I'll stick by upload. I could see PC owners viewing the PC as the subordinate system to the BW, though. :P

Fair call on the "host" in the doco. A bit of a rush job. There's no documentation at all for the support modules yet, so consider yourselves lucky :)
Dave? wrote:
prl wrote: It's not possible to restart interrupted transfers.

Doesn't use the WizPnP protocol to find WixPnP servers.
Any chance of implementing these in future?
I'll think about interrupted transfers.

I'm not sure that the WizPnP search is the "right" way to do a command-line interface, but I'll think about that one, to. I guess it could search for the named host and use WizPnP as a very slow DNS lookup. I have my BW IP addresses nailed down in the DHCP server, and I name them in my /etc/hosts, so if I implemented this feature, I'd have it switched off all the time myself. Anyway, I'm happy to hear suggestions about how it might best be implemented.
Dave? wrote:Nice work, BTW.
Thanks.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

efry
Master
Posts: 150
Joined: Thu Aug 30, 2007 22:01
Location: Sydney
Contact:

Re: getWizPnP - a command-line WizPnP uploader

Post by efry » Mon Mar 24, 2008 23:21

prl wrote: That sounds like what getWizPnP does. :) I think I'll stick by upload. I could see PC owners viewing the PC as the subordinate system to the BW, though. :P
I take upload to mean 'a transfer from a client to a server'. In this case the PC is the client and the wiz is the server. So I would expect an upload to be from PC to wiz. Just my 2cents.

Eric

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

Re: getWizPnP - a command-line WizPnP uploader

Post by prl » Tue Mar 25, 2008 08:52

efry wrote:
prl wrote: That sounds like what getWizPnP does. :) I think I'll stick by upload. I could see PC owners viewing the PC as the subordinate system to the BW, though. :P
I take upload to mean 'a transfer from a client to a server'. In this case the PC is the client and the wiz is the server. So I would expect an upload to be from PC to wiz. Just my 2cents.

Eric
That's Dave's interpretation, too, and it's true enough for just the context of the transaction. But the reason for the transaction is often so that the recording can be served from the PC back to the BW or to other devices, or for archiving. In that context I think upload is more appropriate, but I won't defend the term as fanatically as my initial reply might suggest. The whole thing is complicated by the fact that although I think of the BW as a peripheral system to my Mac, both the Mac and the BW can be client or server depending on the context.

Is a network update of the firmware an upload or a download to the BW? What about a (sneakernet) update using USB?
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Tue Mar 25, 2008 09:32

getWizFX 0.1 BUGS
  • File copy progress bar only updates after each (up to) 32MB chunk file is copied.
  • It's not possible to restart interrupted transfers.
  • If the --ts flag is given, uploading a recording to the same name as an existing one will overwrite the original; if the --ts flag isn't used an error results. It's not completely clear what the correct behaviour should be.
  • The above bug description isn't as clear as in should be in the documentation.
  • Can only upload to the current directory.
  • Doesn't use the WizPnP protocol to find WixPnP servers.
  • No documentation for the support modules.
  • Incorrect heading for the --port option in the documentation.
  • The configuration file $HOME/.getwizpnp not documented.
  • The fact that the --date, --regexp and --expression options have --nodate, --noregexp and --noexpression forms is not documented. These forms allow the options to be on by default in the config file, and switched off in the command line.
  • Merging a recording into a .TS file will not work correctly if the recording has been edited in anyway apart from trimming the end off. The uploaded .TS file might play, but may contain parts of the recording that were edited out, and not contain parts of the file that should be there. Comes from missing seeing the protocol document, and a too-cursory reading of the source code.
The .getwizpnp configuration file.
Looked for in $HOME/.getwizpnp (equivalently %HOME%\.getwizpnp on Windows) or as .getwizpnp in getWizPnP's home directory if the environment variable HOME isn't set. Not documented, and no example in the 0.1 distribution.

Most useful for setting the default host or port.

Code: Select all

# Example .getwizpnp configuration file

# To enable config file entries, edit them to the correct value, and uncomment
# Them by removing the leadting '#'

# Set the default host
# The host name here can't (yet) just be the server name set up in the Beyonwiz
# Use this form if you have a DNS name set up for the Beyonwiz (e.g. in /etc/hosts)
#$host = 'MyWiz';
# Use this form if your PC doesn't have a DNS name.
#Get the IP address from the IP field in the Beyonwiz's LAN/W-LAN status.
#$host = '10.1.1.3'

# Set the default port number if you've changed the port number on the BW.
# Must match the value in Setup>Network>WizPnP>Port if it isn't 49152
#$port=12345;

# Use regular expression matching rather than string matching (--regexp)
#$regexp=1;

# Use Perl expression matching rather than string matching (--expresssion)
#$expression=1;

# Add the program date to its name for uploads by default (--date)
#$date = 1;
Last edited by prl on Tue Mar 25, 2008 12:33, edited 1 time in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
rwhitby
Apprentice
Posts: 37
Joined: Tue Aug 28, 2007 17:41
Location: Adelaide, Australia Project:http://www.openwiz.org Hardware:DP-P1, LiDiC

Re: getWizPnP - a command-line WizPnP uploader

Post by rwhitby » Tue Mar 25, 2008 09:42

prl wrote:Is a network update of the firmware an upload or a download to the BW? What about a (sneakernet) update using USB?
I would download the firmware from the Beyonwiz korea web server to a disk somewhere which is shared on the network. If I'm making the Beyonwiz PVR get it from a network share, then the Beyonwiz PVR is downloading it from that share. As for the USB disk, I would download it from the Beyonwiz korea web server to the USB stick. Then I would plug the USB stick into my Beyonwiz PVR and the PVR would transfer it from the stick to internal memory (it's neither a download nor an upload, cause there is no client-server transaction happening).

-- Rod

MeWhoElse
Apprentice
Posts: 40
Joined: Thu Feb 14, 2008 15:59
Location: Between here and there

Re: getWizPnP - a command-line WizPnP uploader

Post by MeWhoElse » Tue Mar 25, 2008 13:46

rwhitby wrote:
prl wrote:Is a network update of the firmware an upload or a download to the BW? What about a (sneakernet) update using USB?
I would download the firmware from the Beyonwiz korea web server to a disk somewhere which is shared on the network. If I'm making the Beyonwiz PVR get it from a network share, then the Beyonwiz PVR is downloading it from that share. As for the USB disk, I would download it from the Beyonwiz korea web server to the USB stick. Then I would plug the USB stick into my Beyonwiz PVR and the PVR would transfer it from the stick to internal memory (it's neither a download nor an upload, cause there is no client-server transaction happening).
Yet, you are transferring the file to a peripheral. If it was a local hard drive, I would say it is copying if that transfer was to another internal hard drive, but to transfer a file to an external device is downloading/uploading. Using Download or Upload is also dependent on where the data resides you wish to transfer. Hence the data store is considered the Server. Download to receive a file, upload to send a file.

User avatar
rwhitby
Apprentice
Posts: 37
Joined: Tue Aug 28, 2007 17:41
Location: Adelaide, Australia Project:http://www.openwiz.org Hardware:DP-P1, LiDiC

Re: getWizPnP - a command-line WizPnP uploader

Post by rwhitby » Tue Mar 25, 2008 13:54

MeWhoElse wrote:Yet, you are transferring the file to a peripheral. If it was a local hard drive, I would say it is copying if that transfer was to another internal hard drive, but to transfer a file to an external device is downloading/uploading. Using Download or Upload is also dependent on where the data resides you wish to transfer. Hence the data store is considered the Server. Download to receive a file, upload to send a file.
I don't consider a usb stick to be an external device as far as upload and download are concerned. A usb stick appears as a mounted area in the local filesystem. You don't upload or download from one directory to another in the same filesystem.

Something on the other end of a network cable, where one device is a client and the other device is a server, is when the upload/download terminology is used, and the role of client or server defines whether it is an upload (from a client to a server) or a download (from a server to a client).

When a Beyonwiz PVR stores a recorded program on an external network share, it is uploading the program to the server which hosts that network share. When the Beyonwiz is sharing it's internal drive via uPnP, an external media player client downloads the program from the Beyonwiz.

-- Rod

MeWhoElse
Apprentice
Posts: 40
Joined: Thu Feb 14, 2008 15:59
Location: Between here and there

Post by MeWhoElse » Tue Mar 25, 2008 14:04

Some dictionarys do state to a peripheral/electronic device. As I said, internal to the computer is a copy, ie copying within the file structure of the same drive is copying/moving data, and I believe from internal HDD to internal HDD is also copying/moving. Agree once again on the network attached storage.

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

Post by prl » Tue Mar 25, 2008 14:26

OK, The Tribe Has Spoken. It's time for Upload to go :)

It still feels odd to me, but it will all be changed over in the next release.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

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

Post by IanSav » Tue Mar 25, 2008 14:46

Hi Peter,
prl wrote:OK, The Tribe Has Spoken. It's time for Upload to go :)

It still feels odd to me, but it will all be changed over in the next release.
You can always define your interpretation/use of the word in the help text.

I do tend to think about transfers/uploads/downloads in much the same way as Rod suggested.

Regards,
Ian.

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

Re: getWizPnP - a command-line WizPnP uploader

Post by prl » Tue Mar 25, 2008 18:14

Dave? wrote:...
prl wrote:...
Doesn't use the WizPnP protocol to find WixPnP servers.[/code]
Any chance of implementing these in future?
Not looking promising in the short term, I'm afraid. The WizPnP discovery process uses HTTPMU (HTTP Multicast UDP) protocol, and there's no Perl implementation of this in CPAN.

If anyone knows of one. please let me know.

However, the WizFX code for this function doesn't look too hard to turn into Perl.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

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

Re: getWizPnP - a command-line WizPnP uploader

Post by IanSav » Tue Mar 25, 2008 18:50

Hi Peter,
prl wrote:Not looking promising in the short term, I'm afraid. The WizPnP discovery process uses HTTPMU (HTTP Multicast UDP) protocol, and there's no Perl implementation of this in CPAN.

If anyone knows of one. please let me know.

However, the WizFX code for this function doesn't look too hard to turn into Perl.
Does this help http://search.cpan.org/~lds/IO-Socket-M ... lticast.pm ?

Regards,
Ian.

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

Re: getWizPnP - a command-line WizPnP downloader

Post by prl » Tue Mar 25, 2008 21:30

IanSav wrote:Hi Peter,
prl wrote:Not looking promising in the short term, I'm afraid. The WizPnP discovery process uses HTTPMU (HTTP Multicast UDP) protocol, and there's no Perl implementation of this in CPAN.

If anyone knows of one. please let me know.

However, the WizFX code for this function doesn't look too hard to turn into Perl.
Does this help http://search.cpan.org/~lds/IO-Socket-M ... lticast.pm ?

Regards,
Ian.
Yep. But I'd already found that bit. It has most of what I'd need to implement the PnP search.
Last edited by prl on Tue Apr 01, 2008 08:04, edited 1 time in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

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

Post by prl » Fri Mar 28, 2008 14:38

Some notes about the WizFX WizPnP protocol document and discovery code.

Timeout in TfrmDownloader.tmSearchTimer

According to Beyonwiz's WizPnP protocol document, the HTTPMU M-SEARCH request should have the MX header set to 3.

According to the uPnP device architecture document, "Devices should wait a random period of time between 0 seconds and the number of seconds specified in the MX header of the search request before responding".

In the code for TfrmDownloader.tmSearchTimer, in WizDownloaderMain.pas, the HTTPMU request is sent, then the code loops 15 times round doing IdUDPClient1.ReceiveString(100) and calls ProcessResult() if something is returned. The parameter 100 is a 100ms timeout (http://www.indyproject.org/ documentation for TIdUDPClient). This is a maximum wait time of 1.5 seconds, not the 3 seconds specified in the MX header.

Does this mean that the Beyonwiz doesn't uniformly distribute its responses to the request over the 3 seconds in the MX record, or is this a bug that should cause the search to fail about half the time? I don't use WizFX. Does the device search fail fairly often? I'd have thought that people would have complained about it if did.

When MJD is not MJD

In the definition of the TWizTSPoint structure, which is the part of the header.tvwiz file that describes the recording attributes, there is a field called mjd.

MJD is normally Modified Julian Date, which is "the number of days ... that have elapsed since midnight at the beginning of Wednesday November 17, 1858 [Universal Time]".

The mjd field in TWizTSPoint is not the MJD of the date of the recording, and the start field is not the seconds part of the elapsed Julian day at the time of the recording. The timestamp is in fact the MJD plus the time zone offset current at the time the recording started. I don't know why such a thing got called MJD.

To make sense of this time scheme, you can translate the recording start time into local time in C or (or similarly in Perl) on Unix-like systems using:

Code: Select all

time_t startt;
struct tm *locatime;
startt  = (wizTSPoint.mjd - 40587) * 24 * 60 * 60 + wizTSPoint.starttime;
localtime = gmtime(&startt);
/* now the fields of localtime are correct for local time at the start of the recording */
In particular, note that although startt is similar to the Unix time, it should not be converted into the local time date/time information in struct tm by using localtime() as it normally would be.

I don't know why the Beyonwiz (like the TF7000 PVR) choses to represent time in this manner internally. It's especially strange since the EPG information is all UT based.

The fields in the Beyonwix trunc file

The contents of this file aren't well described by the protocol document (and there's an error in the pseudocode that describes how to create a .TS file from a Beyonwiz recording.

Each TwizOffsetFileSection record in the trunc file describes a piece of a logical recording constructed from the numbered files. There may be more than one record in the trunc file for any of the 0000, 0001, etc files in the recording.

The fields are:
  • wizOffset : UInt64; The offset of the start of this chunk in the logical file. Unsigned 64-bit number.
  • fileNum: Word; The file number in the recording containing the chunk. The file name is always a 4-digit zero-padded number: 0000, 0001, ..., 0099, .... 16 bit unsigned? number
  • flags: Smallint; Unknown function. Not described in the protocol document or used in WizFX. 16bit signed? number.
  • offset: UInt64; The offset of the start of the chunk in the file named by fileNum. Unsigned 64-bit number.
  • size: LongWord; Size of the chunk. 32 bit unsigned? number.
The error in the pseudocode to TS file construction is in 3.4 Example, TYPE B.

Code: Select all

DownloadAndMergeFile(?TSFileName?, ?001?, 6 * 1024 * 1024, 32 * 1024 * 1024);
should be

Code: Select all

DownloadAndMergeFile(?TSFileName?, ?001?, 6 * 1024 * 1024, 26 * 1024 * 1024);
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sat Mar 29, 2008 11:42

Has anyone tried using Perl IO::Socket::Multicast?

I'm trying to recode the WixPnP search part of the WizFX protocol in Perl, and I send out the M-SEARCH request, but I don't get the response that's in the document. All I see is the SSDP NOTIFY message that the BW multicasts every minute.

The code looks like this:

Code: Select all

use constant SSDPADDR => '239.255.255.250';
use constant SSDPPORT => 1900;
use constant SSDPPEER => SSDPADDR . ':' . SSDPPORT;

use constant CRLF => "\015\012";

use IO::Socket::Multicast; #ZZ qw(mcast_loopback mcast_add);
use IO::Select;

sub process($) {
    my ($data) = @_;
    print $data, "\n";
}

my $sout = IO::Socket::Multicast->new(Proto => 'udp', PeerAddr => SSDPPEER);
$sout->mcast_loopback(0);

my $sin = IO::Socket::Multicast->new(Proto => 'udp', LocalPort => SSDPPORT)
	    || die "Can't make socket to configure WizPnP: $!\n";
$sin->mcast_add(SSDPADDR) || die "Can't add WizPnP multicast address: $!\n";

my $msg = 'M-SEARCH * HTTP/1.1' . CRLF
     . 'MX: 3' . CRLF
     . 'ST: urn:wizpnp-upnp-org:device:pvrtvdevice:1' . CRLF
     . 'HOST: 239.255.255.250:1900' . CRLF
     . 'MAN: "ssdp:discover"' . CRLF . CRLF;
print "Sending: \n", $msg;
$sout->send($msg) || die "Can't send WizPnP request: $!\n";
$sout->close || die "Can't close WizPnP request: $!\n";;

my $sel = IO::Select->new;
$sel->add($sin);

for(my $i = 0; $i < 60; $i++) {
    print "try $i\n";
    if($sel->can_read(1)) {
	my $data;
	process($data) if(defined $sin->recv($data, 1024));
	last;
    }
}
After a random time less than 60 seconds, process() gets called with $data containing an SDDP NOTIFY message, rather than the HTTP/1.1 200 OK message that is the response that's supposed to come for the M-SEARCH request.

I can make this work, in some sense, but the length of time required to find the PnP device is way too long for it to really be useful.

Anyone got any ideas here?
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Mon Mar 31, 2008 18:31

wizGetPnP 0.1.1

Just released on www.beyonwizsoftware.net.

New in 0.1.1
  • WizPnP device search support added, but it has problems. See the bugs entry below.
  • Ability to specify copy destination directory added.
  • Documentation improved. Added documentation for support modules. Changed all references to 'upload' to 'download'.
  • The short form for --host is now -H; -h is now the short form for --help
Bugs in 0.1.1
  • File copy progress bar only updates after each (up to) 32MB chunk file is copied.[/li]
  • It's not possible to restart interrupted transfers.
  • If the --ts flag is given, uploading a recording to the same name as an existing one will overwrite the original; if the --ts flag isn't used an error results. It's not completely clear what the correct behaviour should be.
  • Although WizPnP device search has been added, the Beyonwiz doesn't seem to respond to the WizPnP search request. The Beyonwiz does send out WizPnP NOTIFY messages every minute, and these are correctly interpreted, but this can take up to a minute, and on average is 30 seconds.
  • Display of the bookmark offsets is incorrect. The offset used to extract the bookmarks in Beyonwiz::Recording::Header is incorrect. Line 480:

    Code: Select all

    		@offsets = unpack '@79334 (V2)' . $nbkmk, $hdr_data;
    should probably read:

    Code: Select all

    		@offsets = unpack '@79336 (V2)' . $nbkmk, $hdr_data;
    But I haven't been able to verify the fix yet. Added 2/4/08.
Fixed in 0.1.1
  • Can only upload to the current directory.
  • Doesn't use the WizPnP protocol to find WixPnP servers.
    [*No documentation for the support modules.
  • Incorrect heading for the --port option in the documentation.
  • The configuration file $HOME/.getwizpnp not documented.
  • The fact that the --date, --regexp and --expression options have --nodate, --noregexp and --noexpression forms is not documented. These forms allow the options to be on by default in the config file, and switched off in the command line.
  • Merging a recording into a .TS file will not work correctly if the recording has been edited in anyway apart from trimming the end off. The uploaded .TS file might play, but may contain parts of the recording that were edited out, and not contain parts of the file that should be there. Comes from missing seeing the protocol document, and a too-cursory reading of the source code.
Last edited by prl on Wed Apr 02, 2008 08:52, edited 1 time in total.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

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

Post by prl » Tue Apr 01, 2008 19:41

Ive posted what I've learnt about the BW recording header files on the Recorded Files page on Openwiz. I've left most of Dave's stuff there except for what I was pretty sure was incorrect. Dave will probably have a look at it and decide what he wants to keep there of his original post.
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Thu Apr 03, 2008 09:19

I've added a description of the bookmarks section of header.tvwiz to the Recorded Files page on Openwiz.
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Thu Apr 03, 2008 09:41

I think I've worked out how to do resumption of interrupted transfers in getWizPnP; I just need to work out how to get 64-bit file sizes to work and how to do 64-bit seek offsets on Perls that have 32-bit longs. Perhaps "use bignum" will just work.

Anyway, I have some questions about how getWizPnP should work when it's asked to copy a recording and the recording already exists on the host.

Current behaviour
Overwrites the recording if it's a TS file; dies if its a BW-format recording and the recording folder exists (even if it's empty).

Options if the existing recording is complete
"Complete" means "has the same length as the recording on the BW".

Overwrite anyway? Or error unless --force option is given? (applies to both TS and BW-format recordings)

Options if the existing recording is incomplete
"Inomplete" means "has the shorter length than the recording on the BW".

Invoke resumption automatically? Or error unless --resume option is given?

Options if the existing recording is larger than the recroding on the BW

Overwrite anyway? Or error unless --force option is given? (applies to both TS and BW-format recordings)

Or should it do something else entirely?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

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

Post by IanSav » Thu Apr 03, 2008 11:25

Hi Peter,

You could always print out a comparison of the old and new files (size, date etc) and then give the user the option to abort the transfer, overwrite the existing file or change the name slightly and copy the file. (A name link "recording.ts" could be named "recording1.ts" etc.)

Regards,
Ian.

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

Post by prl » Thu Apr 03, 2008 13:34

Hi Ian.

My intention is to keep getWizPnP scriptable, and asking the user questions makes it less amenable to automation. Just that Unix mindset, I guess.

Also, there isn't a single file size to talk about in a BW format recording, and then there's the whole mess of the recording time vs file timestamps, and so on - the recording time isn't accessible in the TS format and it's a bit unclear to me what the right tests are.
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Fri Apr 04, 2008 19:15

I've noticed that all the offsets in the TOffset table in my recordings are at multiples of 8192 (0z2000) bytes (you can extract the offsets with getWixPnP.pl -lvvvv).

Is that a characteristic of the MPEG TS format or have the recordings been padded?
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Apr 06, 2008 14:32

Version 0.1.2 of getWizPnP released.

Implements WizPnP device search correctly (and quickly!).

For those interested in the gory details, this is how to do WizPnP device search (in Perl):

Code: Select all

use strict;
use warnings;

use constant SSDPADDR => '239.255.255.250';
use constant SSDPPORT => 1900;
use constant SSDPPEER => SSDPADDR . ':' . SSDPPORT;

use constant CRLF => "\015\012";

use IO::Socket::Multicast;
use IO::Select;

sub process($) {
    my ($data) = @_;
    print $data, "\n";
}

my $sout = IO::Socket::Multicast->new(Proto => 'udp',
				      PeerAddr => SSDPPEER,
				      ReuseAddr => 1);
$sout->mcast_loopback(0);

my $mysock = $sout->sockname;
my ($myport) = sockaddr_in($mysock);

my $sin = IO::Socket::INET->new(Proto => 'udp',
				LocalPort => $myport,
				ReuseAddr => 1)
       || die "Can't make socket to configure WizPnP: $!\n";

my $msg = 'M-SEARCH * HTTP/1.1' . CRLF
     . 'MX: 3' . CRLF
     . 'ST: wizpnp-upnp-org:device:pvrtvdevice:1' . CRLF
     . 'HOST: 239.255.255.250:1900' . CRLF
     . 'MAN: "ssdp:discover"' . CRLF . CRLF;

print "Sending: \n", $msg;
$sout->send($msg) || die "Can't send WizPnP request: $!\n";
$sout->close || die "Can't close WizPnP request: $!\n";;

my $sel = IO::Select->new;
$sel->add($sin);

for(my $i = 0; $i < 35; $i++) {
    print "try $i\n";
    if($sel->can_read(0.1)) {
	my $data;
	process($data) if(defined $sin->recv($data, 1024));
	last;
    }
}
The important error in my original code was that the WizPnP protocol sends the response back directed to the source IPaddr,port of the multicast request. The response doesn't use multicast to send the response. So the code uses getsockname() on the sending socket to find its port number $myport, and then binds to that port for incoming messages. Both sockets must set SOL_REUSEADDR, because they use the same port number.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
alwayslooking
Master
Posts: 299
Joined: Tue Jul 03, 2007 10:56
Location: Adelaide
Contact:

Post by alwayslooking » Sun Apr 06, 2008 20:29

This is really good Peter :D
I've had no luck in making Damn Small Linux run it, but fine on Ubuntu...and Windows :-)

Interestingly WizPNP server wouldn't work for me on the March 20 firmware, so I've downgraded to the previous version and all is good and I can use getWizPnP.

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

Post by DaveR » Sun Apr 06, 2008 20:59

prl wrote:Anyway, I have some questions about how getWizPnP should work when it's asked to copy a recording and the recording already exists on the host.
Whatever you decide as the default behaviour there must be options to change the behaviour as needed.
cheers
DaveR

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

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

Post by prl » Sun Apr 06, 2008 22:33

alwayslooking wrote:This is really good Peter :D
Thanks.
alwayslooking wrote:I've had no luck in making Damn Small Linux run it, but fine on Ubuntu...and Windows :-)
What's the problem with DSU? Is it missing multicast support?

I'm pleasantly surprised it works on Windows, I've never tried on that.
alwayslooking wrote:Interestingly WizPNP server wouldn't work for me on the March 20 firmware, so I've downgraded to the previous version and all is good and I can use getWizPnP.
I was lucky enough to be away when 215 was released, and by the time I saw it had been released, I decided I didn't want to mess with it.

What's the problem with it? Will getWizPnP work with it if you use --host instead of the WizPnP device search?
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun Apr 06, 2008 22:34

Dave? wrote:
prl wrote:Anyway, I have some questions about how getWizPnP should work when it's asked to copy a recording and the recording already exists on the host.
Whatever you decide as the default behaviour there must be options to change the behaviour as needed.
I thought I'd outlined the options when I posted.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
alwayslooking
Master
Posts: 299
Joined: Tue Jul 03, 2007 10:56
Location: Adelaide
Contact:

Post by alwayslooking » Mon Apr 07, 2008 08:54

prl wrote: What's the problem with DSU? Is it missing multicast support?
I believe there is a full Perl package for DSL, but I ran out of time to mess around with it. I'm guessing there will be a multicast package for it too (and the XML-DOM)

The first stumbling block with DSL is:

Code: Select all

Setuid/gid script writable by world
prl wrote: I'm pleasantly surprised it works on Windows, I've never tried on that.
I had to install some modules, but it finds the wiz (with the -H option) and returns a list of the recordings - and that's as far as I got (ran out of time).

I plan to test transferring (downloading / uploading?) today.

Do you know if when using TS mode, if you can start viewing the file before it's finished?

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

Post by prl » Mon Apr 07, 2008 09:39

alwayslooking wrote:
prl wrote: What's the problem with DSU? Is it missing multicast support?
I believe there is a full Perl package for DSL, but I ran out of time to mess around with it. I'm guessing there will be a multicast package for it too (and the XML-DOM)

The first stumbling block with DSL is:

Code: Select all

Setuid/gid script writable by world
Ah. A Perl installation problem, then. I don't know DSU, so I don't think I can help much with that. Sorry.
alwayslooking wrote:...
Do you know if when using TS mode, if you can start viewing the file before it's finished?
TS mode copy just writes the .ts file sequentially. Provided the file system allows simultaneous opens for read and write, and the reader doesn't catch up with the writer, it should be OK. It will certainly be OK on Linux; I;'m not so sure about what the NTFS file system file locking rules are; it may not be possible.
alwayslooking wrote:I had to install some modules [on Windows]
Most installations will need to install some modules from CPAN to run getWizPnP, unless they've already been installed for something else.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
alwayslooking
Master
Posts: 299
Joined: Tue Jul 03, 2007 10:56
Location: Adelaide
Contact:

Post by alwayslooking » Mon Apr 07, 2008 23:40

Code: Select all

Setuid/gid script writable by world
prl wrote:Ah. A Perl installation problem, then. I don't know DSU, so I don't think I can help much with that. Sorry.
Doesn't matter, I seem to keep hitting walls with DSL lately.
prl wrote: TS mode copy just writes the .ts file sequentially. Provided the file system allows simultaneous opens for read and write, and the reader doesn't catch up with the writer, it should be OK. It will certainly be OK on Linux; I;'m not so sure about what the NTFS file system file locking rules are; it may not be possible.
I have been able to start a transfer and begin playing it before it completes on Ubuntu and Windows, which I think is a bonus :D

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

Post by prl » Sat May 10, 2008 19:09

There's a new version of getWizPnP on beyonwizsoftware.net.

Version: 0.2 (See attachments for earlier versions)
Author: prl

Release notes
New:
  • Resumption of interrupted downloads --resume
  • Possible to force over-write of existing recordings --force
  • Episode name shown with title in listings, and used for selection (for FW 1.05.232 & later)
  • Can show program synopsis if available (for FW 1.05.232 & later)
  • Warns, doesn't stop the recording download if the recording stat file can't be downloaded
  • Local copying (e.g. to convert BW format recordings to .ts --indir
  • Finer-grained updates to the copy progress bar
  • Some performance improvements
  • A couple of options intended to make it easier to use with a GUI wrapper (--List & --BWName)
  • Some internal restructuring, especially in the class hierarchy for local/remote recordings
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.
Fixed:
  • File copy progress bar only updates after each (up to) 32MB chunk file is copied.
  • It's not possible to restart interrupted transfers.
  • If the --ts flag is given, uploading a recording to the same name as an existing one will overwrite the original; if the --ts flag isn't used an error results. It's not completely clear what the correct behaviour should be.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

jrx
Master
Posts: 151
Joined: Thu Nov 15, 2007 11:31
Location: Perth, WA, Australia (DP-P1 + DP-H1)

Post by jrx » Sun May 11, 2008 11:18

jrx wrote:
Hi guys,
I just downloded the latest version and tried converting a local file
Code:
getwiz -tv -I 'Top Gear_Mar.3.2008_19.30.tvwiz'


and all I get is the following with no output file

Code:

SBS: Top Gear
Index name: .
Mon Mar 3 19:30:00 2008 - Mon Mar 3 20:35:00 2008
playtime: 65:00 recording size: 2359.5 MB


also received the following error a couple of times

Code:
'@' outside of string in unpack at /usr/lib/perl5/vendor_perl/Beyonwiz/Recording/Header.pm line 477.



Am I doing something wrong?

Thanks
Jeremy

The -I option is intended to name the folder/directory where the .tvwiz folders are stored, not the name of the .tvwiz folder itself. It should be used something like:Code:
getWizPnP -tv -I folder/containing/my/recordings 'Top Gear#Mon Mar 3'


However, there is another bug that stops the -I option from working properly.

Can you give me some examples of when you got the '@' outside of string message - it indicates that the header file it read was too short. Do you get the error only with the -I option or also when you are accessing the Beyonwiz?

Discussion of getWizPnP is probably better off in the getWizPnP - a command-line WizPnP uploader topic in Software Developers. Users are most welcome
_________________
Peter
Hi Peter,
OK, I'll post my reply here... :)

I tried this and it worked a treat

Code: Select all

getwiz -tv -I ./'Top Gear_Mar.3.2008_19.30.tvwiz' 'Top Gear#Mon Mar  3'
As most Twiz collections are in a single folder could iis it really nessesary to have to specify the folder name and file name? If you use the getwiz command on the Beyonwiz without a filename it just processes everything in the folder?

Also found it doesn't automatically name the file with the date like when copying directly from the Wiz?

I'll get some more info together on what caused the error..

Great tool. Thanks!

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

Post by prl » Sun May 11, 2008 11:51

Hi, Jeremy. The idea of the -I option is to tell getWizPnP both that you want to access a local collection of recordings, rather than recordings on a Beyonwiz, and to tell it where the collection of recordings is. The collection is meant to resemble the recordings folder on the Beyonwiz (with some added checks to ignore stuff that doesn't look like Beyonwiz recordings). It's not intended to name a single folder that contains one Beyonwiz recording. It's a coincidence that what you've done actually works, but it's just as well, because its intended operation is broken :)

With the fix for the intended operation of -I your usage will work, but I won't promise that it always will. What's supposed to work for your case is:

Code: Select all

getwiz -tv -I . 'Top Gear#Mon Mar  3'
It doesn't work in the released version, but I hope to have a fix out later today (I'm testing the fix at the moment). I'm also going to add some more testing before decoding the header files.

Thanks for the heads-up on the bugs.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

jrx
Master
Posts: 151
Joined: Thu Nov 15, 2007 11:31
Location: Perth, WA, Australia (DP-P1 + DP-H1)

Post by jrx » Sun May 11, 2008 12:06

Thanks Ian, I'll give it a try.

One suggestion. With the date stamps in the file names it would be good to have the option of using the dates in YYMMDD format to make sorting by file name more logical.
eg 'Top Gear 080304'

jrx
Master
Posts: 151
Joined: Thu Nov 15, 2007 11:31
Location: Perth, WA, Australia (DP-P1 + DP-H1)

Post by jrx » Sun May 11, 2008 14:00

prl wrote:Hi, Jeremy. The idea of the -I option is to tell getWizPnP both that you want to access a local collection of recordings, rather than recordings on a Beyonwiz, and to tell it where the collection of recordings is. The collection is meant to resemble the recordings folder on the Beyonwiz (with some added checks to ignore stuff that doesn't look like Beyonwiz recordings). It's not intended to name a single folder that contains one Beyonwiz recording. It's a coincidence that what you've done actually works, but it's just as well, because its intended operation is broken :)

With the fix for the intended operation of -I your usage will work, but I won't promise that it always will. What's supposed to work for your case is:

Code: Select all

getwiz -tv -I . 'Top Gear#Mon Mar  3'
It doesn't work in the released version, but I hope to have a fix out later today (I'm testing the fix at the moment). I'm also going to add some more testing before decoding the header files.

Thanks for the heads-up on the bugs.
Hi Peter,
When I tried listing . as the -I parameter it failed with the following:

Code: Select all

# getwiz -v -I ./ 'Top Gear 080405'
SBS: Top Gear 080405
    Index name: Top Gear 080405_Apr.5.2008_19.30.tvwiz
    Sat Apr  5 19:30:00 2008 - Sat Apr  5 20:45:00 2008
    playtime:   75:00    recording size:   2725.9 MB
Trunc:hdr_data len=0
Can't get file index for Top Gear 080405_Apr.5.2008_19.30.tvwiz
|==================================================| 100% 0/0MB
If I set the -I path to the full name of the container directory it works fine.

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

Post by prl » Sun May 11, 2008 15:05

jrx wrote:
prl wrote:...
What's supposed to work for your case is:

Code: Select all

getwiz -tv -I . 'Top Gear#Mon Mar  3'
It doesn't work in the released version, but I hope to have a fix out later today (I'm testing the fix at the moment). I'm also going to add some more testing before decoding the header files.

Thanks for the heads-up on the bugs.
Hi Peter,
When I tried listing . as the -I parameter it failed with the following:

Code: Select all

# getwiz -v -I ./ 'Top Gear 080405'
SBS: Top Gear 080405
    Index name: Top Gear 080405_Apr.5.2008_19.30.tvwiz
    Sat Apr  5 19:30:00 2008 - Sat Apr  5 20:45:00 2008
    playtime:   75:00    recording size:   2725.9 MB
Trunc:hdr_data len=0
Can't get file index for Top Gear 080405_Apr.5.2008_19.30.tvwiz
|==================================================| 100% 0/0MB
If I set the -I path to the full name of the container directory it works fine.
Yes, I know, it doesn't work as it's supposed to. See the emphasised bit from my last post.
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun May 11, 2008 20:15

I've posted a new version of getWizPnp, 0.2a, that fixes Jeremy's bug.

Jeremy, your workaround for doing a local conversion to a .ts file won't work any more. You'll have to do it the "official" way now :)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

jrx
Master
Posts: 151
Joined: Thu Nov 15, 2007 11:31
Location: Perth, WA, Australia (DP-P1 + DP-H1)

Post by jrx » Sun May 11, 2008 21:11

prl wrote:I've posted a new version of getWizPnp, 0.2a, that fixes Jeremy's bug.

Jeremy, your workaround for doing a local conversion to a .ts file won't work any more. You'll have to do it the "official" way now :)
Hi Peter,
Just downloaded and tested it and it now works as documented.

Code: Select all

# getwiz -tvd -I ./ 'Top Gear 080128'
SBS: Top Gear 080128
    Index name: Top Gear 080128_Jan.28.2008_19.30.tvwiz
    Mon Jan 28 19:30:00 2008 - Mon Jan 28 20:30:00 2008
    playtime:   60:00    recording size:   2192.2 MB
|==================================================| 100% 2192/2192MB
Keep up the good work!

Thanks
Jeremy

PS. How's the delete switch coming along?.. :)

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

Post by prl » Sun May 11, 2008 22:41

jrx wrote:,,,
Just downloaded and tested it and it now works as documented.
...
PS. How's the delete switch coming along?.. :)
I'm glad I got it fixed! Stupid error, as usual.

Delete wouldn't be hard to implement, but I have some concerns about side-effects on the BW. Deleting a recording that's currently being viewed is likely to cause the BW a bit of indigestion :) As far as I know there's no flag available through WizPnP to tell if a recording is being played.

I will try it to see how nasty it gets. :twisted:
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: 32705
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Post by prl » Sun May 11, 2008 23:10

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

jrx
Master
Posts: 151
Joined: Thu Nov 15, 2007 11:31
Location: Perth, WA, Australia (DP-P1 + DP-H1)

Post by jrx » Mon May 12, 2008 10:21

Hi Peter,
I was wondering what happens with the audio on a HD conversion?
One of the files I converted was HD and when I played it back through the TV audio there wasn't any audio. I didn't check if there was any DD audio on the optical output. This file plays fine on the TV directly on the BW.
Is this a problem with the conversion, ow BW playback?

Thanks
Jeremy

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

Post by prl » Mon May 12, 2008 10:59

jrx wrote:Hi Peter,
I was wondering what happens with the audio on a HD conversion?
One of the files I converted was HD and when I played it back through the TV audio there wasn't any audio. I didn't check if there was any DD audio on the optical output. This file plays fine on the TV directly on the BW.
Is this a problem with the conversion, ow BW playback?

Thanks
Jeremy
getWizPnP conversion to .ts doesn't do any "conversion", it just pastes files together. Losing audio (playback over the net?) is a symptom that the net isn't feeding the BW fast enough, and it's usually more of a problem for HD and/or W-LAN transfer.

getWizPnP doesn't even have any way of telling whether a file is HD or SD.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

jrx
Master
Posts: 151
Joined: Thu Nov 15, 2007 11:31
Location: Perth, WA, Australia (DP-P1 + DP-H1)

Post by jrx » Fri May 23, 2008 10:53

Hi Peter,
How's the investigation on a delete option going?

Thanks
Jeremy

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

Post by prl » Fri May 23, 2008 11:26

jrx wrote:Hi Peter,
How's the investigation on a delete option going?

Thanks
Jeremy
On hold while I've been working on BWFWTools. The main thing I want to test before doing anything is what happens if you delete a recording while it's being played.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

taway
Apprentice
Posts: 17
Joined: Tue Apr 08, 2008 23:14

Post by taway » Sat May 31, 2008 23:01

Is the performance of fetching a file supposed to be significantly worse via WizPNP? I can usually get ~3Mb/s onto a samba share (which is pretty poor but anyway) but I get about 100Kb/s using WizPNP :(

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

Post by prl » Sun Jun 01, 2008 08:11

taway wrote:Is the performance of fetching a file supposed to be significantly worse via WizPNP? I can usually get ~3Mb/s onto a samba share (which is pretty poor but anyway) but I get about 100Kb/s using WizPNP :(
I just timed an ~800MB getWizPnP transfer, and I got 1.7MB/s from my DP-S1 (firmware 1.05.243 beta). I usually get ~2.7-2.8MB/s using Windows Share copying from the BW. I got comparable speed using Eric Fry's WizMac (implemented Mac Cocoa framework, rather than the Perl scripting in getWizPnP).

The difference in speed I get is probably due to network throttling by the BW, because I only pay attention to the Windows Share transfer speed when I'm transferring while in the File Player menu (no video active), while live video is usually showing when I transfer using getWizPnP. I don't know why you're getting such abysmal performance. What hardware/OS are you on? What was the BW doing while you were transferring?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

Post Reply

Return to “Software Developers”