Re: [Rhythmbox-devel] iTunes Music Sharing

On Wed, 2005-07-06 at 02:13 -0400, Charles Schmidt wrote:
> 3. Modify the httpclientsrc implementation in bugzilla to have settable
> properties for extra headers.  uris would be handed to RBPlayer in the
> form of daap://.  RBPlayer would fudge them into http:// uris, force
> playbin to use the new httpclientsrc, and add the extra headers to it.
> Number 3 is probably the "best" solution:
> 	It solves multiple problems. Namely: this one and adds a non-gnomevfs
> http:// handler for GStreamer.   However, I believe it is the most
> challenging, and does end up with some "hackish" code inside RBPlayer.

I agree that (3) is the most "elegant" solution in that it doesn't put
things in places where they don't really fit (i.e. gnome-vfs). As to
having some "hackish" code to deal with setting the properties, etc -
I'm going to need something virtually identical for audio cd support (to
deal with non-/dev/cdrom devices).

After a discussion with some of the gstreamer developers on #gstreamer a
couple of days ago, I have learnt that there is a signal that gets
emitted from playbin, after the source element in constructed, but
before it is used for anything. This can be used to set properties that
are requires for playback.

I've got some thoughts on how to do this, but it involves exposing a
small amount gstreamer stuff to other parts of RB. Step 2 below involves
storing the http headers, cd device, or whatever in the RhythmDbEntry -
how to do this in a backend-neutral way I'm not sure, because the values
are specific to gstreamer. That said, we have removed the xine backend,
my cd audio source _requires_ gstreamer, and the other options for DAAP
have gstreamer-specific bits; substantial parts would need to be
rewritten to support any non-gstreamer backend.

1) Make rb-player take a RhythmDbEntry instead of a simple uri, it can
get the uri from the entry, so this should be a (relatively) simple
change. I'm not aware of any particular reasons against doing this, but
I don't know too much about the internals of rb-player.

2) Add a new field to RhythmDbEntry which lists a mapping of property
names and values that need to be set for the source element. Have
rb-player-gst register a callback for the, which would grab the
names/values from the entry, and set them on the property.

I think this would be one way to solve the issue of how to set
properties on the source element. However there is still an issue for

> The request-id starts at 1, and every time you request another song it
> needs to increment one. 

The request-id isn't something that depends only on the entry to play,
it depends on staeful information, which makes it a bit complex. I'm not
sure on the best way to fit this into my above scheme.


James "Doc" Livingston 
We all enter the world in the same way: naked... screaming... soaked in
blood. But if you live your life right, that kind of thing doesn't have
to stop there.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]