On Tue, Jun 07, 2005 at 11:40:43PM +0100, Bastien Nocera wrote: > More updates. > > [...] > > > patch-13 > > HACK: work around broken shoutcast servers not responding to HTTP > > HEAD requests > > That obviously won't make it. Is there a bug number/test case for this? > The same problem was happening with Totem, and it got fixed with a more > recent gnome-vfs, and the neon HTTP backend.
Test case is pretty simple: try to add 'http://server2.somafm.com:8000/listen.pls' as an iradio station. It appears, sits there for a while, then disappears. That isn't the URL that www.somafm.com tells you to use, but there are a few streams around that do use the '/listen.pls' from the shoutcast/icecast server. I'm using gnome-vfs 2.10.1 (Debian package from experimental) with the neon HTTP backend. > > patch-15 > > drag/drop of iradio streams from browsers into radio source > > patch-16 > > set iradio stream name and genre from stream metadata if not > > already set > > Doesn't that clash with the port to playbin? Sort of. It doesn't work with playbin at the moment, but it (or a variation of it) should eventually. > > patch-17 > > make setting iradio stream properties from stream metadata > > actually work > > Is that on top of patch-16? Yes. > > patch-23 > > fix amg urls (perhaps), use urls from artist/album fields > > (netlabels) > > Committed (I fixed the non-C89 declaration in there :) Some day I'll learn to actually check for these things.. > > patch-24 > > make file choosers not local-only again (again?) > > Committed the API change part, but I set the defaults to be non-local, > as it deadlocks with the good ol' "sftp with password" trick. > Totem test case here (we used to hang as well, but I removed all use of > gdk_enter and leave_threads): > http://bugzilla.gnome.org/show_bug.cgi?id=154796 > Original bug: > http://bugzilla.gnome.org/show_bug.cgi?id=162989 Fair enough. > > patch-39 > > possibly fix weirdness with cursor position jumping while editing > > search box (#171008) > > As I can't reproduce the problem, I won't commit this one just yet (only > appears on "slower" machines?) I can reproduce it on a 3GHz P4 with around 10000 songs in rhythmdb. It's entirely subjective, but I find the search box is much easier to use with this patch in place. > > patch-44 > > apply playlist manager dirty flag fix (necessary for something > > else i'm about to fix) > > What is this last one needed for? Is it OK to merge even though it's > only part of a larger patch? (And what would this larger patch do?) It was needed for patch-45 (which doesn't seem to be in Christophe's patch pile), which fixed #304519. It's useful on its own, as it fixes #166340. > Pennies to the person who manages to track down: > http://bugzilla.gnome.org/show_bug.cgi?id=306819 Is this the one where you get some strange ORBit-related messages on stdout? Right on cue, it just happened again: ** ERROR **: file poa.c: line 1025 (ORBit_POA_activate_object_T): assertion failed: ((poa->life_flags & ORBit_LifeF_DeactivateDo) == 0) aborting... This one has always scared me too much to seriously investigate it. thanks, -jonathan. _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
