Pinnacle SoundBridge HomeMusic – No library

[Anonymous]

Hi,

# mt-daapd/Firefly Version: nightly svn-1586
# Server Operating System: Fedora 7
# Server Hardware: PC
# Client Device: Pinnacle SoundBridge HomeMusic running firmware version 3.0.44
# Also tried using: Rhythmbox – works fine.
# Connection of clients: wireless access point
# If you receive error messages, please write them down exactly.
# Web interface: I am able to connect to the web interface?

The SB cannot see my library with Firefly running on the server.

The SB can play radio – so basic networking is OK.

If I run TwonkyVision instead the SB can see the library, and show the names of the songs, but won’t play them due to a format error.

That proves that the server is fine too (firewall, etc.).

I don’t want to try to solve the TwonkyVision problem, I want to use Firefly.

Twonky listens on ports 1900 and 9080.

Firefly listens on port 5353. So, my guess is that SB is expecting ports 1900 and/or 9080.

When Firefly is running, Rhythmbox can see the library and play the tunes.

So, that means Firefly is OK to some degree.

Everything seems in order *except* the SoundBridge doesn’t work with Firefly.

I’ve spend hours diagnosing this and searching the net for answers. No body else seems to have this problem!

More information….

I’ve recompiled Firefly with –enable-upnp. It now listens on port 1900 too. But SB still doesn’t see it. So, I guess it’s looking for port 9080 (which is service glrpc).

And, in the log file I have this message:

Local Hostnamecabernet.openconc.com.au.local already in use; will try
cabernet-2penconc.com.au.local instead

It happens on startup of Firefly with the SB switched off…so it’s some server software issue, I guess.

Will appreciate any help!

regards,
RR

[Anonymous]

Using tcpdump, I’ve established that the SB and Firefly are communicating via port 1900.

Here’s the log (10.0.0.138 is the router/wireless access point, 10.0.0.60 is the server, and 10.0.0.53 is the SoundBridge):

***************************************
16:37:51.952495 arp who-has 10.0.0.138 tell 10.0.0.53
16:37:51.990964 IP 10.0.0.53.1386 > 239.255.255.250.1900: UDP, length 251
16:37:52.043967 IP 10.0.0.53.1389 > 239.255.255.250.1900: UDP, length 127
16:37:52.044213 IP 10.0.0.60.1900 > 10.0.0.53.1389: UDP, length 311
16:37:52.990190 IP 10.0.0.53.1389 > 239.255.255.250.1900: UDP, length 127
16:37:52.990576 IP 10.0.0.60.1900 > 10.0.0.53.1389: UDP, length 311
16:37:52.992476 IP 10.0.0.53.1393 > 239.255.255.250.1900: UDP, length 319
16:37:53.004709 IP 10.0.0.53.1394 > 239.255.255.250.1900: UDP, length 310
16:37:53.024153 IP 10.0.0.53.1395 > 239.255.255.250.1900: UDP, length 366
16:37:53.044384 IP 10.0.0.53.1396 > 239.255.255.250.1900: UDP, length 374
16:37:53.064424 IP 10.0.0.53.1397 > 239.255.255.250.1900: UDP, length 376
16:37:53.089305 IP 10.0.0.53.1398 > 239.255.255.250.1900: UDP, length 364
16:37:55.064521 IP 10.0.0.53.1401 > 239.255.255.250.1900: UDP, length 310
16:37:55.078726 IP 10.0.0.53.1402 > 239.255.255.250.1900: UDP, length 366
16:37:55.089606 IP 10.0.0.53.1403 > 239.255.255.250.1900: UDP, length 374
16:37:55.100859 IP 10.0.0.53.1404 > 239.255.255.250.1900: UDP, length 376
16:37:55.121655 IP 10.0.0.53.1405 > 239.255.255.250.1900: UDP, length 364
16:37:57.044011 arp who-has 10.0.0.53 tell 10.0.0.60
16:37:57.046594 arp reply 10.0.0.53 is-at 00:0d:4b:30:73:ef
***************************************

After that, I started mt-daapd with -d 9 option and found all this nice output:

***************************************
upnp_packet: M-SEARCH from 10.0.0.53
upnp_packet: Query: urn:schemas-upnp-org:device:MediaServer:1
Responding to query request…
Responding in 0 (of 1) seconds
Sending upnp broadcast of type: 3 (SSDP Discovery Response)
Found 5 tokens in urn:schemas-upnp-org:device:MediaServer:1
Token 1: urn
Token 2: schemas-upnp-org
Token 3: device
Token 4: MediaServer
Token 5: 1
Did respond to query urn:schemas-upnp-org:device:MediaServer:1
select(10, 0.100585)
select(10, 0.100585)
select(10, 0.099609)
upnp_packet: M-SEARCH from 10.0.0.53
upnp_packet: Query: urn:schemas-upnp-org:device:MediaServer:1
Responding to query request…
Responding in 0 (of 1) seconds
Sending upnp broadcast of type: 3 (SSDP Discovery Response)
Found 5 tokens in urn:schemas-upnp-org:device:MediaServer:1
Token 1: urn
Token 2: schemas-upnp-org
Token 3: device
Token 4: MediaServer
Token 5: 1
Did respond to query urn:schemas-upnp-org:device:MediaServer:1
select(10, 0.000976)
select(10, 5.000000)
upnp_packet: M-SEARCH from 10.0.0.53
upnp_packet: Query: urn:schemas-upnp-org:device:MediaServer:1
Responding to query request…
Responding in 0 (of 1) seconds
Sending upnp broadcast of type: 3 (SSDP Discovery Response)
Found 5 tokens in urn:schemas-upnp-org:device:MediaServer:1
Token 1: urn
Token 2: schemas-upnp-org
Token 3: device
Token 4: MediaServer
Token 5: 1
Did respond to query urn:schemas-upnp-org:device:MediaServer:1
select(10, 5.000000)
***************************************

So, Firefly is responding to the SB. But, may the answer doesn’t look right?

Clues, anyone?

regards,
RR

[EVILRipper]

uPnP on firefly is not functional. It includes a simple ‘detection’ stage of code, nothing more. (if enabled)

The SB should discover firefly on the network and play using the RSP protocol. The default port firefly uses is port 3689. You might have a try at that.

[Anonymous]

Hi,

Thanks for your reply.

Well, that doesn’t seem to do anything even though the log says the rsp plugin is loaded.

So, I’ve tried svn-1696 in the hope that that would improve things.

So, here’s the log on startup:

************************************************
2008-06-24 19:04:51 (b7f6a6d0): Registering Firefly svn-1696 on cabernet._http._tcp (3689)
2008-06-24 19:04:51 (b7f6a6d0): Registered service 0, name ‘Firefly svn-1696 on cabernet’, type ‘_http._tcp’, port 3689
2008-06-24 19:04:51 (b7f6a6d0): Checking daap/svn-1696
2008-06-24 19:04:51 (b7f6a6d0): Registering _daap._tcp
2008-06-24 19:04:51 (b7f6a6d0): Processing rendezvous message
2008-06-24 19:04:51 (b7f6a6d0): Registering Firefly svn-1696 on cabernet._daap._tcp (3689)
2008-06-24 19:04:51 (b7f6a6d0): Registered service 1, name ‘Firefly svn-1696 on cabernet’, type ‘_daap._tcp’, port 3689
2008-06-24 19:04:51 (b7f6a6d0): Checking ssc-script/svn-1696
2008-06-24 19:04:51 (b7f6a6d0): Checking rsp/svn-1696
2008-06-24 19:04:51 (b7f6a6d0): Registering _rsp._tcp
2008-06-24 19:04:51 (b7f6a6d0): Processing rendezvous message
2008-06-24 19:04:51 (b7f6a6d0): Registering Firefly svn-1696 on cabernet._rsp._tcp (3689)
2008-06-24 19:04:51 (b7f6a6d0): Registered service 2, name ‘Firefly svn-1696 on cabernet’, type ‘_rsp._tcp’, port 3689
2008-06-24 19:04:51 (b7f6a6d0): Checking ssc-ffmpeg/svn-1696
2008-06-24 19:04:51 (b7f6a6d0): Executing: select count(*) FROM songs
2008-06-24 19:04:51 (b7f6a6d0): Serving 230 songs. Startup complete in 1 seconds
2008-06-24 19:04:52 (b7f6a6d0): Callback: ^Firefly svn-1696 on cabernet^E_http^D_tcp^Elocal Name Registered
2008-06-24 19:04:52 (b7f6a6d0): Callback: ^Firefly svn-1696 on cabernet^E_daap^D_tcp^Elocal Name Registered
2008-06-24 19:04:52 (b7f6a6d0): Callback: ^Firefly svn-1696 on cabernet^D_rsp^D_tcp^Elocal Name Registered
********************************************

Seems the rsp plugin is loaded still.

tcpdump shows the SB contacting again on port 1900 (and now no response from Firefly, since I didn’t enable upnp in this compile).

Isn’t port 3689 for TCP and the administration service?

Do you know whether the Pinnacle SoundBridge will work with RSP?

What port should be open for that?

Firefly has only UDP ports 5353 and something > 34000 (which changes with each start) and TCP port 3689.

Do I need Bonjour (the admin service says it is off)?

Any other suggestions?

thanks,
RR

[Anonymous]

You do need Bonjour/Avahi running.

I’ve just been playing with Firefly on an Ubuntu 8.04 build and the default Avahi config caused me a couple of minor problems not least that my eth0 interface wasn’t communicating after boot – in the /etc/avahi/services/daap.service XML file I restricted the service to IPv4 ( ) and in the /etc/avahi/avahi-daemon.conf file I set ‘use-iff-running=no’. Which of these two points fixed the eth0 issue I’m not sure but both made sense and cured my initial problem.

There’s an example for the service file here

I used this page for some instruction but ignored the firestarter stuff.

[Anonymous]

Hi,

Thanks.

None of that made any difference.

regards,
RR

[Anonymous]

Hi folks,

I have got the same problems with my configuration.

For a strange reason, the hub of my modem/router don’t forward the multicast frame, so the SB can’t detect my firefly server.

A this stage, the only issue I found is to add a regular switch before my modem/router. Is work fine now.

I’m looking for a patch for modem/router

[Anonymous]

Hi,

Yes, the problem (see my OT on this) is my Wireless Router (D-Link DSL G604T).

When I use a very old Access Point (D-Link DWL-900+) it all works fine.

D-Link are replacing my G604T under warranty with a Generation II version which has newer firmware.

I suspect (but don’t know) that if Firefly supported UPnP then faulty network devices would be less of a problem. I suspect this because TwonkyVision almost worked and Windows Media Connect did work, with the same network setup that prevented Firefly from working.

If I can find some time, I’ll help Mr Pedde get the UPnP stuff working.

regards,
RR

[Anonymous]

An another way should be to declare the firefly server in the soundbridge like the java client (by an @ip).
In this case, it will be no discovery problems.

😀

[Anonymous]

Hi,

AFAIK there is no way to do that with the Pinnacle SoundBridge HomeMusic.

regards,
RR

[Author]

Posts