Annouce: SB Player, a software Squeezebox player app for Android.

[Redrum]

Do the Network Timeout and Max Retry work together? Example, network timeout = 30 seconds, max retry = infinite, and taking your backoff into consideration, retries would occur after 30, 31, 32....?

Or, are they for separate purposes?

Jim

<edit, I guess why I am asking, if we were looking for a faster reconnect, we might choose 10 and infinite, then get 10,11,12,13,14,15,16,,,,,>

[SmrtJustin]

Do the Network Timeout and Max Retry work together? Example, network timeout = 30 seconds, max retry = infinite, and taking your backoff into consideration, retries would occur after 30, 31, 32....?

Or, are they for separate purposes?

Jim

<edit, I guess why I am asking, if we were looking for a faster reconnect, we might choose 10 and infinite, then get 10,11,12,13,14,15,16,,,,,>

I tried exactly this tonight, and still seem to never get a reconnect, even though the server takes just a few seconds to restart. I do notice that when I go to the phone that SB Player is running on, I can't disconnect in the app either. It seems to think it's still connected and a disconnect seems to have no effect. I have to exit the app, and then when I restart the app it will reconnect (it is set to auto-connect on launch).

[wt0]

Do the Network Timeout and Max Retry work together? Example, network timeout = 30 seconds, max retry = infinite, and taking your backoff into consideration, retries would occur after 30, 31, 32....?

Or, are they for separate purposes?

Jim

<edit, I guess why I am asking, if we were looking for a faster reconnect, we might choose 10 and infinite, then get 10,11,12,13,14,15,16,,,,,>

Took a look at the code, backoff time does not increase by one each time, starts at 2 secs then increases by 5 each time until a max of 35 secs.

Network Timeout determines how long to wait after, initiating the connection, for it to successfully connect.

So in your scenario, it would be 12,17,22,27,32,37,42,47

Once it's connected, the timeout for receiving data from the server is 30 secs, so after the server goes down it will take 30s before the app will notice. If server restarts within that 30s it still wouldn't matter because the new server instance would not know about the old connection. The disconnect doesn't seem to work when this happens because it was easier to write it that way (I would explain why, but it's a little hard to explain it to non-programmers). I might change that in the future, if I get around to it.

The server takes a bit longer than a few secs to restart. it usually takes at least 20 secs before it becomes responsive to commands again.

[Redrum]

Thanks Wayne,
I mostly understand your explanation, but rather than try to clarify details, maybe you can answer one question and explain what would happen in a couple of scenarios, as SmrtJustin and my situation differ:

Question - does SB Player specifically handle a wifi/network loss differently than a server loss?

Scenarios - In my case, I would walk out of wifi range for say 5-30 minutes, what happens? In SmrtJustin 's case, he restarts the server, which takes, not sure how long, less than a minute? Network connection remains though...From post #377, it does not seem to be recovering as expected.

Jim

[wt0]

Thanks Wayne,
I mostly understand your explanation, but rather than try to clarify details, maybe you can answer one question and explain what would happen in a couple of scenarios, as SmrtJustin and my situation differ:

Question - does SB Player specifically handle a wifi/network loss differently than a server loss?

Scenarios - In my case, I would walk out of wifi range for say 5-30 minutes, what happens? In SmrtJustin 's case, he restarts the server, which takes, not sure how long, less than a minute? Network connection remains though...From post #377, it does not seem to be recovering as expected.

Jim

A network loss is something that happens locally on the phone, so the app will know about it immediately and will try to reconnect. You can test that by just turning off/on your wifi. If you have retries set to infinite, it should reconnect when you walk back into range. If the break is brief, you might not even hear a break in the music.

When the server goes down, the only way the app knows is when it does get any data from the server after a predetermined amount of time, which in this case is 30 secs. It probably will reconnect if you wait long enough, but 30 sec is a pretty long wait and most people will probably try to manually reconnect before that happens.

[SmrtJustin]

When the server goes down, the only way the app knows is when it does get any data from the server after a predetermined amount of time, which in this case is 30 secs. It probably will reconnect if you wait long enough, but 30 sec is a pretty long wait and most people will probably try to manually reconnect before that happens.

Even with it sitting for days it never reconnects after a server reboot. I've set the Max Retries to Infinite, but that doesn't seem to change the behavior. Maybe that's expected behavior based on the Disconnect not working in that case.

