Ping Ryan

Ryan, For future reference, although technically wireless networking is also 'ethernet', we typically use 'ethernet' to describe the RJ45 wired network connection.

Whether you're using USB or SD card shouldn't make any difference at all: they're just different media mounted under TinySBS' music folder.

Did you plug in the SD card while USB was plugged in at the same time? This is currently not supported. Either or, first wins. Is this what you're seeing?

Felix - haven't you been working on some bug re. playback without network?

If I recall correctly the two scenarios we discussed regarding listening to TinySC without network were:

- What Ryan describes in paragraph two (i.e. listening to TinySC and then network goes away).
- Setup and listening to TinySC without network at all

Felix - may I ask you to investigate this one? Thanks!

to clarify Chris's comment I was using a wired connection which I then removed it to see I could then switch to on board Tiny SC content.

steps to reproduce
connected via wired Ethernet SD card installed on the unit
connect and play from  tinySC on another unit.
clear playlist/ stop playback 
disconnect Ethernet
switch library    get connection problem message
select continue without network
select itself for library
it fails to find the library

I retried multiple times without success

Eject the SD card and reinserting it waited for squeezebox server to finish discovering files. 
I was able to select and connect to the library after 4 attempts

last visited in fw8467

Proposed patch to make SlimProto state (UNCONNECTED, CONNECTING, CONNECTED) more reliable. Right now it can oscillate between CONNECTING and CONNECTED even though it isn't connected at all. Alan rightfully urges that all isConnected() calls need to be checked.

Index: SlimProto.lua
===================================================================
--- SlimProto.lua	(revision 8467)
+++ SlimProto.lua	(working copy)
@@ -542,6 +542,8 @@
 			end
 		end
 
+		self.state = CONNECTED
+
 		-- send acknowledgement
 		if not statusSent then
 			self:sendStatus(opcode)
@@ -595,7 +597,6 @@
 
 	-- connect
 	self.socket:t_connect()
-	self.state = CONNECTED
 	self.txqueue = {}
 
 	-- SC and SN ping the player every 5 and 30 seconds respectively.
@@ -610,7 +611,7 @@
 		(status.isStreaming or status.isLooping)
 
 	-- send helo packet
-	self:send(self.heloPacket)
+	self:send(self.heloPacket, true)
 end
 
 
@@ -700,8 +701,8 @@
 
 -- Sent packet. Returns false is the connection is disconnected and the
 -- packet can't be sent, otherwise it returns true.
-function send(self, packet)
-	if self.state ~= CONNECTED then
+function send(self, packet, force)
+	if not force and self.state ~= CONNECTED then
 		return false
 	end

Created attachment 6527 [details]
More evidence of issues related to incorrect isConnected() status

IsConnected() is used in various places but if the status is wrong (i.e. CONNECTED) but in reality there is no connection (ethernet cable removed) subsequent code fails miserably.

