Nightly stuck on wl500g

[Ping]

Hello,

i’m testing the latest nightly (17.5.2007) package for wl500g with a M1001. Installation of the ipkg went fine, with all the needed dependencies. After configuring the config file, starting the daemon gives me this in syslog:

Jul 19 00:39:25 mt-daapd[21255]: Firefly Version svn-1586: Starting with debuglevel 9

Jul 19 00:39:25 mt-daapd[21255]: Plugin loaded: ssc-script/svn-1586

Jul 19 00:39:25 mt-daapd[21255]: Plugin loaded: daap/svn-1586

Jul 19 00:39:25 mt-daapd[21255]: Plugin loaded: rsp/svn-1586

Jul 19 00:39:25 mt-daapd[21255]: Starting rendezvous daemon

Jul 19 00:39:25 mt-daapd[21255]: Starting signal handler

Jul 19 00:39:25 mt-daapd[21257]: Initializing database

Jul 19 00:39:25 mt-daapd[21257]: Full reload...

Jul 19 00:39:26 mt-daapd[21257]: Starting web server from /opt/share/mt-daapd/admin-root on port 3689

The daemon seems stuck here, no answer on the web port although lsof says it is open by mt-daapd. I tested already with sqlite and sqlite3. Only once, with curl locally on the router I got an hhtp answer requesting the password.

Any hint what could be the problem or any test i could perform?

Greetings,

Ste

[rpedde]

@Ping wrote:

Hello,

i’m testing the latest nightly (17.5.2007) package for wl500g with a M1001. Installation of the ipkg went fine, with all the needed dependencies. After configuring the config file, starting the daemon gives me this in syslog:

Jul 19 00:39:25 mt-daapd[21255]: Firefly Version svn-1586: Starting with debuglevel 9

Jul 19 00:39:25 mt-daapd[21255]: Plugin loaded: ssc-script/svn-1586

Jul 19 00:39:25 mt-daapd[21255]: Plugin loaded: daap/svn-1586

Jul 19 00:39:25 mt-daapd[21255]: Plugin loaded: rsp/svn-1586

Jul 19 00:39:25 mt-daapd[21255]: Starting rendezvous daemon

Jul 19 00:39:25 mt-daapd[21255]: Starting signal handler

Jul 19 00:39:25 mt-daapd[21257]: Initializing database

Jul 19 00:39:25 mt-daapd[21257]: Full reload...

Jul 19 00:39:26 mt-daapd[21257]: Starting web server from /opt/share/mt-daapd/admin-root on port 3689

The daemon seems stuck here, no answer on the web port although lsof says it is open by mt-daapd. I tested already with sqlite and sqlite3. Only once, with curl locally on the router I got an hhtp answer requesting the password.

Any hint what could be the problem or any test i could perform?

Greetings,

Ste

If you can curl from the router, but not remotely, it sure sounds like a firewall issue. Is that possible?

Also, know that the mdns sends and receives from 224.0.0.251, so likely you’ll need to open that up, as it’s likely that it’s configured to only allow access from the internal network, and doesn’t have exceptions for multicast.

— Ron

[Ping]

Hello Ron,

thanks for the very quick answer. I could perform a quick check now before leaving for work; iptables on the router are all empty, no port should be closed. Indeed, running ethereal on my pc and tcpdump on the router i captured the same packets, MDNS broadcasts from the M1001 to 224.0.0.251 plus the SSDP packets.
Seems then that the firewall is not the problem.

Looking at the log i posted previously, does it look complete to you? I had a look at the source and after the server is initialised, the number of tracks is queried to the db. I have no such message, actually nothing regarding music files. The database tables are created but empty. And also the embedded web server seems really not answering. I was wrong before when i wrote that it answered once locally, it never did, I just forgot to append the port number to curl, so the wl500 http server answered..

Looks then that the daemon is stuck there; beside, i’m running with -d 9 but i don’t notice any difference with -d 1..

Aynthing more I could check?

Thanks a lot,

Ste

PS: I’m running the daemon as “admin” and I modified accordingly the config file for it. I don’t have a user “guest” in the system. There should be no file rights problem in this way..

PPS: in this post http://forums.fireflymediaserver.org/viewtopic.php?p=12420 another uses turns on the -f switch and has success. I’m going to try later.

[Ping]

Indeed, the -f made it working.

It made also the debug output to match the level selected, the syslog got full of messages. Now I start the daapd with nohup, -f and an & at the end. I did just test few minutes but all functionalities were there. The problem seems in the “go to daemon” part..

Greetings,

Ste

[rpedde]

@Ping wrote:

Indeed, the -f made it working.

It made also the debug output to match the level selected, the syslog got full of messages. Now I start the daapd with nohup, -f and an & at the end. I did just test few minutes but all functionalities were there. The problem seems in the “go to daemon” part..

Greetings,

Ste

Hrm, that’s two reports. I wonder if it’s a uclibc thing. That’s what’s common on the two platforms is uclibc. I might have to test that further.

— Ron

[Author]

Posts