[Announce] Radio Paradise Lossless Streaming (Plugin v2)

[philippe_44]

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

	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.

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)

		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

			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?

[philippe_44]

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

[slartibartfast]

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

[robanglin]

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.

[philippe_44]

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?

[robanglin]

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.

[robanglin]

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?

[left channel]

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

[philippe_44]

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

[left channel]

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.