Even with my proposed patch (comment #9) there still is an issue right after the connection (SlimProto) goes away.

SlimProto uses two timeouts, a read timeout (10 seconds) and a write timeout (35 seconds). That means if after the network goes down and the next packet is trying to send (write) something it takes 35 seconds before the problem is detected and the connection status changes from CONNECTED to CONNECTING.

If during that timeout time any part of our code tries use this (actually dead) connection an relies on isConnected() it is most likely doing the wrong thing.

Created attachment 6529 [details]
event id=nil issue when switching between libraries 

Some event id=nil Comet issues I do not understand at all.

Note: I did not even disconnect the network in this case. I only switched between libraries (BigSC, TinySC and mysb.com).

Highlights from the log regarding datestatus subscription:

- 11:16:35 - subscribe to mysb.com (I think) with a valid event id = 21
- 11:16:35 - unsubscribed from Touch, event id = 15
- 11:16:35 - subscribe to mysb.com, event id = 21
- 11:16:37 - response from mysb.com failed due to invalid event id

I fail to understand why the datestatus event id could be invalid in this case.

7.5.0 r8504

Comment on attachment 6529 [details]
event id=nil issue when switching between libraries 

Opened a new bug 15724 dealing with switching between music libraries (but not related to network going away).

This bug should only be about isConnected() not being accurate.

Index: jive/slim/LocalPlayer.lua
===================================================================
--- jive/slim/LocalPlayer.lua	(revision 8506)
+++ jive/slim/LocalPlayer.lua	(working copy)
@@ -14,6 +14,7 @@
 
 local SlimProto      = require("jive.net.SlimProto")
 local Playback       = require("jive.audio.Playback")
+local Timer          = require("jive.ui.Timer")
 
 local jiveMain       = jiveMain
 local debug          = require("jive.utils.debug")
@@ -201,17 +202,46 @@
 
 		server:addLocallyRequestedServer(server)
 		self.slimproto:connect(server)
-	else
+	end
+
+
+	if self:isConnected() then
+		-- First try switching via current server
 		log:info('connectToServer(): switching localPlayer to server', server)
 		local ip, port = server:getIpPort()
 
 		server:addLocallyRequestedServer(server)
-		self:send({'connect', ip}, true)
+
+		-- If switch not successful - try connecting after 5 seconds
+		self.checkConnectTimer = Timer( 5000,
+			function()
+				log:info('connectToServer(): connecting localPlayer to server', server, ' via slimproto')
+
+				-- close any previous connection
+				self.slimproto:disconnect()
+
+				server:addLocallyRequestedServer(server)
+				self.slimproto:connect(server)
+			end,
+			true -- only once
+		)
+		self.checkConnectTimer:start()
+
+		self:call({'connect', ip}, true)
 	end
 	return true
 
 end
 
+
+function _process_connect(self, event)
+	-- Stop connect timer if switch was successful
+	if self.checkConnectTimer and self.checkConnectTimer:isRunning() then
+		self.checkConnectTimer:stop()
+	end
+end
+
+
 function connectIp(self, serverip, slimserverip)
 	self.slimproto:disconnect()
 	self.slimproto:connectIp(serverip, slimserverip)

Comment #15 contains an untested patch to try to connect to new server after 5 seconds if switching to new server fails due to current server not available anymore.

Felix, Ryan tells me this is now largely working.  What work is left to mark this as 'fixed?'

Alan to review the fix.

Created attachment 6556 [details]
Proposed patch

Only have SlimProto:isConnecting() return true when properly connected, and have LocalPlayer use a more robust test to determine if server switching can be accomplished by the currently-connected server.

 == Auto-comment from SVN commit #8556 to the  repo by ayoung ==
 == https://svn.slimdevices.com/?view=revision&revision=8556 ==

bug 15633: cannot switch to SD card content without network 
Only have SlimProto:isConnecting() return true when properly connected, and
have LocalPlayer use a more robust test to determine if server switching can be
accomplished by the currently-connected server.

Created attachment 6557 [details]
Proposed fail-fast patch

Felix, Ben, What do you think about this patch to make connection-failure for local players be notified more quickly, rather than having to time out?

Update hours

Alan - I am not sure about the very last change from self:connect() to self:_connectToAddr(). Isn't going through self:connect() meant to pickup server IP address changes in case the server, the player is connected to, goes away and later when it comes back and has a different IP address that would get noted in self.lastServerip?

I made the change so that the reset of "self.connectionFailed = false" that now occurs in connect() and connectIp() would not happen when retrying a connection after a failure. In the case that connect() is called with no arguments, as was the case from the retry-timer callback, effectively all it did was;

	local serverip = self.serverip
	_connectToAddr(self, serverip)
	
My change has the timer callback do:

	self:_connectToAddr(self.serverip)

instead of:

	self:connect()
	
I think these should be equivalent.

You are certainly correct about this. I mistakenly assumed 'server' would be defined from the self: part, but that is clearly not the case. So, yes, I think your change to use _connectToAddr() instead of connect() should be fine.

 == Auto-comment from SVN commit #8561 to the  repo by ayoung ==
 == https://svn.slimdevices.com/?view=revision&revision=8561 ==

bug 15633: cannot switch to SD card content without network 
Make connection-failure for local players be notified more quickly - as
soon as it is detected - rather than having to time out after 20s.

As FW 8563 this is NOT! working every time.

It takes two tries of inserting the SD card before it is fully recognized.

Steps to reproduce

Power up unit connected with wired Ethernet12, Connect to Squeeze box server, Play some music.

Disconnect Ethernet, Insert SD card, check squeezebox server status, wait for file discovery complete, continue without network, and switch library to TinySC local SD card, 
Indicated library changes from local Squeezebox server to TinySC  SD card. 
Select my music, attempt various combination's of try again and switch library to gain access to music content on the SD card without success.

Go to home menu, eject the SD card, 
Reinsert the SD card, Check Squeezebox server status, wait for files discovery to complete.

Select my music, browse and select music and play. SUCCESS! 

The first attempt installing the SD card gets the library to change and once changed the second try inserting the SD card lets you access it.

Actually I think that it is inconsistent. Sometimes it works, sometimes not.

*** Bug 15724 has been marked as a duplicate of this bug. ***

*** Bug 15775 has been marked as a duplicate of this bug. ***

*** Bug 15627 has been marked as a duplicate of this bug. ***

 == Auto-comment from SVN commit #8583 to the jive repo by ayoung ==
 == https://svn.slimdevices.com/jive?view=revision&revision=8583 ==

Fixed bug 15633: cannot switch to SD card content without network 
SlimMenusApplet: if the server has just connected and we do not have our menus 
yet then the request must have been lost in a transient connection interruption,
so reissue the request for our menus.
The fact that we get a transient connection loss if probably another bug but we
still need to be able to handle the resulting state.

In the case that we get such a transient connection loss then we will end up in the Home 
menu instead of the My Music menu after changing music source.

update hours

fw 8627   I was able to insert and connect to the SD card the first time after loss of network (cable to touch unplugged), and also after loss of local Squeezecenter (turned off). There were a couple times where a message was displayed "problem connecting to library" for the previously selected library. After passing the message I was able to select the SD card as the library and play music. So it is working but not yet elegant.