Home of the Squeezebox™ & Transporter® network music players.
Page 69 of 133 FirstFirst ... 1959676869707179119 ... LastLast
Results 681 to 690 of 1327
  1. #681
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,725
    Some more information, not really progress unfortunately

    - I've tried adding SO_KEEPALIVE to maintain socket at the TCP level => no impact
    - Confirming the above, I've carefully logged the streaming process between LMS and the player: the player does not do "long suspend" of the data request due to some buffering. There is a regular flow of data, instead it's LMS that closes the socket with the player
    - More interesting and probably why I did not see that before: this does *not* seem to happen on my Windows version, where I did the tests before. I've now listened to more than one block without interruption, which has not happened *at all* today on my Pi3: all blocks have been interrupted.
    - I've looked more at the option to hide the reconnect inside the HTTP/S core logic and I don't think it's possible. The socket created when starting a song is used all the way up by the SongController, so if it closes, it can be re-open "in the background". The re-opening would have to be done very high, in the StreamingController.

    [edit]: 2 1/2 block-in and still not interruption, definitively a difference. A question for Michael: in the HTTP2.pm of LMS, there is the following in sysread
    Code:
    	if (main::ISWINDOWS && !$readLength) {
    		$! = EWOULDBLOCK;
    	}
    I know the EAGAIN is not EWOULDBLOCK on Windows, is this because of that? Reading the Perl IO::Socket::SSL documentation, it seems that when SSL cannot return on sysread, it sets EWOULDBLOCK on all platforms, so I don't understand. Could there be something here? Like when SSL is in the middle of a handshake re-negotiation and LMS asks for data at that moment (sort of race condition), on Linux we have 0 bytes but $! is set to EAGAIN and that causes a problem.
    Code:
    With SSL, handshakes might occur at any time, even within an established connection. In these cases it is necessary to finish the handshake before you can read or write data. This might result in situations where you want to read but must first finish the write of a handshake or where you want to write but must first finish a read. In these cases $! is set to EAGAIN like expected, and additionally $SSL_ERROR is set to either SSL_WANT_READ or SSL_WANT_WRITE. Thus if you get EWOULDBLOCK on a SSL socket you must check $SSL_ERROR for SSL_WANT_* and adapt your event mask accordingly.
    And looking at Pipeline.pm (if this is the code used to get data from the webserer)
    Code:
    		my $socketReadlen = $source->sysread($pendingBytes, $chunksize);
    
    			if (!$socketReadlen) {
    				if (defined $socketReadlen) {
    					# EOF
    					main::INFOLOG && $log->info("EOF on source stream");
    					undef $source;
    					delete ${*$self}{'pipeline_source'};
    					$writer->close();
    					last STUFF_PIPE;
    				} elsif ($! == EWOULDBLOCK) {
    					last STUFF_PIPE;		
    				} else {
    					return undef; # reflect error to caller
    				}
    			}
    or Source.pm
    Code:
    			if (!defined($readlen)) { 
    				if ($! == EWOULDBLOCK) {
    					# $log->debug("Would have blocked, will try again later.");
    					if ($callback) {
    						# This is a hack but I hesitate to use isa(Pileline) or similar.
    						# Suggestions for better, efficient implementation welcome
    						Slim::Networking::Select::addRead(${*$fd}{'pipeline_reader'} || $fd, sub {_wakeupOnReadable(shift, $client);}, 1);
    					}
    					return undef;	
    				} elsif ($! == EINTR) {
    					main::DEBUGLOG && $log->debug("Got EINTR, will try again later.");
    					return undef;
    				} elsif ($! == ECHILD) {
    					main::DEBUGLOG && $log->debug("Got ECHILD - will try again later.");
    					return undef;
    				} else {
    					main::DEBUGLOG && $log->debug("readlen undef: ($!) " . ($! + 0));
    					$endofsong = 1; 
    				}	
    			} elsif ($readlen == 0) { 
    				main::DEBUGLOG && $log->debug("Read to end of file or pipe");  
    				$endofsong = 1;
    			} else {
    				# too verbose
    				# $log->debug("Read $readlen bytes from source");
    			}
    		}
    Then, when SSL sysread returns EAGAIN (SSL handshake happening again, as it should at any time in SSL) which should be equal to EWOULDBLOCK, but if not ... then we exit, except in Windows?
    Last edited by philippe_44; 2019-04-07 at 23:07.
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  2. #682
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,725
    No joy in that direction, EAGAIN and EWOULDBLOCK are the same, but I now have a pretty clear additional information. Ran sessions in // during the night on Windows x64 + Perl 5.14, Linux x86 +Perl 5.20+openssl 1.0.1f, and Armhf (Pi3B+) + Perl 5.24 + openssl 1.1.0f.

    - this is not player related, the ssl socket closes on EoF
    - No (0%) block failed on Windows and Linux x86
    - All (100%) blocks failed at various level (let's say at least >5mins) on the Pi

    So ... it's not a RP problem, but a general problem with long ssl session. I don't know more at that time
    Last edited by philippe_44; 2019-04-08 at 12:18.
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  3. #683
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,228
    Quote Originally Posted by philippe_44 View Post
    No joy in that direction, EAGAIN and EWOULDBLOCK are the same, but I now have a pretty clear additional information. Ran sessions in // during the night on Windows x64 + Perl 5.14, Linux x86 +Perl 5.20+openssl 1.0.1f, and Armhf (Pi3B+) + Perl 5.24 + openssl 1.1.0f.

    - this is not player related, the ssl socket closes on EoF
    - No (0%) block failed on Windows and Linux x86
    - All (100%) blocks failed at various level (let's say at least >5mins) on the Pi

    So ... it's not a RP problem, but a general problem with long ssl session. I don't know more at that time
    This sounds similar to an issue I found with some podcasts which would stop playing after 5-7 minutes.
    https://forums.slimdevices.com/showthread.php?p=934245

    Sent from my SM-G900F using Tapatalk

  4. #684
    Member
    Join Date
    Aug 2009
    Location
    New Providence, NJ
    Posts
    33
    Quote Originally Posted by philippe_44 View Post
    No joy in that direction, EAGAIN and EWOULDBLOCK are the same, but I now have a pretty clear additional information. Ran sessions in // during the night on Windows x64 + Perl 5.14, Linux x86 +Perl 5.20+openssl 1.0.1f, and Armhf (Pi3B+) + Perl 5.24 + openssl 1.1.0f.

    - this is not player related, the ssl socket closes on EoF
    - No (0%) block failed on Windows and Linux x86
    - All (100%) blocks failed at various level (let's say at least >5mins) on the Pi

    So ... it's not a RP problem, but a general problem with long ssl session. I don't know more at that time
    Philippe, I very much appreciate the effort on your part. I do find it interesting that for you, Windows is the stablest platform. As previously mentioned, my LMS is running on Win 10-64 and I can't get through more than 1 or 2 tracks without interruption, never mind a whole block. Let me know if there's anything I can do to assist in this endeavor.

  5. #685
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,725
    Quote Originally Posted by robanglin View Post
    Philippe, I very much appreciate the effort on your part. I do find it interesting that for you, Windows is the stablest platform. As previously mentioned, my LMS is running on Win 10-64 and I can't get through more than 1 or 2 tracks without interruption, never mind a whole block. Let me know if there's anything I can do to assist in this endeavor.
    We would need more data points, but I’m wondering if this is not linked to the ssl stack version and/or default configuration. Do you use LMS default Perl?
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  6. #686
    Member
    Join Date
    Aug 2009
    Location
    New Providence, NJ
    Posts
    33
    Quote Originally Posted by philippe_44 View Post
    We would need more data points, but I’m wondering if this is not linked to the ssl stack version and/or default configuration. Do you use LMS default Perl?
    I would guess so since I have not made any mods on that front.

  7. #687
    Member
    Join Date
    Aug 2009
    Location
    New Providence, NJ
    Posts
    33
    Quote Originally Posted by philippe_44 View Post
    We would need more data points, but I’m wondering if this is not linked to the ssl stack version and/or default configuration. Do you use LMS default Perl?
    Name:  LMSVersion.jpg
Views: 184
Size:  25.6 KB

  8. #688
    Senior Member left channel's Avatar
    Join Date
    Mar 2018
    Location
    Silicon Valley
    Posts
    394
    I very rarely experience the problem. Almost never. And I listen to RP a lot.

    My Perl and etc. versions:

    Logitech Media Server Version: 7.9.2 - 0.9.20181207git1543258616 @ Fri Dec 7 12:03:59 EST 2018
    Operating system: Red Hat - EN - utf8
    Platform Architecture: x86_64-linux
    Perl Version: 5.24.3 - x86_64-linux-thread-multi
    Audio::Scan: 0.95
    IO::Socket::SSL: 2.038
    Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
    Total Players Recognized: 10
    LMS: SGC microJukebox running Sonicorbiter OS
    Control apps: Squeezelite-X on Win 10; Squeezer or Material web app on Android
    Players: Duet, Touch (two), Mac SqueezePlay, Win Squeezelite-X on laptop and HTPC

  9. #689
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,725
    My IO::Socket::SSL on Windows is 1.44 and 2.044 on Linux arm...
    I'm not very familiar with they Windows-based Perl installation, but I'm wondering how you end up having a much more recent IO::Socket::SSL. I thought all these packages were part of the LMS built-in Perl distr
    Last edited by philippe_44; 2019-04-08 at 21:10.
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  10. #690
    Senior Member left channel's Avatar
    Join Date
    Mar 2018
    Location
    Silicon Valley
    Posts
    394
    Quote Originally Posted by philippe_44 View Post
    My IO::Socket::SSL on Windows is 1.44 and 2.044 on Linux arm...
    I'm not very familiar with they Windows-based Perl installation, but I'm wondering how you end up having a much more recent IO::Socket::SSL. I thought all these packages were part of the LMS built-in Perl distr
    My LMS installation is packaged with the Sonicorbiter OS, if that helps.
    LMS: SGC microJukebox running Sonicorbiter OS
    Control apps: Squeezelite-X on Win 10; Squeezer or Material web app on Android
    Players: Duet, Touch (two), Mac SqueezePlay, Win Squeezelite-X on laptop and HTPC

Posting Permissions

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