Connection loss and reboot issue reloaded

[schiers]

@rpedde wrote:

obtw, you have a fetchmail problem:

The Mail Delivery System couldn't deliver this mail because of the following problem:



Reporting-MTA: dns; localhost.localdomain



Final-Recipient: rfc822; carsten@localhost

Last-Attempt-Date: Sat, 27 May 2006 23:02:51 +0200

Action: failed

Status: 5.0.0

Diagnostic-Code: 550 Rejected







Received: from localhost (localhost.localdomain [127.0.0.1])

by localhost.localdomain (AvMailGate-2.0.2-15) id 02976-10C6D05E;

Sat, 27 May 2006 23:02:40 +0200

Received: from pop.xxxx.com [xxx.xxx.xx.xxx]

by localhost with POP3 (fetchmail-6.2.5)

for carsten@localhost (single-drop); Sat, 27 May 2006 23:02:40 +0200 (CEST)

No, Ron, 8) You are a Spammer (at least for my setup). I am very strict.

Content analysis details:   (2.0 points, 1.3 required)



pts rule name              description

----



0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%

[score: 0.5000]

2.0 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address

[70.114.57.34 listed in dnsbl.sorbs.net]

Now you are on the whitelist.

BR,
Carsten.

[fizze]

hm, I donno if my crashed are related to this, but RokuDan just told me that they logged 7 crashes of my unit. I bet 99% of these are related to my mt-daapd being in this whacky state.

Maybe that helps.

[schiers]

although i have to mention that the issue improved much by the latest two nightlies. It only crashes when I change the version underneath the Soundbrige’s butt…

[fizze]

Id tell that detail to the Roku folks 😉

[schiers]

I’ve told them that it crashes. But not that it got better. I fear they don’t check it, when I tell them 8)

And in the end, I need more test to see wether it is really gone…

CU Carsten.

[fizze]

true, I experienced crashes like that too, when I changed the config, but no the version, without cold-booting the SB.

seems like the fingerprint of the server changes, and the SB dont like that. *shrug*

[rpedde]

@fizze wrote:

true, I experienced crashes like that too, when I changed the config, but no the version, without cold-booting the SB.

seems like the fingerprint of the server changes, and the SB dont like that. *shrug*

You know, that could be it — if the soundbridge fetches stuff and then it changes out from under it, like a playlist changes, or something. Wonder if that could be part of it?

[Ted Harper]

@rpedde wrote:

You know, that could be it — if the soundbridge fetches stuff and then it changes out from under it, like a playlist changes, or something. Wonder if that could be part of it?

I don’t know if you are still tracking this, but I just had my Soundbridge go stupid (ie lose the ability to connect to any music libraries, or do anything useful at all until it was powered off-and-on) after it had worked flawlessly for about a week, playing dozens of albums, etc.

What I did, which I believe caused the Soundbridge to lunch itself internally in some way, was to stop Firefly, edit the Firefly config file and restart Firefly (probably a couple of times in quick succession) while the Soundbridge was switched on and connected to the Firefly library via RSP (even though it wasn’t actually playing any track at the time). Specifically – although I don’t think the specific change would matter – I changed the default scan time from 600 to 0 – and as soon as I had stopped fiddling with it and Firefly was running again I went out to the loungeroom and the Soundbridge couldn’t connect to any media servers (or anything).

So what I think is (sometimes, maybe timing-dependent – as far as some request cycle between the SB and Firefly) if the Soundbridge is on and connected to Firefly via RSP, and Firefly is stopped/restarted (or has some sort of config file change which it processes and reinnitialises itself), the Soundbridge can put itself into a useless state that then requires a power off/on to get functionality back.

In my case I have 2.5 Beta 10 firmware on the Soundbridge and am running the latest nightly build of Firefly (svn-1197) on Windows. To reiterate, it was running flawlessly (with no changes being made to Firefly config, no new media added, etc) right up until I edited the Firefly config file, then it was no good, as described by others also.

ted.h.

[rpedde]

I think there are two issues here.. one is the “sb gets stupid” one, where it just won’t connect to anything until you reboot it, and the other is a ff deadlock that people report happen particularly on dual core systems.

I’m not sure on 1, but I think there is probably new firmware soonish, and #2 is waiting on me to get a dual core system up and running for better debugging.

[Ted Harper]

@rpedde wrote:

I think there are two issues here.. one is the “sb gets stupid” one, where it just won’t connect to anything until you reboot it, and the other is a ff deadlock that people report happen particularly on dual core systems.

I’m not sure on 1, but I think there is probably new firmware soonish, and #2 is waiting on me to get a dual core system up and running for better debugging.

Thanks Ron, the one I see is (1) and for me at least it definitely seems related to “something being changed on Firefly while the Soundbridge is switched on and connected via RSP” (even if the SB isn’t actually playing something), but not 100% repeatable – I haven’t had the “sb gets stupid” problem for a while now _except_ when I have changed Firefly underneath it. I haven’t had Firefly lock up and require restarting for a couple of weeks or so – when the “sb gets stupid” problem happens it is only the SB I am powering off/on, not touching Firefly (and after the SB cold restart all is well again).

I don’t know if I can help with debugging or isolating (2), because the only dual-core machine I have here is my wife’s Mac Mini (and the MacFirefly builds seem to have a fairly high “degree of difficulty” right now). I do have a Xeon laptop (the Xeon CPU appears to be two CPUs to Windows XP, and behaves that way as far as threads being thrown across them, just there are really only two instruction queues rather than two actual cores); would testing Firefly on that box give you any useful information for the deadlock/race problem?

ted.h.

[Author]

Posts