Share dissapearing after 30 seconds in iTunes

FireFly Media Server Firefly Media Server Forums Firefly Media Server Setup Issues Share dissapearing after 30 seconds in iTunes

Viewing 9 posts - 11 through 19 (of 19 total)
  • Author
    Posts
  • #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
    #13034
    rpedde
    Participant

    @kenpem wrote:

    an almost exactly two hours later… <>

    The log looks fine, and the symptoms sound just like what happens when the server doesn’t see mdns requests. Like above, this looks like a firewall or router issue.

    Is the server and client split by a wireless link? Is it possible that the linux box is firewalling multicast (or routing it upstream)?

    #13035
    Anonymous
    Inactive

    In the current test scenario, there is no wireless. The “server” is the FSG-3, and the “client” is my laptop, on a direct cable connection to one of the FSG’s LAN ports.

    Firewalling multicast? Dunno! Although I would expect that if it was, I wouldn’t get two hours of music first.


    > iptables -L
    Chain INPUT (policy DROP)
    target prot opt source destination
    DROP all -- 192.168.2.0/24 anywhere
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:smtp
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:pop3s
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:pop3
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:imaps
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:imap2
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:www
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere 255.255.255.255 udp dpt:5004
    ACCEPT icmp -- anywhere 192.168.1.2
    ACCEPT all -- anywhere 192.168.1.2 state RELATED,ESTABLISHED
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:ssh
    ACCEPT udp -- anywhere anywhere state NEW,RELATED,ESTABLISHED udp dpt:loc-srv
    ACCEPT udp -- anywhere anywhere state NEW,RELATED,ESTABLISHED udp dpts:netbios-ns:netbios-dgm
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:netbios-ssn
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:microsoft-ds
    DROP all -- anywhere anywhere

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT all -- 192.168.2.0/24 anywhere
    DROP all -- anywhere anywhere

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    >

    the 192.168.2.x subnet is no longer in use, I should probably get it out of there.

    #13036
    Anonymous
    Inactive

    More info…

    Just for a laugh this morning I killed mt-daapd on the FSG, dusted off my old NSLU2 Slug (running uNSLUng), connected it to one of the FSG’s LAN ports, and fired up mt-daapd on the Slug. Music has been playing ever since. Almost eight hours now.

    Music being played on the same laptop, which is still connected to one of the FSG’s LAN ports.

    So now: same version of mt-daapd. Same client software (iTunes 7). Same firewall. If anything, I’ve made the setup worse by doing this. But this music plays on.

    Thoroughly confused! 😯 😕 😥 ❓ ❓ ❓

    #13037
    rpedde
    Participant

    @kenpem wrote:

    Firewalling multicast? Dunno! Although I would expect that if it was, I wouldn’t get two hours of music first.

    Multicast isn’t what transfers the music, multicast is what is used for discovery. It’s what controls whether the “shared music” icon appears. When the server starts, it blasts out multicast stuff to say it’s on the network, so it shows up on iTunes. After the ttl wears off, iTunes queries for it again. If the server doens’t see requests, it won’t answer, and iTunes drops it from the shared list.

    That’s why “plays for a while, then disappears” is usually indicative of the server not seeing multicast. It’s usually one of two things — firewall on server, or wireless routers (which are notorious for dorking up multicast) dropping the multicast.

    Multicast is generall the 224.0.0.0/4 network, and you’d see a query from 224.0.0.251, dport 5353 udp.


    > iptables -L

    Hard to tell from here, too many options missing. an “iptables-save” output would be more helpful.

    Another decent thing to try (at least for troubleshooting) might be to add a LOG target for your drops on the input chain. Somehting like:

    iptables -A INPUT -i -j LOG

    so you can log drops sourced from the inside interface to syslog. Unless you are already passing all traffic received on the inside interface.

    In the case of same firewall working for the slug, then my next guess would be something that doesn’t *often* happen, but sometimes does on embedded boxes — a driver without good multicast support, so it misses the multicast traffic sent to it. In that case, a cheap solution is to just kick hte interface into promicuous mode:

    ifconfig eth0 promisc

    If it’s on a switched port, it’s not really a cpu overhead.

    – Ron

Viewing 9 posts - 11 through 19 (of 19 total)
  • The forum ‘Setup Issues’ is closed to new topics and replies.