Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 45
  1. #11
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    14,927
    Quote Originally Posted by marcoc1712 View Post
    Attached is the zipped log, produced with C-3PO plugin in debug (verbose) mode, hope you don't care.
    Thanks but there doesn't seem to be any of the socketwrapper messages ?

    The juxtaposition of LMS log messager with socketwrapper debug messages is important as it can indicate what is happening - possibly which process is the root cause of the block.
    Last edited by bpa; 2016-09-28 at 15:44.

  2. #12
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    14,927
    A possible way to check to see if your problem is with blocking. You could simplify your c3po test program and do two separate tests.

    1. Loop just reading data from stdin and then throw data away. Log each chunk read.
    2. Loop just writing 64kb chunks of binary zero to stdout. Ignore stdin. I think socketwrapper will eventually stall as data from LMS is not read but in that time many kbs should have been written to stdoutand it should also show LMS throttling the flow.

    To change i/o to non blocking use the blocking function. Example - this would make STDIN non blocking but need to check if it works on Windows.
    Code:
    STDIN->blocking(0);
    my $data;
    while (1) {
        my $rc = sysread( STDIN, $data, 1024 );
        if ( defined $rc ) {
            if ( $rc > 0 ) {
                print $data,"\n";
            }
            else {
    # could add a delay here to that CPU can be released to other tasks.
            }
        }
        elsif ( $! == EWOULDBLOCK ) {
            next;
        }
        else {
            die "sysread error:$!";
        }
    };
    However you would need to modify your code to add delays or some sort blocking or otherwise the programm will use 100% CPU as above example will do.

    edit:

    Looking at LMS code there is this routine called blocking which indicates at least for sockets/pipes Windows using Activestate Perl "blocking" won't work and you'll need to use ioctl and FIONBIO( 0x8004667e ) function. I don't have a Perl development Windows system so I can't help. Perl and Windows don't go well together - I didn't write socketwrapper and it was initially written to overcome a deficiency in Perl on Windows.
    Code:
    sub blocking {   
    	my $sock = shift;
    
     	return $sock->blocking(@_) unless main::ISWINDOWS;
    
    	my $nonblocking = $_[0] ? "0" : "1";
    	my $retval = ioctl($sock, 0x8004667e, \$nonblocking);
    
    	if (!defined($retval) && $] >= 5.008) {
    		$retval = "0 but true";
    	}
    
    	return $retval;
    }
    Last edited by bpa; 2016-09-29 at 01:56. Reason: Added FIONBIO definition.

  3. #13
    Senior Member
    Join Date
    Dec 2009
    Location
    Albinea (Bologna Area) Italy
    Posts
    480
    Quote Originally Posted by bpa View Post
    Thanks but there doesn't seem to be any of the socketwrapper messages ?

    The juxtaposition of LMS log messager with socketwrapper debug messages is important as it can indicate what is happening - possibly which process is the root cause of the block.
    SW do not write to the log, here the complete output on the screen.

    serverLog.zip


    C-3PO is used also when reading form files and in that case work without problem in windows too, the command is exactly the same, but in stead of "-" as last parameter there is a real URI, but socketWrapper is not involved in that case. LMS is descerning and only call Socketwraper when is a 'real' pipe.

    Where I'll have to put the #PIPE# token in the command?
    __________________________________________________ __________
    SB+, Klimo Merlino + Kent Gold, Monitor Audio Studio 20 Gold SE+, Klimo reference and DIS Interconnect.

  4. #14
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    14,927
    Quote Originally Posted by marcoc1712 View Post
    SW do not write to the log, here the complete output on the screen.

    serverLog.zip
    I desciribed the setup with a command promtp window hoe to get a socketwrapper log - there is no point trying to debug socketwrapper withtout socketwrapper log.



    LMS is descerning and only call Socketwraper when is a 'real' pipe.
    I know but the Perl function that is used on Linux doesn't worjk on Windows becuase of Windows implementation of pipes.

    Where I'll have to put the #PIPE# token in the command?
    I don't know perhaps it is not even necessary. I was pointing out there are differences since I don't understand what you are trying to do - I thought it was a normal plugin and you were using a conf file.

    Please run suggested test with just reading stdin and discard output and also 2nd test but I need SW logs.

    I can't help without socketwrapper log intermixed with LMS log - this can only be done using command prompt and set command prompt properties to very big window.

  5. #15
    Senior Member
    Join Date
    Dec 2009
    Location
    Albinea (Bologna Area) Italy
    Posts
    480
    Quote Originally Posted by bpa View Post
    A possible way to check to see if your problem is with blocking. You could simplify your c3po test program and do two separate tests.

    1. Loop just reading data from stdin and then throw data away. Log each chunk read.
    2. Loop just writing 64kb chunks of binary zero to stdout. Ignore stdin. I think socketwrapper will eventually stall as data from LMS is not read but in that time many kbs should have been written to stdoutand it should also show LMS throttling the flow.

    To change i/o to non blocking use the blocking function. Example - this would make STDIN non blocking but need to check if it works on Windows.
    Code:
    STDIN->blocking(0);
    my $data;
    while (1) {
        my $rc = sysread( STDIN, $data, 1024 );
        if ( defined $rc ) {
            if ( $rc > 0 ) {
                print $data,"\n";
            }
            else {
    # could add a delay here to that CPU can be released to other tasks.
            }
        }
        elsif ( $! == EWOULDBLOCK ) {
            next;
        }
        else {
            die "sysread error:$!";
        }
    };
    However you would need to modify your code to add delays or some sort blocking or otherwise the programm will use 100% CPU as above example will do.

    edit:

    Looking at LMS code there is this routine called blocking which indicates at least for sockets/pipes Windows using Activestate Perl "blocking" won't work and you'll need to use ioctl and FIONBIO( 0x8004667e ) function. I don't have a Perl development Windows system so I can't help. Perl and Windows don't go well together - I didn't write socketwrapper and it was initially written to overcome a deficiency in Perl on Windows.
    Code:
    sub blocking {   
    	my $sock = shift;
    
     	return $sock->blocking(@_) unless main::ISWINDOWS;
    
    	my $nonblocking = $_[0] ? "0" : "1";
    	my $retval = ioctl($sock, 0x8004667e, \$nonblocking);
    
    	if (!defined($retval) && $] >= 5.008) {
    		$retval = "0 but true";
    	}
    
    	return $retval;
    }
    Already tried that, The first will not work, just becouse the sysread blocks, tried the solution in network.pm as one of the first, could not remembre why but it did not work for me, I'll have another try.

    Mybe move to C is the simplest way, I was loking for FAAD sources in the slimserver git hub repository, but i could not fount it, could you please point me to it?

    thanks.

    Marco
    __________________________________________________ __________
    SB+, Klimo Merlino + Kent Gold, Monitor Audio Studio 20 Gold SE+, Klimo reference and DIS Interconnect.

  6. #16
    Senior Member
    Join Date
    Dec 2009
    Location
    Albinea (Bologna Area) Italy
    Posts
    480
    Quote Originally Posted by bpa View Post
    I can't help without socketwrapper log intermixed with LMS log - this can only be done using command prompt and set command prompt properties to very big window.
    The second file I've posted (ServerLog.txt) is the hardcopy of the screen with socketwrapper messages, is'nt that enough for you? If so, my fault, but I could not understand what are you asking me to do.

    I'm working on the symplified C-3PO version and I'll give you the logs (screen hard copy) ASAP.
    __________________________________________________ __________
    SB+, Klimo Merlino + Kent Gold, Monitor Audio Studio 20 Gold SE+, Klimo reference and DIS Interconnect.

  7. #17
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    14,927
    Quote Originally Posted by marcoc1712 View Post
    The second file I've posted (ServerLog.txt) is the hardcopy of the screen with socketwrapper messages, is'nt that enough for you? If so, my fault, but I could not understand what are you asking me to do.

    I'm working on the symplified C-3PO version and I'll give you the logs (screen hard copy) ASAP.
    Sorry I rushed and ended opening up the previous log you sent. I'll have a look at log later today.

  8. #18
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    14,927
    Looking at socketwrapper source code. It uses a buffer size of 8k - if any of your previous test didn't use a buffer size smaller then 8kb then you should try with say 4kb rather than 64kb.

  9. #19
    Senior Member
    Join Date
    Dec 2009
    Location
    Albinea (Bologna Area) Italy
    Posts
    480
    Quote Originally Posted by bpa View Post
    Sorry I rushed and ended opening up the previous log you sent. I'll have a look at log later today.
    no porbs.

    Here the log of C-3P0 Just reading from STDIN and NOT writing to STDOUT:

    related code is here:

    Code:
                    Plugins::C3PO::Logger::infoMessage(
    				"Start copy from STDIN");
    		while (
    			sysread (STDIN, $buffer, 65536)	# read in (up to) 64k chunks, write
    			#and syswrite STDOUT, $buffer	# exit if read or write fails
    			) {
    				Plugins::C3PO::Logger::infoMessage(
    				"copied 64Kb chunk from STDIN");
    		}
    		if ($!){		
    
    			Plugins::C3PO::Logger::errorMessage(
    				"Problem writing body from STDIN: $!");
    		} else{
    		
    			Plugins::C3PO::Logger::infoMessage(
    				"end copy from STDIN");
    		}		
    		flush STDOUT;
    I kept the program structure in order to produce the (separate) log, was much simpler than deal with stderr... Please see C-3PO.zip.
    Attached Files Attached Files
    __________________________________________________ __________
    SB+, Klimo Merlino + Kent Gold, Monitor Audio Studio 20 Gold SE+, Klimo reference and DIS Interconnect.

  10. #20
    Senior Member
    Join Date
    Dec 2009
    Location
    Albinea (Bologna Area) Italy
    Posts
    480
    Quote Originally Posted by bpa View Post
    Looking at socketwrapper source code. It uses a buffer size of 8k - if any of your previous test didn't use a buffer size smaller then 8kb then you should try with say 4kb rather than 64kb.
    same behaviour, here the scrren copy.
    Attached Files Attached Files
    __________________________________________________ __________
    SB+, Klimo Merlino + Kent Gold, Monitor Audio Studio 20 Gold SE+, Klimo reference and DIS Interconnect.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •