Rhythmbox cannot download some podcasts (port 8000)

Bug #247123 reported by over 5000 on 2008-07-09
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Rhythmbox
Invalid
Medium
rhythmbox (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: rhythmbox

All podcast episodes from http://ueberklang.net/feed/ueberklang_podcast.xml fail.
Other feeds work fine.

I guess this is due to the Überklang-Podcast using Port 8000:
All mp3 urls are like "http://listening.at:8000/ueberklang/ueber060708.mp3", with only the last part (numbers, for the release date) changing.

I can download all episodes from this feed using Miro, so it's a Rhythmbox issue.

JM Williams (jmdwilliams) wrote :

I think that the problem is actually that listening.at refuses to respond
helpfully to an HTTP HEAD request on port 8000: it instead returns a 400 Bad
Request error.

RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, states:

    The metainformation contained in the HTTP headers in response to a HEAD
    request SHOULD be identical to the information sent in response to a GET
    request.
                                http://tools.ietf.org/html/rfc2616#section-9.4

Rhythmbox’s debug output includes:

    rb-podcast-manager.c:699: get_file_info request failed

Presumably, it is making an HTTP HEAD request to find information on the file
that is to be downloaded.

You can verify how http://listening.at:8000 responds to an HTTP HEAD request
by, for example, running:

    curl --head http://listening.at:8000/ueberklang/ueber220608.mp3

In case you do not have curl, I’ll mention that wget’s spider option seems to
work by making HEAD requests; in any case, in this instance it responds in the
same way:

    wget --spider --server-response http://listening.at:8000/ueberklang/ueber220608.mp3

It looks to me that this is not a bug in Rhythmbox, but rather a bug, or at
least undesirable behaviour, in listening.at, so I am marking this bug as
Invalid. Of course, you may wish to contact Überklang to inform them of this
problem.

Changed in rhythmbox:
status: New → Invalid
JM Williams (jmdwilliams) wrote :

It seems that Überklang is running Icecast2, so you could install
apt:icecast2, try to reproduce the bug in that, and file a bug here in
Launchpad or upstream if you manage to do so. There are mailing list posts
from November 2006 regarding Icecast’s lack of support for HTTP HEAD, so I
don’t know how forthcoming a fix would be.

(I didn’t think to visit http://listening.at:8000 in a Web browser before
posting my previous comment, but doing so was irresistible once it was
clickable in the Launchpad Web page!)

So I wrote a mail to tech at ueberklang.net, even though I don't have much hope that anything changes that way.

So I actually installed Icecast2 and I could easily reproduce the bug. I filed Bug 248386 in launchpad, and I hope someone forwards it to their upstream bug tracker.

Icecast seems to be a fine program, though. I began to like it, but then I found out I couldn't stream through my renters' router (don't have access to it to change any configuration), so gone is all the fun.

JM Williams (jmdwilliams) wrote :

For completeness, here is a log to show that Rhythmbox does indeed make a HEAD
request:

    HEAD /ueberklang/ueber220608.mp3 HTTP/1.1
    Host: listening.at:8000
    User-Agent: gnome-vfs/2.22.0 neon/0.25.4
    Keep-Alive:
    Connection: TE, Keep-Alive
    TE: trailers

    HTTP/1.0 400 Bad Request
    Content-Type: text/html

    <b>unknown request</b>

Adam Smith (adam-disc0tech) wrote :

I've confirmed this two ways

1) I used a python program to mock a web server, I've checked it responds to HEAD requests on non-standard ports
2) When I right click on a podcast feed and select properties, I can see that it is not showing the port number on the URL, even though I know it does in the podcast XML.

Changed in rhythmbox (Ubuntu):
status: Invalid → Confirmed
Adam Smith (adam-disc0tech) wrote :
Download full text (7.3 KiB)

Looking at the debug log from both rhythmbox and my test code, I can confirm this. Note that if I change the server and podcast XML to port 80 this test works fine.

