I am very interested in finding a C DAAP/DPAP library and have some
questions about the code in Rhythmbox.
1. The DAAP code was already once pulled out of Rhythmbox to create
libdmapsharing [1]. However, this project seems to have stalled in
the last two years. Is this project dead? If so,
I have done some work adding server support to libdmapsharing. As I
said in a previous email (Subj.: Questions regarding DAAP library
split), I am interested in a DMAP client / server library for C.
libdmapsharing-new-libsoup [1] Adds support for libsoup-2.24.
libdmapsharing-server [2] This
In December of this year, I started maintaining Andre Magalhaes'
libdmapsharing[1]. At the time, I expressed interested in adding DPAP
(iPhoto) support to the library, which had originally been based on code
pulled from rhythmbox. I have now been working on this project for nine
months and would li
> I just wanted to let you know about my Google Summer of Code project, which
> is to implement support for DACP, aka iPhone & iPod touch Remote, to
> Rhythmbox. The coding officially starts this week so I've setup a WIki to
> show the progress (also because GSoC admins required ;)
> http://live.gn
>> The patch is starting to get mature and I would appreciate feedback from
>> anyone who is willing to test it. The Bugzilla entry contains instructions
>> that describe what is needed to build Rhythmbox with the patch.
> Would that work using the latest libdmapsharing tarball, or is master
> ne
>> I am the Google Summer of Code mentor for Alexandre's project. I
>> would like Alexandre's work to target libdmapsharing so that any GNOME
>> application may use his DACP functionality. Rhythmbox does not yet use
>> libdmapsharing for its DAAP implementation. I have submitted a patch
>> [1] that
> Thanks for the suggestion.
>
> I recompiled libdmapsharing with "--with-mdns=avahi" and got much the same
> thing with the avahi mdns service running
>
> Regards
> John
>
> (09:58:25) [0x944bef0] [rb_module_init] rb-module.c:140: RBModule 0xb3809800
> initialising
> (09:58:25) [0x944bef0] [r
>> Just wondering if there is a way to remotely control Rhythmbox with an
>> Android phone. Something similar to the Apple Remote for the Iphone. My
>> wife has that installed on her iPhone and is able to control all the music
>> on her computer via her phone she can control Itunes volume, play m
> I started by trying to build libdmapsharing from source (from git), and
> have a couple of small suggestions - I hope the RB folk don't mind
> me using their mailing list, since it is related.
>
> Please add a .gitignore file which should cover *.o and *.lo at least,
> plus all the files you exp
> I'm building it on a 32 bit system and got this error:
>
> CC libdaap_la-rb-daap-record.lo
> cc1: warnings being treated as errors
> rb-daap-record.c: In function ‘rb_daap_record_new’:
> rb-daap-record.c:413: error: cast from pointer to integer of different size
>
> The following one line
> Here is a one byte change to libdmapsharing which allows the Rhythmbox
> DAAP/DACP plugin to work with Apple Remote v2.0.1 (229) on an iPod
> touch (and probably an iPhone, but maybe not on an iPad):
>
> diff --git a/libdmapsharing/daap-share.c b/libdmapsharing/daap-share.c
> index 2120632..0592
>>> Does this version dependency need to be checked in the RB
>>> configure script?
>> libdmapsharing should probably complain if libsoup isn't new enough
>> for DACP to work. It's not really up to an application to check
>> versions of libraries required for other libraries to work.
>
> Understo
>> Actually, I forgot I found a better solution ;) libdmapsharing uses
>> gdk-pixbuf if present, while getting only a filename from Rhythmbox,
>> it loads the image, resize and convert to PNG (take a look
>> at dacp_share_ctrl_int in dacp-share.c). I think it's still a better
>> solution then inclu
> The following stub entry in libdmapsharing to just say we don't
> have covers (rather than not handling the request at all) seems
> to solve the stale cover issue I was seeing in the Remote app:
>
> diff --git a/libdmapsharing/dmap-share.c b/libdmapsharing/dmap-share.c
> index 1c714df..be3ed1f 1
>> I've been able to send covers (using a single hard coded filename)
>> by inserting a copy of the dcap-share.c cover sending code into
>> dmap-share.c in this new stub. However, I don't understand the
>> libdmapshare code enough to work out how to define the callback
>> function which would ask t
I have been experimenting with libdmapsharing and Vala. What I have found
is that there are some symbol name changes to libdmapsharing that would
facilitate the use of libdmapsharing from Vala. For example,
libdmapsharing uses "TYPE_DMAP_DB," where the GObject convention is
actually "DMAP_TYPE_DB."
>> Version 0.13.1, installed with Fedora 14 does not detect the files loaded
>> onto a working iPod shuffle (3-gen, 2Gig device).
>
> 0.13.2 is in updates-testing for Fedora 14.
I noticed "0001-Build-with-older-libdmapsharing.patch." I'd be happy to
push a newer libdmapsharing to Fedora 14. Rhyt
>>> 0.13.2 is in updates-testing for Fedora 14.
>> I noticed "0001-Build-with-older-libdmapsharing.patch." I'd be happy to
>> push a newer libdmapsharing to Fedora 14. Rhythmbox is the only
>> reason I have not done so. The only other package in Fedora that uses
>> libdmapsharing is dmapd, and I a
GNOME Bugzilla ticket #402477 points out that Rhythmbox does not support
DAAP over IPv6. In fact, libdmapsharing does not quite work with IPv6
yet. I would like to fix this.
The largest change requires that Rhythmbox listen on an IPv6
address. There is a patch at the bug referenced above that impl
>> GNOME Bugzilla ticket #402477 points out that Rhythmbox does not support
>> DAAP over IPv6. In fact, libdmapsharing does not quite work with IPv6
>> yet. I would like to fix this.
>>
>> The largest change requires that Rhythmbox listen on an IPv6
>> address. There is a patch at the bug reference
> Are there any plans to support Apple's Airplay for devices that support
> this? I'm interested in streaming music to my Airport Express Base Station
> with Rhythmbox in the same way that iTunes is currently capable of doing.
There is an "apexsink" in Gstreamer plugins bad. This should allow any
I just pushed the libdmapsharing API 3 changes to the DAAP plugin in
Rhythmbox's gobject-introspection branch.
Most of the changes to the libdmapsharing API are cosmetic, driven
by work to build DMAP-aware applications using Vala. The latest
version of libdmapsharing that provides API 3 is 2.9.2,
I updated the gobject-branch Rhythmbox DAAP plugin to use a developement
version of libdmapsharing a few weeks ago. I am looking for feedback on
this change. To test, you will need libdmapsharing 2.9+, available at:
http://www.flyn.org/projects/libdmapsharing/
I am especially interested i
> I can't compile Rhythmbox with DAAP support, because I can't find the
> libdmapsharing development library. Anyone know where I can find it? I'm
> running openSUSE 11.3.
I can't speak for OpenSUSE packages, but libdmapsharing is available
upstream at:
http://www.flyn.org/projects/libdma
>> Sorry, I'm not much of a c developer, I was just trying to be helpful
>> and give you folks more info than just a complaint. Does the bug,
>> ignoring my bad patch, seem legitimate?
> File a bug please, yes.
Am I correct to assume that you are connecting with the menu item
"Music->Connect to
I am planning to ship a new version of libdmapsharing which breaks the
library's API. This version will have a new soname. The primary reason
for this is to better support GObject introspection.
When would be a good time to port the DMAP plugin in Rhythmbox to this
new API? If I were to submit a p
26 matches
Mail list logo
