You are here: Home » Topic » mt-daapd suddenly disappears from iTunes / FreeBSD 6.2

mt-daapd suddenly disappears from iTunes / FreeBSD 6.2

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues mt-daapd suddenly disappears from iTunes / FreeBSD 6.2

This topic contains 25 replies, has 4 voices, and was last updated by  rpedde 10 years, 2 months ago.

Viewing 15 posts - 1 through 15 (of 26 total)
  • Author
    Posts
  • #1319

    madkiss
    Participant

    Hi all,

    i am encountering a very strange problem with mt-daapd: Running on FreeBSD 6.2, while compiling mt-daapd and installing and starting it works flawlessly, the mt-daapd-entry just disappears randomly from iTunes. While mt-daapd is still running (the process, i mean), nothing else but restarting it will work to make iTunes see it again. This happens (more or less) reproducibly with the current stable as well with current snapshot versions that i tried.

    is this a known problem and is a fix available possibly?

    m.

    #10316

    rpedde
    Participant

    @madkiss wrote:

    Hi all,

    i am encountering a very strange problem with mt-daapd: Running on FreeBSD 6.2, while compiling mt-daapd and installing and starting it works flawlessly, the mt-daapd-entry just disappears randomly from iTunes. While mt-daapd is still running (the process, i mean), nothing else but restarting it will work to make iTunes see it again. This happens (more or less) reproducibly with the current stable as well with current snapshot versions that i tried.

    is this a known problem and is a fix available possibly?

    m.

    Sounds like your fbsd box is blocking incoming multicast. Allow udp port 5353 from 224.0.0.251, or see if there is a way to allow all local multicast.

    — Ron

    #10317

    madkiss
    Participant

    that indeed fixed it, thank you very much! just if you have a little bit of free time, can you quickly explain why upon restarting mt-daapd, iTunes first saw it but then lost it a bit later? I mean … if the firewall blocks things, then it should block it right away and always, shouldn’t it? so iTunes should never have been able to see it …

    i’m a bit mixed up by that. anyway. thank you.

    m.

    #10318

    rpedde
    Participant

    @madkiss wrote:

    that indeed fixed it, thank you very much! just if you have a little bit of free time, can you quickly explain why upon restarting mt-daapd, iTunes first saw it but then lost it a bit later? I mean … if the firewall blocks things, then it should block it right away and always, shouldn’t it? so iTunes should never have been able to see it …

    i’m a bit mixed up by that. anyway. thank you.

    m.

    When it starts, it sends out a multicast to “pre-cache” the mdns resolvers on locally connected networks. So probably that was going out (permissive firewall — allows all outbound, stops unsolicited inbound). But it has an associated TTL. So after that TTL (somewhere around a half hour), machines tart querying the network for the device. But it doesn’t see the queries (firewall), so it doesn’t respond, so it gets dropped off the browse lists.

    So “shows up when starting, drops off after about a half hour” is textbook for not seeing mDNS requests.

    — Ron

    #10319

    jellyfish
    Participant

    I too have this same problem on freebsd.

    Can you please tell me what command you ran/file you edited to resolve this?

    Thanks

    #10320

    jellyfish
    Participant

    I am not running any firewall rules on this freebsd box in question. Do I have to explicitly allow that port with a firewall rule? I don’t see how that would change anything..

    #10321

    madkiss
    Participant

    This line in pf.conf fixed the problem for me:

    pass in proto { tcp, udp } from any to 224.0.0.251 port mdns keep state label “mdns”

    cheers.

    m.

    #10322

    foging
    Participant

    I’m experiencing exactly the same problem as mentioned above, but I have not activated any firewall on my Ubuntu Feisty installation. What could be the problem if it isn’t a firewall issue?

    Ubunty Feisty: Running firefly
    Powerbook 10.4.9: Playing music

    Any suggestions?

    #10323

    rpedde
    Participant

    @foging wrote:

    I’m experiencing exactly the same problem as mentioned above, but I have not activated any firewall on my Ubuntu Feisty installation. What could be the problem if it isn’t a firewall issue?

    Ubunty Feisty: Running firefly
    Powerbook 10.4.9: Playing music

    Any suggestions?

    On feisty it’s probably a problem with using two different multicast daemons. I’d guess that feisty is probably using avahi, and you may be using a different one on your workstation.

    How did you compile it, or where did you get the package from?

    #10324

    foging
    Participant

    On feisty it’s probably a problem with using two different multicast daemons. I’d guess that feisty is probably using avahi, and you may be using a different one on your workstation.

    How did you compile it, or where did you get the package from?

    I did:
    >apt-get install mt-daapd

    it installed just fine, I could log into the web-page but the service didn’t show up in iTunes. After some searching here I restarted the avahi-daemon and mt-daapd started showing up in iTunes. It seems to work as long as I play music, but when its not used it disappears after a while.

    How do I know if I’m running multiple multicast daemons?

    #10325

    rpedde
    Participant

    @foging wrote:

    On feisty it’s probably a problem with using two different multicast daemons. I’d guess that feisty is probably using avahi, and you may be using a different one on your workstation.

    How did you compile it, or where did you get the package from?

    I did:
    >apt-get install mt-daapd

    it installed just fine, I could log into the web-page but the service didn’t show up in iTunes. After some searching here I restarted the avahi-daemon and mt-daapd started showing up in iTunes. It seems to work as long as I play music, but when its not used it disappears after a while.

    How do I know if I’m running multiple multicast daemons?

    If you got it from the etch repository, then you are fine — it’s using avahi. If it shows up when you start avahi and then goes away after a half hour or so, then it’s a firewall issue. I think your feisty box has a built-in firewall. You’ll need to add an exception for multicast, but that’s a question better asked on the ubuntu forums, I think.

    — Ron

    #10326

    foging
    Participant

    Not getting any closer, but, when i did >sudo mt-daapd -f I got:

    Starting rendezvous daemon
    *** WARNING *** The programme ‘mt-daapd’ uses the HOWL compatiblity layer of Avahi.
    *** WARNING *** Please fix your application to use the native API of Avahi!
    *** WARNING *** For more information see
    Starting signal handler
    Signal handler started
    Initializing database
    Starting web server from /usr/share/mt-daapd/admin-root on port 3689
    Registering rendezvous names
    Serving 14543 songs. Startup complete in 3 seconds

    This makes no sense to ne, I thought I was using just Avahi, not HOWL? Am I just completely daft or have I installed HOWL in my sleep? Suggest I wanted mt-daapd to stop using HOWL and just use Avahi, how would I go about?

    p.s. Installed mt-daapd via apt-get install mt-daapd

    #10327

    foging
    Participant

    Did some more fixing and apparently broke it further more:

    [email protected]:/etc$ sudo mt-daapd -f
    Starting with debuglevel 2
    Starting rendezvous daemon
    *** WARNING *** The programme ‘mt-daapd’ uses the HOWL compatiblity layer of Avahi.
    *** WARNING *** Please fix your application to use the native API of Avahi!
    *** WARNING *** For more information see
    Starting signal handler
    Signal handler started
    Initializing database
    Query: vacuum
    Error: unable to open database file
    Aborting
    [email protected]:/etc$ Rendezvous socket closed (daap server crashed?) Aborting.
    Aborting

    Aaargh! Running mtdaapd 0.2.4+r1376-2, and I have both sqlite and sqlite3 installed. I have also opened port 5353 from 224.0.0.251 and 3689 incoming from everyone (is that one necessary?)

    #10328

    rpedde
    Participant

    @foging wrote:

    Not getting any closer, but, when i did >sudo mt-daapd -f I got:

    Starting rendezvous daemon
    *** WARNING *** The programme ‘mt-daapd’ uses the HOWL compatiblity layer of Avahi.
    *** WARNING *** Please fix your application to use the native API of Avahi!
    *** WARNING *** For more information see
    Starting signal handler
    Signal handler started
    Initializing database
    Starting web server from /usr/share/mt-daapd/admin-root on port 3689
    Registering rendezvous names
    Serving 14543 songs. Startup complete in 3 seconds

    This makes no sense to ne, I thought I was using just Avahi, not HOWL? Am I just completely daft or have I installed HOWL in my sleep? Suggest I wanted mt-daapd to stop using HOWL and just use Avahi, how would I go about?

    p.s. Installed mt-daapd via apt-get install mt-daapd

    Avahi has a howl compatibility mode. That’s what this is using. Its still using avahi, but mt-daapd thinks its using howl. Sometime after 1376 native avahi bindings were added.

    So this is normal, and nothing to worry about.

    #10329

    rpedde
    Participant

    Error: unable to open database file
    Aborting
    [email protected]:/etc$ Rendezvous socket closed (daap server crashed?) Aborting.
    Aborting

    Aaargh!

    premissions on the /var/cache/mt-daapd directory (or the db file itself) are probably not writable by the “runas” user.

    Running mtdaapd 0.2.4+r1376-2, and I have both sqlite and sqlite3 installed. I have also opened port 5353 from 224.0.0.251 and 3689 incoming from everyone (is that one necessary?)

    Yes. Both are necessary. 5353/224.0.0.251 is the mdns stuff, the 3689 is the admin web page as well as the daap server.

    — Ron

Viewing 15 posts - 1 through 15 (of 26 total)

You must be logged in to reply to this topic.