Any thoughts on this one? What do you think, Felix?

There have been a lot of changes since 7.4.1/r7915. It might be helpful if you updated to 7.4.2 as soon as the the latest Radio firmware is available (r8320 or similar). I haven't lost one single preset yet.

(In reply to comment #2)
> There have been a lot of changes since 7.4.1/r7915. It might be helpful if you
> updated to 7.4.2 as soon as the the latest Radio firmware is available (r8320
> or similar). I haven't lost one single preset yet.

Any ETA on the newer firmware?  The behavior sounds a lot like the problems in Bug#15397 or Bug#15292.

(In reply to comment #2)
> There have been a lot of changes since 7.4.1/r7915. It might be helpful if you
> updated to 7.4.2 as soon as the the latest Radio firmware is available (r8320
> or similar). I haven't lost one single preset yet.

How can I get a newer firmware on the radio? I tried it with the menu "Software - Update" but the radio tells me that the installed FW (7.4.1/r7915) is the newest one and I can only download and install it AGAIN.

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

Brian - do you have a local SbS running? You should be able to get newer firmware this way.

I am still trying to reproduce this case.

Created attachment 6441 [details]
messages file

Brought the messages log to this bug thread from 15397
Just saw the failure again this morning. This time I saw a WHITE wifi icon, but
the presets didn't work. I checked the diags, all looked good to me. Then
selected Internet Radio > Local, and it looked up the stations somehow, and the
presets started working again!
I note the player uptime was 5 days 56 hours 34 minutes
software version remains: 7.4.1 r7915

ATTACHED: /var/log/messages
This looks very interesting! Can anyone interpret for for me? I pulled this
right after reconnecting the radio as described above. So the pertinent stuff
is all at the end, dated Jan 15.

(In reply to comment #6)
> Brian - do you have a local SbS running? You should be able to get newer
> firmware this way.

Thanks, I'll give it a try.

(In reply to comment #7)
> I am still trying to reproduce this case.

I just tried to reproduce it, too.

First of all, as I came home this moment, my Radio didn't react pressing one oft the preset buttons. Nothing happens. I had to go through the menu (Internet radio or something else) and after pushing that, the screen "connecting to mysqueezebox.com" appears. Then I can push the preset buttons and everything works fine. That's the same procedure I have to do every morning (with oder without an alarm doesn't matter). By the way: The wifi-sign is white everytime! So everything seems to be fine.

To reproduce this behaviour, I disconnected my router to give me a new IP-address (external) and tried again one of the preset buttons: And the radio plays the station correctly! I thought the new external IP-address is the problem, but there must be anything else.

Is there a "deep sleep" state of the radio where it doesn't recognize there's a new IP-address? It sounds strange that the problem occurs only at the morning / evening after a long(er) time of non usage ...

(In reply to comment #6)
> Brian - do you have a local SbS running? You should be able to get newer
> firmware this way.

Just updated to 7.5.0 r8358

I'll have a look on it whether the alarm / preset buttons will work tomorrow morning / evening.

Test is done: It doesn't work right, either with the newer firmware!

There was only the backup-alarm ringing this morning, although there was no disconnect during the night (as of the logs of my router). Neither the preset buttons did work.

First as I came home this evening I tried the preset buttons: Same behaviour! No radio, just a "there is no preset" - sound. During the day there were 3 short disconnects from the internet.

And then, the same procedure: Hit a menu entry (that requires a connection to the net and to mysqueezebox.com) like "Internet radio", the screen "connecting to mysqueezebox.com" appears and after that, everthing works.

Now I'm a little bit fed up with this radio ...

Felix, is there anything else we can provide to help? Is the messages log I provided useful?

Carl - I've looked at your log file, but unfortunately found nothing that helped me understand what's going wrong in your setup. I can see SB Radio did disconnect on January 14th, but the last entry on January 14th is that it has reconnected fine.

Brian - I am sorry to hear it still doesn't work.

There must be something special to your setup that I am unable to reproduce else I am sure I'd see the same issue with my tests too.

Could you please give me some more details about your setup and your use pattern just before you let SB Radio sit for a while? Like are you pausing / stopping music before you turn it off?

Also, am I correct that you both exclusively use mysb.com and have _no_ local SB server running (not even an older one)? Just want to make sure.

Carl - next time, before you try anything and you have logged into SB Radion with ssh, could you please get another log and also issue a 'netstat -an' command. This would give me the active connections.

Thank you for your patience and help to track down this issue. I appreciate it.

QA - Chris, Steven - I could use some help here. I need a reproducible case. Thanks

Carl - When you are logged into your Radio, could you please also issue a

cat /etc/squeezeplay/userpath/settings/SlimDiscovery.lua

and post its content here. Thanks.

BTW: Brian, if you feel like it and know how to login to your Radio with ssh then please post your logfile etc. too. Thanks.

Created attachment 6446 [details]
netstat -an

Created attachment 6447 [details]
/var/log/messages

Created attachment 6448 [details]
/etc/squeezeplay/userpath/settings/SlimDiscovery.lua

(In reply to comment #14)
> Brian - I am sorry to hear it still doesn't work.
> 
> There must be something special to your setup that I am unable to reproduce
> else I am sure I'd see the same issue with my tests too.
> 
> Could you please give me some more details about your setup and your use
> pattern just before you let SB Radio sit for a while? Like are you pausing /
> stopping music before you turn it off?

After the fallback-alarm fires, I put it off (sorry, don't know the exact way. It's way too early for me). When it's time to wake up, I want to hear some music, press one of the preset buttons, nothing happens. Then I go to the menu, hit "Internet radio", "your advices" (or something like that), the screen "connecting to mysqueezebox.com" appears and after that, everything works fine. I push one of the preset buttons, listen to the station.

When its (really really) time to wake up, I push the "power-off" button shortly and leave the room.

When I come home at evening and want to listen so some internet-music: I hit one of the preset buttons, nothings happens. Then I start the same workaround as described above.

The attached files are made at the point where nothing happens, that means BEFORE the workaround.

 
> Also, am I correct that you both exclusively use mysb.com and have _no_ local
> SB server running (not even an older one)? Just want to make sure.

Yes. I tried the server a few times, but it is only running if I start it. Normally (morning, evening) the PC is shut down.

Hi Brian

Thank you very much for your latest message log. I think we found something in there which could help to solve the mystery, but I need you to please take another message log, but with some more network debug flags turned on.

To turn the message flags on you'll need to copy a file onto your SB Radio and place it into the correct location. Here is a step by step description:

1. Download the attached logconf.lua file
2. Copy the file logconf.lua via scp onto your SB Radio into roots home
-- scp <path>/logconf.lua root@<ip of radio>:/root
3. Log into your SB Radio
-- ssh root@<ip of radio>
4. Move the file logconf.lua from /root to /etc/squeezeplay/userpath/
-- mv /root/logconf.lua /etc/squeezeplay/userpath/
5. Make sure the changes stick in the filesystem by issuing a sync
-- sync
6. Reboot your SB Radio

If you look at your log now it will have many more entries. Please post them here again when you get the failure.

Thanks
Felix

Created attachment 6449 [details]
Logging config file to turn on network logging

(In reply to comment #21)
> Hi Brian
> 
> Thank you very much for your latest message log. I think we found something in
> there which could help to solve the mystery, but I need you to please take
> another message log, but with some more network debug flags turned on.
> 
> To turn the message flags on you'll need to copy a file onto your SB Radio and
> place it into the correct location. Here is a step by step description:

Just copied the file to the given directory and made a reboot (what the hell: now I have a Logitech-trojan on my device :) ). After the reboot, preset buttons do work (they didn't when I came home). 


> If you look at your log now it will have many more entries. Please post them
> here again when you get the failure.

Which file you want to see? The "/var/log/messages"? And if so, I think you wanna have a look on it if the radio is in the state that the preset buttons don't work, right? So I have to wait till tomorrow evening..

Yes, the "/var/log/messages" file and yes when your Radio is in the preset buttons don't work state again. And don't be alarmed the log file will be bigger this time. This is expected with all the additional logging options now turned on.

Thanks again
Felix

As expected, the preset buttons didn't work as I came home a few minutes ago (the wifi-sign is still white, the diagnostics say everything is fine).

You can find the files (there a 2 files, one called "messages.txt", the other one called "messages.0.txt") attached at the next comments. I don't know what the suffix ".0" means, maybe it's the older version of the normal "messages.txt"?

Created attachment 6451 [details]
/var/log/messages

Created attachment 6452 [details]
/var/log/messages.0

Hello Brian

Thanks for the message logs. Two log files are kept and the logging happens to both of them in turn. That is the reason for a messages and messages.0 file.

Unfortunately it looks like the message logs you submitted are not covering the time when the 'bad' thing happened since we are now logging much more information and consequently this fills up the log file much quicker overwriting older entries.

I didn't realize that the default message log file size is set to about 200k which will only hold about 40 minutes of logging information. Sorry about that.

Therefore I need you to restart the logging daemon to use a larger default log file size so it can hold about 12 hours of logging information.

Please log into your SB Radio again and issue the following commands:

killall syslogd
/sbin/syslogd -S -s500

This starts the logging daemon with a default file size of about 5 MB.

Do not reboot your SB Radio after that else the logging daemon gets started with the default (small) log file size again.

Then when your SB Radio is in the bad state again, please submit both messages files again, but rename messages.0 to something else before submitting it so it won't delete the messages file as it did the last time.

Thanks again
Felix

The command to start syslog with a 5 MB file size was wrong in my previous comment, please use these two commands instead:

killall syslogd
/sbin/syslogd -S -s5000

(In reply to comment #29)
> The command to start syslog with a 5 MB file size was wrong in my previous
> comment, please use these two commands instead:
> 
> killall syslogd
> /sbin/syslogd -S -s5000

I did this yesterday evening. The alarm was set to 'off' (because I can't stand the backup tone in the morning...), the preset buttons didn't work. After the 'workaround' everything was fine.

This morning the same: No function of the preset buttons, did the workaround, and after that fine.

This evening the same: No working buttons, then the workaround. Hope it helps you.

Created attachment 6468 [details]
/var/log/messages

Created attachment 6469 [details]
/var/log/messages_zero.txt

I wanted to follow up... Brian, you have been doing great work. My situation has been just like yours, but I've never tried the alarm, just the preset problem. At any rate, It occurred almost every day for me, more like every other day. I set my radio to static IPs back around January 1st, and have only had the problem once since then. I don't know if this provides a tip or data point for Felix or not. Brian, does moving to a static IP setup fix your problem? You can see my static setup under bug 15397.
To me, this implies that the software somehow loses some part of the DHCP obtained info overnight? 

Assuming that the issue is related to losing the dhcp info, could a crude fix be for the software to automatically refresh the DHCP if it can't reach mysqueezebox.com, before reporting an outright failure to connect? I'd rather see a crude patch that "makes it work" in the next release, than nothing...

At any rate, I might set the config back to Dynamic now and see if the problem comes back consistently.

Felix, once you narrow this down, I'd love to hear more about what the actual cause is.

Carl

(In reply to comment #33)
> ...
> Brian, does moving to a static IP setup fix your
> problem? You can see my static setup under bug 15397.
> To me, this implies that the software somehow loses some part of the DHCP
> obtained info overnight? 
> 
Hi Carl,
I read about the thing with DHCP / static IP and switched my router from DHCP to the static IP, but it didn't matter. I have the same problems with both of the settings. Unfortunatelay ...

Brian, switching your router settings wouldn't have worked. DHCP is initiated and requested by the radio itself: the RADIO asks the router for an address. Putting the router on a fixed address setting just means it will reserve a specific address for the radio. The radio will still attempt to do DHCP to get it's addresses. You would need to change the Radio settings so that it has a fixed set of addresses, and then it would have no need to request addresses, and thus could not lose them. Does this make sense? I'd again suggest you try changing the Radio setting per my comments on bug 15397. It might be very useful to see if that clears up the problem, as that would point to the Radio's DHCP process as being part of the issue.
Best wishes!
Carl


(In reply to comment #34)
> (In reply to comment #33)
> > ...
> > Brian, does moving to a static IP setup fix your
> > problem? You can see my static setup under bug 15397.
> > To me, this implies that the software somehow loses some part of the DHCP
> > obtained info overnight? 
> > 
> Hi Carl,
> I read about the thing with DHCP / static IP and switched my router from DHCP
> to the static IP, but it didn't matter. I have the same problems with both of
> the settings. Unfortunatelay ...

Hi there

Thank you guys for your input. It's highly appreciated.

Unfortunately we do not yet exactly know what is going wrong but we are fairly sure from looking at Brians message log files it has nothing to do with how SB Radio gets its IP address. There is nothing in the message log indicating SB Radio gets disconnected from the router.

Thanks
Felix

Created attachment 6472 [details]
Proposed patch

Created attachment 6473 [details]
Proposed patch

I've also rolled out a possible fix to MySB, so please grab another log when this happens tomorrow.

(In reply to comment #38)
> Created an attachment (id=6473) [details]
> Proposed patch

It's nice that somebody takes care of this problem but it would be much more nice if there would be a HOWTO or something like that to apply the given patch!

Just to say: I'm a common customer that bought this radio to listen to some internet streams and to wake up with music. I have really very few knowledge in linux, in the structure of your devices and the way how your firmware is designed! So posting a few lines of source code and call it a patch really doesn't help me out!

Am I right that you want me to change the Player.lua file in

/usr/share/jive/jive/slim

with the given marked lines in that way the DIFF link near the patch shows it?

No, please don't apply the patch.  Alan was posting it here for the other developers and for reference.

(In reply to comment #41)
> No, please don't apply the patch.  Alan was posting it here for the other
> developers and for reference.

Aah, OK! I won't do anything unless somebody calls me directly :) ...

Hello Brian

I am very sorry for the confusion. As Andy mentioned already Alan only posted his patch here so we developers can have a look at it. Eventually it will be integrated into a new firmware if it proves to be ok.

However as Andy also said in comment 39 he applied a possible fix to mysqueezebox.com so if you please could post another message log when it happens to your SB Radio again that would be very helpful.

If for whatever reason you had to reboot your SB Radio please make sure you run the two commands again to increase the message log file to be 5MB. When in doubt you can just run the two commands again anyway.

killall syslogd
/sbin/syslogd -S -s5000

Thank you so much for helping us out here. I tried with many routers to reproduce the issue you are seeing but unfortunately it seems that we are chasing an issue which is very specific to the router / DSL modem you are using.

BTW: What make / model is the router / DSL modem you have?

Thanks
Felix

(In reply to comment #43)
> Thank you so much for helping us out here. I tried with many routers to
> reproduce the issue you are seeing but unfortunately it seems that we are
> chasing an issue which is very specific to the router / DSL modem you are
> using.
> 
> BTW: What make / model is the router / DSL modem you have?

Just another data point here.  I'm experiencing this exact issue intermittently as well.  I haven't had a chance to grab the logs as it hasn't happened recently.  Originally it was nightly.  The last time it happened neither my internet facing IP, nor the LAN IP for the squeezebox had changed between uses.  Though in some prior disconnect cases, the LAN IP did rotate.

I'm using a Netgear FGW114p router.  WPA2-PSK AES

(In reply to comment #43)
> Hello Brian
> 
> I am very sorry for the confusion. As Andy mentioned already Alan only posted
> his patch here so we developers can have a look at it. Eventually it will be
> integrated into a new firmware if it proves to be ok.

However, after reading the post with the patch and lot of investigation I'm now able to change the file ;)

> If for whatever reason you had to reboot your SB Radio please make sure you > run
> the two commands again to increase the message log file to be 5MB. When in
> doubt you can just run the two commands again anyway.
> 
> killall syslogd
> /sbin/syslogd -S -s5000

Done!


> BTW: What make / model is the router / DSL modem you have?

It's a "FRITZ!Box Fon WLAN 7050" of the manufacturer "AVM" which is, in my
opinion, very common here in Germany.

I have tested that patch against a modified SbS. I have been able to reproduce the original problem without the patch and the problem is mostly resolved with the patch.

I say mostly, because it usually takes one minute after the reconnection for the player to be working properly again. I have resolved this with a modified patch.

To reproduce:
	in Slim/Networking/Simproto.pm set $forget_disconnected_time = 0; restart SbS
	use lsof to find the file-descriptor of the slimproto connection from the SP player to SbS
	use gdb to close that connection (attach <pid> / call close(<fd>) / detach / quit )
	
	observe that the now-playing screen is exited and that the playback-state icons disappear from the display (Radio)
	
	Preset buttons do not work. Library browsing may not work.
	
With the patch in place, observe that the main menu is rebuilt and the playback-state icons reappear. Preset buttons and library browsing work.

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

Fixed Bug 15444: note when current player disconnects so that reconnection is noticed later

Hello Brian, hello Carl

Even though Alan closed this bug I'd be interested in hearing from you whether the issue is solved for you now? Do you still have to manually reconnect before using a preset?

Thanks
Felix

Had it yesterday, so I do NOT consider it fixed. Brian, hows yours?
Carl 

(In reply to comment #49)
> Hello Brian, hello Carl
> 
> Even though Alan closed this bug I'd be interested in hearing from you whether
> the issue is solved for you now? Do you still have to manually reconnect before
> using a preset?
> 
> Thanks
> Felix

Hi Carl

Could you please confirm what firmware version you are running on your SB Radio?

Thanks
Felix

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

Just saw this bug again. Radio was in standby, hit one of the presets, and it doesn't connect. I know this bug is "closed" but it still happens! What can I check or do? At the moment the radio is sitting with the preset still broken. Can I provide any useful data again?
Carl


(In reply to comment #50)
> Had it yesterday, so I do NOT consider it fixed. Brian, hows yours?
> Carl 
> 
> (In reply to comment #49)
> > Hello Brian, hello Carl
> > 
> > Even though Alan closed this bug I'd be interested in hearing from you whether
> > the issue is solved for you now? Do you still have to manually reconnect before
> > using a preset?
> > 
> > Thanks
> > Felix

Carl, thanks for the feedback. Could you please confirm what firmware your SB Radio is currently running?

Thanks
Felix

I'm on 7.4.1 r7915
Anything I can do?
Carl

(In reply to comment #54)
> Carl, thanks for the feedback. Could you please confirm what firmware your SB
> Radio is currently running?
> 
> Thanks
> Felix

The fix for this bug is in 7.4.2 (to be released in the _extremely_ near future) and 7.5.0. 

Carl, you're running 7.4.1 firmware so the problem is still present there.

Firmware needs to be at or past r8423 to pick up Alan's change.

OK, so I'll wait for the "extremely near future" ;-), for the new
firmware, instead of trying to find r8423. But I'll definitely report
back here if I see the bug again. It's only been happening once every
couple weeks since I've been on fixed IP addresses.
Best wishes,
Carl

(In reply to comment #56)
> The fix for this bug is in 7.4.2 (to be released in the _extremely_ near
> future) and 7.5.0. 
> 
> Carl, you're running 7.4.1 firmware so the problem is still present there.
> 
> Firmware needs to be at or past r8423 to pick up Alan's change.

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

I also experience this problem. This afternoon the Squeezebox Radio suddenly only showed three menu items in the menu items when starting up. I decided to try to fix this by making a factory reset with the result that I ended up with a "Can't connect to mysqueezebox.com". The device never had this problem during the past month (since I bought it) so I can't see any issue with the router since I didn't modify its configuration. The wireless symbol is constantly blue.

I was surprised that on the one hand I had to choose my wireless network again (and type the password) but on the other hand the squeezebox didn't ask me for the mysqueezebox username or password. And unfortunately there is no possibility to set it on your own which I think is a bad thing, as it could be that you changed your password.

Firmware: newest (7.5.1 r9009)
Hardware Version: 5
[...]
mysqueezebox.com: 89.202.121.131
Ping: OK
TCP port 3484: OK
TCP port 9000 (for mysqueezebox.com): Can't connect
mysqueezebox.com registration: [empty]