GNOME Bugzilla – Bug 583655
Some URLs for podcasts get broken, podcasts cannot be downloaded
Last modified: 2020-03-17 08:23:40 UTC
Please describe the problem: After bugfix for #574605 there are new rss feeds working. Unfortunately the files cannot be downloaded. The direct playback works, download does not. Manual download of enclosures works. The URL contains two slashes in the path. One of these slashes disappears. Example feed URL: http://rss.spokenword.org/feed/2629 One of enclosure URLs: http://media.spokenword.org/i276464/http://media.libsyn.com/media/macosken/macosken090522.mp3 The malformed URL dumped to console on call to HttpFileDownloadTask (string remoteUri, string localPath, object userState) http://media.spokenword.org/i276464/http:/media.libsyn.com/media/macosken/macosken090522.mp3 Steps to reproduce: 1. add RSS feed: http://rss.spokenword.org/feed/2629 2. try to download one of recent podcasts 3. Actual results: Feed is recognised, enclosures are listed On download status is shown, but download fails Expected results: 1. The download to succeed 2. On unsuccessful download a descriptive error message/description Does this happen every time? yes Other information: Here are a few lines from the console -- first is 'my' debug message from OnDownloadFileCompletedHandler, the rest comes with --debug switches OnDownloadFileCompletedHandler (): http://media.spokenword.org/i276464/http:/media.libsyn.com/media/macosken/macosken090522.mp3 Running [Warn 17:44:17.523] HttpDownloadTask Mac OS Ken - Mac OS Ken: 05.22.2009 Error: System.Net.WebException: The remote server returned an error: (404) Not Found. at System.Net.HttpWebRequest.CheckFinalStatus (System.Net.WebAsyncResult result) [0x00000] at System.Net.HttpWebRequest.SetResponseData (System.Net.WebConnectionData data) [0x00000] [Debug 17:44:17.539] Executed in 2ms SELECT CoreTracks.Rating,CoreTracks.LastStreamError,CoreTracks.TrackID,CoreTracks.PrimarySourceID,CoreTracks.ArtistID,CoreTracks.AlbumID,CoreTracks.TagSetID,CoreTracks.MusicBrainzID,CoreTracks.MimeType,CoreTracks.FileSize,CoreTracks.FileModifiedStamp,CoreTracks.LastSyncedStamp,CoreTracks.Attributes,CoreTracks.Title,CoreTracks.TitleSort,CoreTracks.TrackNumber,CoreTracks.TrackCount,CoreTracks.Disc,CoreTracks.DiscCount,CoreTracks.Duration,CoreTracks.Year,CoreTracks.Genre,CoreTracks.Composer,CoreTracks.Conductor,CoreTracks.Grouping,CoreTracks.Copyright,CoreTracks.LicenseUri,CoreTracks.Comment,CoreTracks.BPM,CoreTracks.BitRate,CoreTracks.Score,CoreTracks.PlayCount,CoreTracks.SkipCount,CoreTracks.ExternalID,CoreTracks.LastPlayedStamp,CoreTracks.LastSkippedStamp,CoreTracks.DateAddedStamp,CoreTracks.DateUpdatedStamp,CoreTracks.Uri,CoreArtists.Name,CoreArtists.NameSort,CoreAlbums.Title,CoreAlbums.TitleSort,CoreAlbums.ArtistName,CoreAlbums.ArtistNameSort,CoreAlbums.IsCompilation FROM CoreTracks,CoreAlbums,CoreArtists WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND PrimarySourceID = 5 AND ExternalID = 1 LIMIT 1 [Debug 17:44:17.541] Executed in 1ms UPDATE CoreTracks SET Rating = 0,LastStreamError = 0,PrimarySourceID = 5,ArtistID = 1,AlbumID = 1,TagSetID = 0,MusicBrainzID = NULL,MimeType = 'audio/mpeg',FileSize = 8976953,FileModifiedStamp = 0,LastSyncedStamp = NULL,Attributes = 21,Title = 'Mac OS Ken: 05.22.2009',TitleSort = NULL,MetadataHash = '5e7d68db21e08e0c9beb5d8dce2f6e97',TrackNumber = 0,TrackCount = 0,Disc = 0,DiscCount = 0,Duration = 735000,Year = 2009,Genre = 'Podcast',Composer = NULL,Conductor = NULL,Grouping = NULL,Copyright = NULL,LicenseUri = NULL,Comment = NULL,BPM = 0,BitRate = 0,Score = 0,PlayCount = 0,SkipCount = 1,ExternalID = 1,LastPlayedStamp = NULL,LastSkippedStamp = 1243095832,DateAddedStamp = 1243095771,DateUpdatedStamp = 1243097057,Uri = 'http://media.spokenword.org/i276464/http://media.libsyn.com/media/macosken/macosken090522.mp3',TitleSortKey = X'0E510E020E0A07020E7C0E9107020E360E210E70073707020C030C6A07330C330C3307330C330C030C030CB40101010100',TitleLowered = 'mac os ken 05222009' WHERE TrackID = 1
Paul, thanks for your report and your investigations. You're right, the / gets dropped when the URL string is put into a System.Uri class, in the HttpFileDownloadTask constructor : this.remoteUri = new Uri (remoteUri); However, I'm not sure this is a bug in the Uri class, as this behavior seems to be right according to the docs (http://msdn.microsoft.com/en-us/library/system.uri.aspx) : "the Uri constructor (...) canonicalizes the path for hierarchical URIs by compacting sequences such as /./, /../, //" Ideas welcome...
But the 'streaming' works, I can play the not downloaded mp3 from within banshee. How is it handled there? Workaround by escaping those sequences? Or retry with 'escaped' sequence if the first try fails? The retry option is difficult to be interpreted if the web server redirects on fail instead of 404. I am C/C++/Perl/Matlab developer I have no experience with .NET, sorry.
Further info: I tried to trick Uri class escaping the double slash with hex notation http://media.spokenword.org/i276464/http://media.libsyn.com/media/macosken/macosken090522.mp3 as http://media.spokenword.org/i276464/http:/%2Fmedia.libsyn.com/media/macosken/macosken090522.mp3 The Uri canonicalisation gets disabled and the string goes as http://media.spokenword.org/i276464/http://media.libsyn.com/media/macosken/macosken090522.mp3 But it does so only at ToString(). The version sent over the wire contains my original escape http://media.spokenword.org/i276464/http:/%2Fmedia.libsyn.com/media/macosken/macosken090522.mp3 And what is really strange (confirmed with wget) the Web server does not interprete the % sign and reports 404. I have no ideas. How does the 'streaming'/playback code does this? The site spokenword.org has really a bunch of nice podcasts, I'm not willing to give up on this.
I have contacted Doug Kaye about this problem with his site. It looks like he is willing to fix the URLs, but it may take some time till he gets to it. My problem would disappear, but the problem of handling buggy URIs is still there. Even if the issue becomes WONTFIX (i hope not) there must be appropriate user feedback also pointing to the issue of not correct URLs. I am still convinced, that if banshee can play the MP3 it can also download it.
It seems like the behavior of the System.Uri class is different from MS .NET 3.5, so I opened a bug with mono : https://bugzilla.novell.com/show_bug.cgi?id=506734 The streaming is done directly by gstreamer, so it's doing things differently. But streaming doesn't work for me either. Changing the URLs on the site might be a good idea anyway, as the second "http://" is redundant : they're not going to do the redirection using else than HTTP.
Apparently a major radio station in France also switched to a similar redirection scheme, and its podcasts cannot be downloaded anymore with banshee. See this feed as an example : http://radiofrance-podcast.net/podcast09/rss_10692.xml I'll try to find a workaround in banshee.
*** Bug 622824 has been marked as a duplicate of this bug. ***
*** Bug 628610 has been marked as a duplicate of this bug. ***
*** Bug 630563 has been marked as a duplicate of this bug. ***
*** Bug 643052 has been marked as a duplicate of this bug. ***
*** Bug 616577 has been marked as a duplicate of this bug. ***
I have Mono 2.8.2 and couldn't reproduce the bug with any of these podcasts: http://rss.spokenword.org/feed/2629 http://feeds.twis.org/twis/science/ http://radiofrance-podcast.net/podcast09/rss_11558.xml Is anybody seeing this that is running Mono >= 2.6?
I can reproduce this with Mono 2.6.7 and http://radiofrance-podcast.net/podcast09/rss_11558.xml
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.