You are here: Home » Reply » Reply To: SOLVED Problems with gigabit ethernet interfaces

Reply To: SOLVED Problems with gigabit ethernet interfaces

#18251
skellert
Participant

I have two ethernet switches between the firefly server and the M1001 – a gig E switch and a 10/100 switch. I have zero routers between them. (Why two switches??? Because I have about 14 wired ethernet devices in my house and I need more than one eight port switch).

Anyway – I got it working finally YIPEE – but not sure exactly what I did to make it work. Too many things changing…
For what its worth, here’s what I’ve ended up with and how I did it more or less…

1) Because I am ‘lazy’ and don’t want to run upstairs every time I restarted my mt-daapd server, I discovered some time back that you can telnet to port 5555 of the M1001 (ie telnet “IP of M1001” 5555) and issue a Reboot command. It now seems to me that this is NOT THE SAME as powering down the M1001 and doing a hard reboot. I think that its necessary to power cycle the M1001 after restarting the mt-daapd server or it seems to remain confused with some previous data. But I am not 100% sure about this. Without power cycling the M1001, a ‘working’ firefly build won’t work properly! My guess is that if the M1001 was previously connected to a broken build, then it stays broken even if you change to a working build – until power cycling.

2) I was flipping between compiling mt-daapd using the –enable-mdns flag and the –enable-avahi flag. In the end, I have a working server with a build using –enable-avahi. This doesn’t necessarily mean that the built in mdns server doesn’t work, but maybe.

It slowly dawned upon me that, with avahi (which I have not used before), if you restart the mt-daapd server, you also need to restart the avahi-daemon server. In other words…

service mt-daapd stop
service avahi-daemon restart
service mt-daapd start

...Then power cycle the M1001

3) At some stage in all the rigmarole, I realised I was having trouble with the avahi-daemon and rendezvous/bonjour because the M1001 was always seeing TWO instances of the firefly server. When I told the M1001 to connect to what it listed as the first firefly server, the mt-daapd server or the avahi-daemin would seem to lock up.

I found that the problem was that I had erroneously followed instructions in different postings on various discussion groups saying you need to define a daap service in the file /etc/avahi/services/daap.service. THIS IS DEFINITELY WRONG.

It seems that if you compile mt-daapd with the –enable-avahi flag, you SHOULD NOT create an /etc/avahi/services/daap.service file. When I removed this file and restarted everything as above, the M1001 correctly found one instance of the firefly server and connected to it without locking everything up.

4) Try as I may, I never got svn-1696 to work. At some stage, I looked to see if I could find a ‘newer’ build and discovered that the project moved to sourceforge some time ago. I downloaded mt-daapd-0.2.4.2.tar.gz. This is the version of mt-daapd I now have working with Fedora 10.

Interesting because the /etc/mt-daapd.conf file seems to be an *older* format than the version required by svn-1696 (ie I remember having to make a change in format a couple of years ago to the format used by svn-1696 and its immediate predecessors).

And it seems that the M1001 works much better with 0.2.4.2 with regards browsing composers / classical music than it ever did with svn-1696 (it was actually broken in 1696 – at least for me). I’m not sure whether this is because I have a *large* (>10k tracks) classical collection or what. I also noticed that 0.2.4.2 is much faster (four times faster?) than svn-1696 in scanning the library.

Anyway, 0.2.4.2 works for me on Fedora 10 and svn-1696 does not, even though 1696 worked on Fedora 8.

5) I still have an ‘ifconfig eth1 promisc’ command in my etc/rc.d/rc.local script. I added ‘ifconfig eth1 allmulti’ for good measure. This is because my ipg based gigE card at eth1 doesn’t work with multicast otherwise. I required this flag to make mt-daapd work even under Fedora 8.

6) I can’t remember all of the libraries I had to download to get it to compile because my system is now full of libraries, but here’s a guess at what it was (this may contain more libraries than actually required)…

yum install pcre-devel clamav-devel avahi-devel flac-devel nss-mdns avahi-compat-libdns_sd-devel sqlite-devel libid3tag-devel faad2-devel ffmpeg-devel libogg-devel libvorbis-devel libtheora-devel taglib-devel mysql-embedded-devel libmp4v2-devel

For what its worth, I’m using the Fedora 10 development-testing repositories but I have a feeling it will still work with the regular repositories.

7) It probably didn’t make any difference, but I added the –enable-flac to my compile command. Here is the compile line I used to build a working server…

./configure --prefix=/usr  --sysconfdir=/ --enable-sqlite3 --libdir=/usr/lib --enable-avahi --enable-oggvorbis --enable-flac
make
make install

phew. It works now. And it works better than the old svn-1696.
Thanks for the ideas and support.