When I add the podcast URL, rbox debug output clearly references 8080

(10:06:42) [0x2655ca0] [rb_uri_could_be_podcast] rb-file-helpers.c:596: 'http://localhost:8080/test_podcast_feed.xml' should be Podcast file, HACK
(10:06:42) [0x2655ca0] [rb_podcast_parse_load_feed] rb-podcast-parse.c:168: not checking mime type for http://localhost:8080/test_podcast_feed.xml (should be Podcast file)
(10:06:42) [0x2655ca0] [rb_podcast_parse_load_feed] rb-podcast-parse.c:241: Parsing http://localhost:8080/test_podcast_feed.xml as a Podcast succeeded

My test server confirms it receives a request for the XML

10:06:42.715 DEBUG test_rbox:190 - Podcast XML file requested
10:06:42.720 DEBUG test_rbox:223 - Host: localhost:8080

When I select the TRACK to be played rbox debug clearly is NO LONGER searching for port 80:

(10:10:04) [0xd296a0] [rb_entry_view_row_activated_cb] rb-entry-view.c:2139: row activated
(10:10:04) [0xd296a0] [rb_entry_view_row_activated_cb] rb-entry-view.c:2143: emitting entry activated
(10:10:04) [0xd296a0] [episode_entry_activated_cb] rb-podcast-add-dialog.c:633: search result podcast entry http://localhost/001.mp3 activated
(10:10:04) [0xd296a0] [load_uri_finish] rb-shell.c:2896: found an entry to play
(10:10:04) [0xd296a0] [rb_shell_player_stop] rb-shell-player.c:2124: stopping
(10:10:04) [0xd296a0] [rb_shell_player_set_playing_source_internal] rb-shell-player.c:2060: setting playing source to (nil)
(10:10:04) [0xd296a0] [rb_shell_player_sync_with_source] rb-shell-player.c:1887: playing source: (nil), active entry: (nil)
(10:10:04) [0xd296a0] [rb_shell_set_window_title] rb-shell.c:2397: clearing title
(10:10:04) [0xd296a0] [rb_shell_player_sync_buttons] rb-shell-player.c:1979: syncing with source 0x1028630
(10:10:04) [0xd296a0] [rb_shell_playing_source_changed_cb] rb-shell.c:2240: playing source changed
(10:10:04) [0xd296a0] [rb_shell_player_sync_with_source] rb-shell-player.c:1887: playing source: (nil), active entry: (nil)
(10:10:04) [0xd296a0] [rb_shell_set_window_title] rb-shell.c:2397: clearing title
(10:10:04) [0xd296a0] [rb_shell_player_sync_buttons] rb-shell-player.c:1979: syncing with source 0x1028630
(10:10:04) [0xd296a0] [rb_shell_player_set_playing_source_internal] rb-shell-player.c:2060: setting playing source to 0x1028630
(10:10:04) [0xd296a0] [rb_shell_player_sync_with_source] rb-shell-player.c:1887: playing source: 0x1028630, active entry: (nil)
(10:10:04) [0xd296a0] [rb_shell_set_window_title] rb-shell.c:2397: clearing title
(10:10:04) [0xd296a0] [rb_shell_player_sync_buttons] rb-shell-player.c:1979: syncing with source 0x1028630
(10:10:04) [0xd296a0] [rb_shell_playing_source_changed_cb] rb-shell.c:2240: playing source changed
(10:10:04) [0xd296a0] [rebuild_menu] rb-display-page-menu.c:211: building menu, 0 => 0 items
(10:10:04) [0xd296a0] [rb_player_gst_try_audio_sink] rb-player-gst-helper.c:101: audio sink autoaudiosink changed to READY state successfully
(10:10:04) [0xd296a0] [construct_pipeline] rb-player-gst.c:738: pipeline construction complete
(10...

Read more...

Changed in rhythmbox:
importance: Unknown → Medium
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.