Share dissapearing after 30 seconds in iTunes

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
    Posts
  • #1840
    digitalbanana
    Participant

    Hi, just installed mt-daapd. Gotta say, its ace. I have had a NAS for a few years, and only just heard about this…

    Anyways, I have set it up, and it works all apart from the face that the share dissappears after 30 seconds….and is not detected again. I have to restart itunes for the share to appear in the first place.

    I have opened the ports on my NAS (Freecom FSG) as follows:

    iptables -A INPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A OUTPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT
    iptables -A OUTPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT

    This is part of the mt-daapd startup script.

    Why is it only showing for 30 secs and how can I fix it?

    Any help would be appreciated…

    #13020
    rpedde
    Participant

    @digitalbanana wrote:

    iptables -A INPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A OUTPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT
    iptables -A OUTPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT

    I thinks these are not quite right… try:


    iptables -A INPUT -p tcp --dport 3689 - j ACCEPT
    iptables -A INPUT -p udp --dport 5353 -s 224.0.0.215 -j ACCEPT
    iptables -A OUTPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT

    That will probably work. If you can http to 3689, the first rule is working. If it shows up at all, for any length of time, then the last rule is working. If it disappears at some point after it starts up, then the second rule is broken.

    Your second rule is superfluous, and my third rule is probably superfluous, as from your description of the problem it looks like you aren’t doing egress filtering, or at least not to the hosts on your lan.

    If you can’t get the 3689 by http, because you *are* doing egress filtering, the winning rule would be:


    iptables -A OUTPUT -p tcp --sport 3689 -j ACCEPT

    – Ron

    #13021
    digitalbanana
    Participant

    Thanks for the help, however with your rules it does not show up at all, no matter how many times i restarted iTunes.

    It did resort back to showing for 30 seconds aain when I entered this rule again:

    iptables -A INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT

    Cheers,

    #13022
    digitalbanana
    Participant

    OK, i have just tried to totally turn off the firewall by doing:

    iptables -P INPUT ACCEPT
    iptables -P OUPUT ACCEPT
    iptables -P FORWARD ACCEPT

    Same happens…it will stream for 30 sec and die. Would this then be an issue with mt-daapd on the server, or a client issue?

    I am using the latest of both: 2.2.4 of mt-daapd and 7.4.2 of itunes.

    Cheers,

    #13023
    rpedde
    Participant

    @digitalbanana wrote:

    Thanks for the help, however with your rules it does not show up at all, no matter how many times i restarted iTunes.

    It did resort back to showing for 30 seconds aain when I entered this rule again:

    iptables -A INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT

    Cheers,

    hrm. Yeah, I guess so. I guess I was thinking that mcast appeared *from* the multicast address, but that’s obviously not right. So yeah, your rule should be the proper rule #2.

    #13024
    rpedde
    Participant

    @digitalbanana wrote:

    OK, i have just tried to totally turn off the firewall by doing:

    iptables -P INPUT ACCEPT
    iptables -P OUPUT ACCEPT
    iptables -P FORWARD ACCEPT

    Same happens…it will stream for 30 sec and die. Would this then be an issue with mt-daapd on the server, or a client issue?

    I am using the latest of both: 2.2.4 of mt-daapd and 7.4.2 of itunes.

    Cheers,

    Then it’s not a firewall issue. It’s probably nic driver on the machine not seeing multicast traffic.

    Try “ifconfig promisc eth0” (or whatever interface), and seeing if that works. If so, it’s a driver issue.

    #13025
    digitalbanana
    Participant

    Entered that command and the same happens, it disappears still.

    Do you think there is incompatibility between the itunes and mt-daapd versions?

    Cheers,

    #13026
    rpedde
    Participant

    @digitalbanana wrote:

    Entered that command and the same happens, it disappears still.

    Do you think there is incompatibility between the itunes and mt-daapd versions?

    Cheers,

    Nope, it’s a multicast issue. That’s how discovery is done. Is it possible you have duplicate names on the network? Like the hostname of your linux box is that same as another machine on the network? Such that the name registration is refused?

    One thing that might be worthwhile would be do make a chain that logs and then drops packets, so you can see dropped packets in syslog. Then make it fail and see if you have any packets canned by the firewall.

    #13027
    digitalbanana
    Participant

    Currentl, and before, the only two boxes in use are this MacBook and the Linux drive, and both are distinctly named. There are no duplicate hostnames on the network according to the router.

    Unfortunately I am not that able with iptables. How would I got about doing the logging and dropping part?

    Cheers,

    #13028
    rpedde
    Participant

    @digitalbanana wrote:

    Currentl, and before, the only two boxes in use are this MacBook and the Linux drive, and both are distinctly named. There are no duplicate hostnames on the network according to the router.

    Unfortunately I am not that able with iptables. How would I got about doing the logging and dropping part?

    Cheers,

    Something like:

    iptables -N logdrop
    iptables -A logdrop -j LOG
    iptables -A logdrop -j DROP

    Then use:

    iptables …blahblahblah.. -j logdrop

    rather than -j DROP

    That way it logs the packet first, then drops it.

    If you have some you don’t want to log (icmp, or windows browser stuff), then just drop that versus logdropping it.

    Or, just before your rules drop off the end (to the default deny), add

    iptables -A INPUT -j LOG

    and they’ll get logged before they drop off the end of the ruleset and get dropped.

    Any of those options would work okay, and let you see what’s getting blocked.

    — Ron

    #13029
    spoonfed
    Guest

    I’m getting almost exactly the same thing, but with a very different setup.

    Wired PC :- XP pro running firefly 1.0 svn-1359

    Wireless laptop :- XP pro running iTunes 7.4.3.1

    My Roku branded M1001 using wireless are both able to connect to the firefly share and play VBR mp3s (over 4 hours today without a hiccup).

    However iTunes on my laptop initially sees the share. When I connect to it it starts loading the database then without any error messages drops back to the local music library and the share disappears. It looks like it’s dropping out at the exact moment it’s finished loading the library and should then be sorting the list of available files.

    The only way to see the share again is to close and restart iTunes.

    Before I installed firefly I had iTunes 7.4.3.1 running on the same wired PC working fine serving to the M1001s and to my laptop.

    There are no errors in the firefly log. My library is 9286 tracks.

    What can I try?

    #13030
    rpedde
    Participant

    @spoonfed wrote:

    I’m getting almost exactly the same thing, but with a very different setup.

    Wired PC :- XP pro running firefly 1.0 svn-1359

    Wireless laptop :- XP pro running iTunes 7.4.3.1

    My Roku branded M1001 using wireless are both able to connect to the firefly share and play VBR mp3s (over 4 hours today without a hiccup).

    However iTunes on my laptop initially sees the share. When I connect to it it starts loading the database then without any error messages drops back to the local music library and the share disappears. It looks like it’s dropping out at the exact moment it’s finished loading the library and should then be sorting the list of available files.

    The only way to see the share again is to close and restart iTunes.

    Before I installed firefly I had iTunes 7.4.3.1 running on the same wired PC working fine serving to the M1001s and to my laptop.

    There are no errors in the firefly log. My library is 9286 tracks.

    What can I try?

    One possibility is that the soundbridge and iTunes use two different protocols for talking to the server.

    It might be that the rsp is working okay, but you’ve found a bug in the daap output module. That’s what iTunes uses.

    Can you connect with iTunes from the PC?

    Can you connect from the laptop wired?

    Those two data points would help some..

    #13031
    Anonymous
    Inactive

    I’m running an FSG-3 with v3.1.29, and mt-daapd installed from the ipkg in the FSG-3 optware repository (identified by the web admin pages as Version 0.2.4.1), and have a similar problem. On startup, mt-daapd is great, it finds all the music and presents itself as a shared library on the iTunes (v7) of PCs scattered through the house. Any time from a few minutes to a few hours later, it just ain’t there any more.

    More info: when iTunes loses the shared library, the mt-daapd web admin pages also disappear.

    All PCs are on wired ethernet connections, through the LAN side of the FSG.

    I’ve also notices that there are always five or six mt-daapd processes running (according to ps). Is this normal? Or a symptom?

    Other users have commented that when installed from the ipkg, the startup script complains about pidof. This is because the FSG’s Linux doesn’t have that command. Edit the startup script and replace the funky looping logic with a simple killall mt-daapd before the sleep 3.

    #13032
    Anonymous
    Inactive

    Follow-up:

    Running fine since 18:28, stopped at 20:14, so nearly two hours of up-time. Shared library disappeared from iTunes.

    Web admin IS running – looks like I was wrong about that, sorry! Status page reports:


    Thread Session Host Action
    108 0 192.168.1.102 Serving admin pages

    Service Status Control
    Rendezvous Running Stop MDNS Server
    DAAP Server Running Stop DAAP Server
    Background scanner Idle Start Scan
    Uptime 3 hours, 25 minutes, 33 seconds
    Songs 2299
    Songs Served 60
    DB Version 2309

    ps reports five instances of the mt-daapd process running – is this right?

    The tail of the log file:

    2008-02-04 20:06:03: Rescanning database
    2008-02-04 20:06:28: Finished streaming file to remote: 4343808 bytes
    2008-02-04 20:06:31: Scanned 2299 songs (was 2299) in 28 seconds
    2008-02-04 20:06:47: Session 0: Streaming file 'Bryan Adams-Kids wanna rock.mp3' to 192.168.1.102 (offset 0)
    2008-02-04 20:09:04: Finished streaming file to remote: 3119232 bytes
    2008-02-04 20:09:22: Session 0: Streaming file 'soundtrack-doom-16-clint_mansell_-_kill_em_all.mp3' to 192.168.1.102 (offset 0)
    2008-02-04 20:11:27: Finished streaming file to remote: 3552041 bytes
    2008-02-04 20:11:42: Session 0: Streaming file 'Queen-Killer Queen.mp3' to 192.168.1.102 (offset 0)
    2008-02-04 20:14:20: Client 192.168.1.102 disconnected
    2008-02-04 20:14:20: Finished streaming file to remote: 3563520 bytes

    and just noticed that debug level is 7, not 9, so I’ll be starting up again now.

    #13033
    Anonymous
    Inactive

    an almost exactly two hours later… <>

    was paying away quite happily, then went off to rescan. Don’t know if that’s related. Tail of level-9 log:

    2008-02-04 23:46:26: Initial update over.  Removing stale items
    2008-02-04 23:46:26: Done removing stale items
    2008-02-04 23:46:26: Reorganizing db
    2008-02-04 23:46:26: Reorganize done
    2008-02-04 23:46:26: Finding deleted static playlists
    2008-02-04 23:46:26: Scanned 2299 songs (was 2299) in 36 seconds
    2008-02-04 23:49:34: Finished streaming file to remote: 5699584 bytes
    2008-02-04 23:49:34: Entering config_set_status
    2008-02-04 23:49:34: Exiting config_set_status
    2008-02-04 23:49:34: Finished serving DAAP response
    2008-02-04 23:49:34: Entering config_set_status
    2008-02-04 23:49:34: Exiting config_set_status
    2008-02-04 23:49:34: Thread 55: Terminating
    2008-02-04 23:49:34: Thread 55: Freeing request headers
    2008-02-04 23:49:34: Thread 55: Freeing response headers
    2008-02-04 23:49:34: Thread 55: Freeing request vars
    2008-02-04 23:49:34: Thread 55: Closing fd
    2008-02-04 23:49:34: With thread 55 exiting, 1 are still running
    2008-02-04 23:49:37: Socket closed?
    2008-02-04 23:49:37: Client 192.168.1.102 disconnected
    2008-02-04 23:49:37: Entering config_set_status
    2008-02-04 23:49:37: Exiting config_set_status
    2008-02-04 23:49:37: Entering config_set_status
    2008-02-04 23:49:37: Exiting config_set_status
    2008-02-04 23:49:37: Thread 0: Terminating
    2008-02-04 23:49:37: Thread 0: Freeing request headers
    2008-02-04 23:49:37: Thread 0: Freeing response headers
    2008-02-04 23:49:37: Thread 0: Freeing request vars
    2008-02-04 23:49:37: Thread 0: Closing fd
    2008-02-04 23:49:37: With thread 0 exiting, 0 are still running
    2008-02-04 23:56:33: Skipped bground scan... no users
Viewing 15 posts - 1 through 15 (of 19 total)
  • The forum ‘Setup Issues’ is closed to new topics and replies.