You are here: Home » Topic » Library shows twice on Roku M1000

Library shows twice on Roku M1000

This topic contains 7 replies, has 4 voices, and was last updated by  Anonymous 8 years, 1 month ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #2928

    Anonymous

    Hi there, I was recommended to ask this question on this forum, having drawn a blank from the helpful people on the Roku forums.

    I am running Firefly (svn-1586) on an Icybox 4220 NAS, works perfectly (great software) – only on my M1000 the Library shows up twice, that is I get two libraries with the same name. One library works as expected, the other appears to work fine but has some quirks, for example, when browsing artists, then drilling down to Albums it will list ALL albums, not just the albums associated with that Artist.

    The NAS comes bundled with an earlier version of mt-daapd, but that is turned off.

    iTunes clients on the network only see one library.

    Any pointers to a solution would be helpful.

    I have tried restarting the Soundbridge, the NAS, the Firefly service, in various combinations but to no avail.

    It was sugegsted that I might have two mt-daapd service running, but that doesn’t seem so from looking at the output of the ps command; the only relevent entries are below.

    2769 nobody 4192 S /mnt/md1/public/applications/mt-daapd/bin/mt-daapd -m -c /mnt/md1/public/applications/mt-daapd/conf/mt-daapd.conf
    2775 nobody 4192 S /mnt/md1/public/applications/mt-daapd/bin/mt-daapd -m -c /mnt/md1/public/applications/mt-daapd/conf/mt-daapd.conf
    2781 root 584 S /sbin/mDNSResponderPosix -n The_Music_Box -t _daap._tcp -p 3689 -P /tmp/ff_mDNS_daap.pid -b
    2783 root 584 S /sbin/mDNSResponderPosix -n The_Music_Box -t _rsp._tcp -p 3689 -P /tmp/ff_mDNS_rsp.pid -b
    2814 nobody 4192 S /mnt/md1/public/applications/mt-daapd/bin/mt-daapd -m -c /mnt/md1/public/applications/mt-daapd/conf/mt-daapd.conf
    2875 root 636 R ps ax

    Thanks in anticipation for any help or advice.

    #18629

    fizze
    Participant

    Hi,
    that’s all right, because the RoKu unit will see a DAAP (iTunes) share, and then also the RCP (roku control protocol) share.
    Performance usually isa bit better when using RCP. Other than that there shouldn’t be any differences.

    #18627

    Anonymous

    @fizze wrote:

    Hi,
    that’s all right, because the RoKu unit will see a DAAP (iTunes) share, and then also the RCP (roku control protocol) share.
    Performance usually isa bit better when using RCP. Other than that there shouldn’t be any differences.

    Well thank you, that explains it I guess. So does everyone using a Roku with Firefly see two copies of their library? As I said, there appears to be a difference; one library lists all albums under all artists.

    #18630

    stretch
    Participant

    No, the SB is supposed to ignore the DAAP server if there is an RSP server.
    The same thing happens with one of my servers occasionally.
    Try powering everything down & then reboot.

    #18626

    Anonymous

    @stretch wrote:

    No, the SB is supposed to ignore the DAAP server if there is an RSP server.

    Thanks, so it is a SB issue not a Firefly one. Maybe I need to update the firmware. In the meantime I will try the reboot route.. Thanks for your help.

    #18628

    fizze
    Participant

    If the RSP share is indeed acting up, you can disable it by removing the rsp plugin.
    It’s located in the plugin_dir and called rsp.so or rsp.dll iirc.

    #18631

    Anonymous

    Did anyone resolve this quirk/problem? Can anyone enlighten me?

    I’m running mt-daapd/Firefly (svn-1696) on a Ubuntu server (Jaunty 9.04). I too am seeing the same server twice on my Roku Soundbridge M1000 (firmware 3.0.44). Rebooting does nothing on my setup. One advertised service seems to be fine but the other has the quirk noted by timw where if browsing for an specific artist, a list of albums from ALL artists is returned. I can confirm that my Soundbridge is seeing both daap service and rsp services. To check this I modified the /etc/avahi/services/daap.service to disable Avahi from advertising either service. The unbrowsable service is the daap service. The rsp service is the one that is perfect. The only drawback of disbabling the broadcast daap service is I can’t see the music on my server with iTunes. Is there any way of getting the Roku to ignore daap service? Maybe a tweak of the /etc/avahi/services/daap.service file? The code I have for the daap.service file advertising two services on my Soundbridge is here.



    %h

    _daap._tcp
    3689
    txtvers=1 iTShVersion=131073 Version=196610


    _rsp._tcp
    3689
    txtvers=1 iTShVersion=131073 Version=196610

    Here is code I used to see one browse-able service on my Soundbridge.



    %h

    _rsp._tcp
    3689
    txtvers=1 iTShVersion=131073 Version=196610
    #18632

    Anonymous

    To make things easier to distinguish which service is rsp and which is daap on my Roku Soundbridge (for searching and browsing easier), I devised a way for each service to get a different name. I created two different .service files in the /etc/avahi/services folder. One called rsp.service and one called daap.service. The codes for each are below.

    rsp.service




    %h-RSP

    _rsp._tcp
    3689
    txtvers=1 iTShVersion=131073 Version=196610

    daap.service




    %h-DAAP

    _daap._tcp
    3689
    txtvers=1 iTShVersion=131073 Version=196610

    Rebooting my server delivers these two services to my Roku Soundbridge now with different names. This confirms that the daap service is indeed visible by the Roku (I thought it wasn’t supposed to be). I can now at least select the service that is browse-able and searchable from my soundbridge. This will serve as an acceptable temporary measure until I get any better ideas or a firmware change to the soundbridge allows the daap service to be ignored. I forgot to mention that when I look in iTunes for shared music only the daap service is visible.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.