[wt0]

Even with it sitting for days it never reconnects after a server reboot. I've set the Max Retries to Infinite, but that doesn't seem to change the behavior. Maybe that's expected behavior based on the Disconnect not working in that case.

Alright, finally did some debugging and the problem wasn't what I thought it was. It turns out that when the server goes down, the background thread that handles the commands from the server was silently crashing before it ever reaches the reconnect code. The case where the network disconnects generates a different error and goes thru a different code path that doesn't crash the thread. I'll get it fixed in the next update.

[SmrtJustin]

Alright, finally did some debugging and the problem wasn't what I thought it was. It turns out that when the server goes down, the background thread that handles the commands from the server was silently crashing before it ever reaches the reconnect code. The case where the network disconnects generates a different error and goes thru a different code path that doesn't crash the thread. I'll get it fixed in the next update.

Awesome! Thanks for looking into it!

[darrell]

Got this app for my Amazon Fire TV stick. Just a couple of small issues:

I need to set Output Sampling Rate to 48000 in order to stream from BBC Sounds. But as I understand, this means that everything is resampled unneccesarily with a possible performance problems according to the app. Or is the AFTV resampling the 44100 stuff anyway, even on HDMI?

I understand I could instead "Emulate 192khz Support", but this means that SBS sends 96/24 from Qobuz (with this off, SBS sends 44.1/16) , which makes buffering and therefore track advance/seeking slow as the Fire TV Stick is at the other end of the house behind a stack of electronics, hanging off the back of an AV receiver. I'd like to keep 96/24 streaming for the main system, where the SB Server, router and SB Touch are on top of each other so a very fast connection, so I don't want to throttle Qobuz on the SBS. Would it be worth having 48 and 96 options in the app, as well as 192?

Also, gapless playback is not quite perfect: there's a momentary breakup in the sound on track transition, though no actual delay. The same thing happens on my tablet, so it's not a Fire stick problem. And the problem does not exist on the rival SqueezePlayer app when tested on the same tablet (but that's no longer available in the Amazon store and doesn't work when sideloaded onto the AFTV stick).

Thank you!

[wt0]

I need to set Output Sampling Rate to 48000 in order to stream from BBC Sounds. But as I understand, this means that everything is resampled unneccesarily with a possible performance problems according to the app. Or is the AFTV resampling the 44100 stuff anyway, even on HDMI?

The performance warning was put there when Android 4.1 was new. By now on anything built in the last 8 years and running Android 5 or better, the performance hit would be practically negligible especially since I've tweaked the resampling to be more efficient.

I understand I could instead "Emulate 192khz Support", but this means that SBS sends 96/24 from Qobuz (with this off, SBS sends 44.1/16) , which makes buffering and therefore track advance/seeking slow as the Fire TV Stick is at the other end of the house behind a stack of electronics, hanging off the back of an AV receiver. I'd like to keep 96/24 streaming for the main system, where the SB Server, router and SB Touch are on top of each other so a very fast connection, so I don't want to throttle Qobuz on the SBS. Would it be worth having 48 and 96 options in the app, as well as 192?

That's actually a good idea and I wish I had thought of that when I put that option in. However, changing a setting from being stored as a on/off toggle to a number or multiple choice is a pain. I have to make sure that everywhere that setting is used is changed to expect the new type, not to mention making sure that the previous setting is converted correctly to the new type when the app is updated but only for the versions that have that setting. On top of that Google's auto settings backup is going to cause problems too when it restores the setting on reinstalls or installs on other devices. Basically, it's a bit of a minefield that I don't want to step into for a relatively niche problem.

If you're ok with a bit of a drop in quality, you could set SB Player to connect in low bandwidth mode to force LMS to stream using a lossy format (mp3, aac, ogg, opus)

Also, gapless playback is not quite perfect: there's a momentary breakup in the sound on track transition, though no actual delay. The same thing happens on my tablet, so it's not a Fire stick problem. And the problem does not exist on the rival SqueezePlayer app when tested on the same tablet (but that's no longer available in the Amazon store and doesn't work when sideloaded onto the AFTV stick).

I've never had a problem like that happening consistently. What format are you streaming? Do you have crossfading turned on? Crossfading could make it sound like the sound is dropping. I don't think SqueezePlayer supports crossfading so that might be why it doesn't seem to have a problem.