- This topic has 21 replies, 5 voices, and was last updated 17 years, 10 months ago by
.
-
Posts
-
(I am reposting this from the Roku Forum, in case this is more of a Firefly issue than a Soundbridge issue and there are different brains looking at each forum. I apologize if it is redundant for some of you.)
Since this is my first post, I’d like to start with a short introduction. I’m a software developer dealing mostly with C#/.NET enterprise development from Toronto. I recently purchased a Soundbridge M1001 and after a bit of fiddling was able to get it to work perfectly (Over WiFi) with my library on my linux box using the latest mt-daapd stable build.
A couple of days go by leaving the unit on standby, and I discovered last night that the Soundbridge would no longer connect to my library. That is, that my library is always visible from the SB while the server is running, but attempting to select it on the SB results in a short wait followed by “Could not connect to server.” No amount of restarting mt-daapd, rebooting the server, rebooting the router, or power cycling the soundbridge have helped.
Puzzled I checked things over on the server and all appeared well. I booted up my old laptop with Windows on it, to test the server with iTunes 7. To my horror, my mt-daapd music share was found, loaded and played songs just fine. The mt-daapd share also loaded and played OK locally via Rhythmbox and Banshee. I went as far as to go into Firestarter and completely disable the firewall from there on the linux box, even though no events were being logged to lead me to believe that there was something going on. Considering that it *was* working fine before, I am pretty sure that my router/server is functioning fine.
Curiously, I started Rhythmbox and enabled music sharing and the library there had the same issue, showing up on SB but not connecting but playing in iTunes. Discouraged, I removed all of my avahi packages and re-installed them using apt. After which, my music libraries shared from either Rhythmbox or Banshee were both showing up and playing on the SB… though the mt-daapd I am running is not using avahi, I gave it another shot and the problem with mt-daapd persists.
At the end of the day, as it was getting late, I tried one last thing… I got the latest nightly of firefly, compiled and installed it and set it up as directed with the new configuration file loading the plugins including RSP. All was fine with it in iTunes on my laptop, but it still won’t work with the SB.
My router is a Linksys WRT54GL running the latest stable DD-WRT firmware. I’ve tried even disabling the SPI firewall on it, which had no effect, and it is not set up to filter multicast (though SB discovering my library is never a problem).
So the million dollar question is, what could have happened to make my working setup stop working? Why should the server play from iTunes on a remote machine fine but not the SB? What am I missing here?
I should note that I have NOT tried upgrading the SB to the 2.7 beta firmware after reading all of the bug reports on this forum it did not seem like it would be the wise thing to do yet… obviously, if the problems are exaggerated and upgrading will somehow get my unit working on my network again with mt-daapd I’d be happy to try it. I don’t really want to leave Rhythmbox running to access my music, I noticed that the browse functions by artist etc. were not available using it as my server.
P.S. SB plays Internet Radio fine, I assume it is not a connectivity issue. Also, I upgraded my SB to the latest stable firmware the day I received it and all was well afterwards. Also interesting is that out of curiosity I installed the Windows build of Firefly on my laptop, and it was found by my SB and played fine… it is only on my Linux box, only with mt-daapd that I am having issues.
Is there anything special I should know to compile the latest nightly to have it use Avahi under Edgy?
Reboot the Soundbridge. This is an (old) known bug the SBs have.
Apparently Roku doesnt think this one deserves priority. I think this is a shame, because one often checks EVERYTHING else in the chain, only to find the last piece to be faulty. 🙁
Well, another thing you can do is using the Avahi-Browser under Ubuntu. Then you can see the multicasts, etc.
Doesnt make much sense on the same host though, but on the WLAN, prolly. You get the idea.Thanks for the tip, but I’ve both tried rebooting via the menu *and* power cycling the soundbridge and the problem persists that when it starts up it immediately tries to connect to my library and fails.
Or do you mean I have to “reset to defaults” and re-enter all of my wifi configuration? Ugh, I hope not, that was tedious. 🙂
@fizze wrote:
Reboot the Soundbridge. This is an (old) known bug the SBs have.
Apparently Roku doesnt think this one deserves priority. I think this is a shame, because one often checks EVERYTHING else in the chain, only to find the last piece to be faulty. 🙁
Well, another thing you can do is using the Avahi-Browser under Ubuntu. Then you can see the multicasts, etc.
Doesnt make much sense on the same host though, but on the WLAN, prolly. You get the idea.I am of not much help but have similar problems. I get message: unable to play from WMP 11 – could not connect to Firefly at all. Tried from laptop and Firefly was fine! Downloaded slimbox but no luck although that seems to come up in the log file of Firefly…. It is all a big puzzle to me and all that really works is the internet radio.
I have downloaded the upgrade without problems but it did not solve the firefly problem.
Had firewall down and Norton anitvirus but no luck.Any one any idea?
I did not get a response from Roku.Thanks!
well, it could be the old multicast over WLAN router issue, but I dont think so.
You should consider trying to upgrade to 2.7beta4 , Im running it without any drawbacks. But thats only me. No guarantee of course. Meh. :-/
Is the SB your only wireless device?
Well, I know notice that you run DD-WRT. I ran that too and had nothing but trouble with it. I thought its a hardware problem, but as soon as I slapped HyperWRT Thibor on the WRT54 everything was smooth and stable and without a hitch since then.
If there isnt a specific reason for you to use DD-WRT, then Id recommend to switch to Thibor – its featurest aint bad – and it has been stable for me like hell.
I also run an NDS, Wii, and Laptop on the wireless network all without any trouble.
I suppose I can try the beta firmware as a last resort. I’d be surprised if something was with DD-WRT, it’s been doing a fine job for me and like I said, it was working alright before and I haven’t changed anything on the router since.
The only thing that happened that I can think of which even remotely might have some effect is that there was a round of security updates to the Avahi packages that I did… but why should that effect Firefly running mDNS?
I even tried disabling Avahi in my Ubuntu services control but it didn’t make a lick of difference.
well, firefly running with mDNS AND avahi at the same time conflicts.
You should build firefly around avahi. At least thats what Ron suggested somewhen. iirc.Well, whats a NDS?
I run firefly on my NSLU2, and i can share niceley through banshee or rhythmbox through avahi on my PC. Its all wireless, and all works fine here, also latest avahi patches and stuff.
But maybe its the combination of mDNS and avahi…. *shrug*
@Binary Jay wrote:
The only thing that happened that I can think of which even remotely might have some effect is that there was a round of security updates to the Avahi packages that I did… but why should that effect Firefly running mDNS?
Probably shouldn’t.
You can compile to avahi with “–enable-avahi” in the config invocation, although it requires a working pkg-config (which ubuntu should have).
Basically, though, you’ve already ruled everything out. It’s not an mdns problem — the SB can see the server, as can everything else you tried, so it’s not mDNS.
It’s not a firewall issue, as your iTunes can connect to it.
You could *try* disabling the rsp module, forcing the sb to connect using daap rather than rsp. That would make it look exactly like an iTunes client, and you will have eliminated everything that’s different between a wireless iTunes client and a wireless SB.
Stop the mt-daapd server, and rename /usr/share/mt-daapd/plugins/rsp.so to something else. rsp.so.old, maybe.
Then restart the server. Then your soundbridge should be connecting via daap. That’s the only thing left to exclude (on the server side, anyway) — a bug in the rsp module that doesn’t get exposed when you use a daap client.
— Ron
Thanks for the reply Ron.
I forgot to mention that I previously (when researching through existing posts on the board) tried to disable RSP in mt-daapd by removing it from the plugins list in the conf file. I didn’t however rename/move the rsp.so file. Is removing it from the plugins list not good enough to accomplish what you suggested to force mt-daapd into DAAP only mode?
I’m really puzzled!
I’ll try the rename when I’m home from the office this evening to see if that does any good. Failing that, unless you have any other suggestion, I’ll take my chances with the 2.7b4 firmware. I assume the firmware can be rolled back to 2.5x if I choose to, somehow?
@Binary Jay wrote:
I forgot to mention that I previously (when researching through existing posts on the board) tried to disable RSP in mt-daapd by removing it from the plugins list in the conf file. I didn’t however rename/move the rsp.so file. Is removing it from the plugins list not good enough to accomplish what you suggested to force mt-daapd into DAAP only mode?
That works for the version roku distributes (based on svn-1359). It was changed to load all plugins present in the plugin_dir around 1400 or so. It was done to make it easier for distros to modularize it… specific plugins that would drag in large dependancies could be packaged separately, and by just dropping the plugin in the plugin_dir and the plugin would automatically get activated.
I’ll try the rename when I’m home from the office this evening to see if that does any good. Failing that, unless you have any other suggestion, I’ll take my chances with the 2.7b4 firmware. I assume the firmware can be rolled back to 2.5x if I choose to, somehow?
I seem to remember you could do that, but I don’t remember the details. It’s something to root around for in the roku forums, I think.
Ah, it’s in the manual: unplug the device, and plug it in while pressing any button on the remote. The logo should appear with “safe mode” superimposed on it, and you should be taken directly to the system configuration menu with options limited to checking for software update and resetting factory defaults.
Stored settings won’t be recalled, though, so in safe mode you’ll have to connect via wired, or go through the process of setting up a network and wep key.
So it’s doable to recover, just painful. 🙁
- The forum ‘Setup Issues’ is closed to new topics and replies.