Re: [Rhythmbox-devel] Current issues?



On Tue, Jan 17, 2006 at 10:19:23PM +0100, Ernst Persson wrote:
> Search could be faster?
> I remember something about a patch that said that switching playlists
> used to use one signal for every song, and it was much faster to take
> all songs with one signal.
> Should something similar be done for search, or other cases, perhaps?

If you could gather some profiling data (using sysprof or similar) for
various searches, we could have a look at what's actually taking all the
time.  No point optimising something that's only 1% of the work.

> Songs dissapearing from playlists
> If songs in you library can't be found, they will appear in you
> library if they are found
> again. But they will be gone from any playlists forever as soon as
> they are removed!

This is already fixed in CVS.  It was previously reported as bug
#319278.

> Idea:
> "rhythmbox my_song.ogg" should start playing the song and
> "rhythmbox -queue my_song.ogg" should add it to the play que?
> Maybe "rhythmbox -play /dev/cdrom" should start playing an audiocd also?

The current plan is to add all files specified on the commandline to the
play queue.  I also plan to add dbus methods to add songs to playlists
and the play queue, and I've got most of a patch that does this
somewhere.

I think rather than having /dev/cdrom mean "select the audio CD source
corresponding to the device /dev/cdrom and play from it", we need a way
to select any source.  Preferably without referring to device nodes, so
your 'play my CD now' script doesn't break when udev changes its mind
about device naming again.

For some sources, it's pretty straightforward: library, podcast, iradio,
queue.  

For some, you need to specify which instance of the source type:
playlist:<name>, daap:<share|IP|hostname?>[:<playlist>].  

For some, you usually only need the source type, but you may need to
disambiguate if you have more than one:  device[:<mountpoint>] (for
digital audio players; I don't want to abbreviate to 'dap' though),
cd[:<device>].

Further ideas?


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