PDA

View Full Version : %20 in URL



Krobb
2006-02-05, 05:58
Is there a way to show the space (and other chars) in the URL detail? (You get this if you press the right arrow in 'Now playing' or elsewhere while browsing)

Michaelwagner
2006-02-05, 20:58
I noticed this in another context. I believe it got encoded and never unencoded.

I expect it's a bug. You can file a bug report about it and if it's an error, it'll get fixed. I suppose it might be done on purpose, but I can't imagine why.

Mark Lanctot
2006-02-05, 21:06
Isn't this URL shorthand for a space though?

--- Michaelwagner
<Michaelwagner.22sh1b (AT) no-mx (DOT) forums.slimdevices.com>
wrote:

>
> I noticed this in another context. I believe it got
> encoded and never
> unencoded.
>
> I expect it's a bug. You can file a bug report about
> it and if it's an
> error, it'll get fixed. I suppose it might be done
> on purpose, but I
> can't imagine why.
>
>
> --
> Michaelwagner
>
------------------------------------------------------------------------
> Michaelwagner's Profile:
> http://forums.slimdevices.com/member.php?userid=428
> View this thread:
> http://forums.slimdevices.com/showthread.php?t=20796
>
>

Michaelwagner
2006-02-05, 23:45
Isn't this URL shorthand for a space though?

It is the URL encoded version of a space.

But why is the Universal Resource Locator version (encoded or otherwise) of a filename being shown to the user rather than the naked filename itself, without all the URL folderoll?

Krobb
2006-02-06, 00:53
But why is the Universal Resource Locator version (encoded or otherwise) of a filename being shown to the user rather than the naked filename itself, without all the URL folderoll?
It's good in this way. I need the reference URL to know where is that song. (eg. handy to locate doubles).

The problem is only the wrong displaying method.

kdf
2006-02-06, 01:39
Michaelwagner wrote:
> Mark Lanctot Wrote:
>
>> Isn't this URL shorthand for a space though?
>>
>>
> It is the URL encoded version of a space.
>
>
I've changed this in 6.5 for the feb 7 build (probably just missed the
feb6 build). Since the trackinfo is just for user reading, the url is
in human readable form. As the item is a url, it is still in url form
-k

Michaelwagner
2006-02-06, 05:20
(after I wrote it, I realized it has to be a URL because it could be an internet radio station).

KDF: Will this effect the storage of the URL internally? Because I have a problem at the CLI interface where the URL is double encoded (of course, to add confusion, it's called a "path" there). Fred said he was unwilling to change it, because he was just working on the CLI, and that's the way the item was given to him from the internals.

kdf
2006-02-06, 10:32
Quoting Michaelwagner <Michaelwagner.22t4nb (AT) no-mx (DOT) forums.slimdevices.com>:

> KDF: Will this effect the storage of the URL internally? Because I have
> a problem at the CLI interface where the URL is double encoded (of
> course, to add confusion, it's called a "path" there). Fred said he was
> unwilling to change it, because he was just working on the CLI, and
> that's the way the item was given to him from the internals.

The only reason I made the change is that it was at final output
stage. The trackInfo on the player UI is for human reading only. I'm
not in a position to arbitrarily change the way the url is handled
internally either :)

I agree that "path" is an odd descriptor in that case. All file
locations are handled as urls (file urls included) internally.

-k

dip
2006-02-08, 12:20
Will that be changed for the 6.2.* version too?

kdf
2006-02-08, 19:17
On 8-Feb-06, at 11:20 AM, dip wrote:

>
> Will that be changed for the 6.2.* version too?
>
feb 9
-k

dip
2006-02-09, 01:19
Thanks kdf!