GNOME Bugzilla – Bug 608382
Imported files without title metadata show %20 in name
Last modified: 2010-09-12 16:34:58 UTC
Created attachment 152523 [details] Screenshot illustrating the problem Videos imported seem to be assigned whatever they contain as title in their metadata as a "Name" for showing up in the Banshee UI. If such a title tag is not available, the file name is used instead. Problem in the current version is that spaces are shown as %20, and not as spaces.
*** Bug 608873 has been marked as a duplicate of this bug. ***
I can confirm I experience the same issue.
*** Bug 614621 has been marked as a duplicate of this bug. ***
This should be a very easy bug to fix, should be just a tweak somewhere around http://git.gnome.org/browse/banshee/tree/src/Core/Banshee.Core/Banshee.Streaming/StreamTagger.cs#n204
Created attachment 158668 [details] [review] Potential patch
My patch just changes the relevant access of track.Uri.AbsoluteUri to track.Uri.LocalPath to force it to format the string properly (i.e., not as a URI, but specifically as a local file name). I haven't tested this, but if the Mono System.Uri acts like .NET's, and hopefully it would, this should fix the bug.
Review of attachment 158668 [details] [review]: This won't work for non-local files (supported via our GIO backend).
(In reply to comment #7) > Review of attachment 158668 [details] [review]: > > This won't work for non-local files (supported via our GIO backend). OK, I wasn't aware that support was there; my mistake. In that case, a decision may need to be made, because it might be desirable to leave the behavior as it is for non-local URIs and only display actual spaces for local files.
Does System.Web.HttpUtility.UrlDecode (System.IO.Path.GetFileNameWithoutExtension (track.Uri.AbsoluteUri)) work?
That should definitely work, from the documentation of the method: "If characters such as blanks and punctuation are passed in an HTTP stream, they might be misinterpreted at the receiving end. URL encoding converts characters that are not allowed in a URL into character-entity equivalents; URL decoding reverses the encoding. For example, when embedded in a block of text to be transmitted in a URL, the characters < and > are encoded as %3c and %3e."
*** Bug 621932 has been marked as a duplicate of this bug. ***
I compiled the code with the changes suggested by Gabriel Burt and it works!
Please attach a patch, produced with `git format-patch HEAD~1`
Created attachment 164334 [details] [review] git formatted patch
Created attachment 164335 [details] [review] git formatted patch
Gabriel Burt: is the patch ok? can you commit?
*** Bug 623871 has been marked as a duplicate of this bug. ***
Review of attachment 164335 [details] [review]: Thanks Nicolo, committed.
*** Bug 628372 has been marked as a duplicate of this bug. ***