PDA

View Full Version : Help with stripAnchorFromURL ?



2eleven
2007-02-12, 15:45
Hi Folks,

I filed this bug a while back and finally decided to see if I could just fix it:

http://bugs.slimdevices.com/show_bug.cgi?id=4709

I've isolated the problem to this code from Util::Misc::stripAnchorFromURL:

if ($url =~ /^(.*)#[\d\.]+-.*$/) {
return $1;
}

Wherein, presumably an html anchor gets stripped from the tail end of a path so that the extension may be gathered by Music::Info::typeFromPath. The problem is the regular expression is picking up things it shouldn't - like some of my album directories (Westwood One #01-23, for example).

I think the right fix is to make the regexp a little smarter, but I don't know squat about url anchors, so I wouldn't be able to come up with a smart regexp. Since I ~think~ anchors only exist in html, perhaps we could match a case insensitive .html# or .htm# rather than # as the leading part of the expression.

Anybody know for sure?

Thanks,

John

2eleven
2007-02-12, 17:03
From what I can tell, the 'anchor' here isn't an html anchor, so I really have no idea what the proper way to match it is. Looks like Dan is the father of stripAnchorFromURL:

http://svn.slimdevices.com/trunk/server/Slim/Utils/Misc.pm?rev=3540&view=rev

Maybe he can provide some insight? This is the first time I've looked at the slimserver code, so I feel a litte in the dark.

Thanks,

John

JJZolx
2007-02-13, 11:40
From what I can tell, the 'anchor' here isn't an html anchor, so I really have no idea what the proper way to match it is. Looks like Dan is the father of stripAnchorFromURL:

http://svn.slimdevices.com/trunk/server/Slim/Utils/Misc.pm?rev=3540&view=rev

Maybe he can provide some insight? This is the first time I've looked at the slimserver code, so I feel a litte in the dark.

^(.*\..{2,4})#[\d\.]+-.*$

You might try the regex above. This will only match that anchor pattern if it immediately follows a two to four character long file extension. There's a possibility that even that could appear within a folder name, but it's less likely.

You should file a bug report.

kdf
2007-02-13, 11:47
Quoting JJZolx <JJZolx.2lyigz1171392302 (AT) no-mx (DOT) forums.slimdevices.com>:


> You should file a bug report.

the "anchor" in this case, most likely has to deal with cue sheets
(the anchor specifies the time index. I believe here are bugs already
filed for this.
-kdf

JJZolx
2007-02-13, 12:38
> You should file a bug report.

the "anchor" in this case, most likely has to deal with cue sheets
(the anchor specifies the time index. I believe here are bugs already
filed for this.

You're right. Here they are. Same bug.

http://bugs.slimdevices.com/show_bug.cgi?id=4652
http://bugs.slimdevices.com/show_bug.cgi?id=4709

I posted a patch in bug 4652. I'm making the assumption that applicable (music) file extensions are 2-4 characters in length. This isn't a perfect fix, but I'll bet it fixes most of the problems.

2eleven
2007-02-13, 13:07
Thanks for the patch - I agree - it should address 99% of cases.

Regarding bug 4652, it seems slightly different, and I don't know if this patch will fix that one. From the bug:

"On the 'Got' line, the path is truncated at the # character, after URI->path() function is called."

The log entry given shows a filename that would not match the regexp in stripAnchorFromURL. It would appear that URI->path() might strip things from any # on, though I'd have to look at it closer to be sure.

I think these are two seperate bugs, with similar symptoms.

Thanks,

John

Craig, James \(IT\)
2007-02-14, 03:09
> It would appear that URI->path() might strip things from any # on,
though I'd have to look at it closer to be sure.

It does, apparently a # character is a 'fragment anchor' when used in a
URI which causes this effect...

> I think these are two seperate bugs, with similar symptoms.

I agree.

James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

JJZolx
2007-02-14, 11:52
My bad. Yes, they're separate issues.

Regarding bug 4652, I just did a few tests and don't have any issues with file names containing the # character. They index correctly, display correctly in both the web ui and the remote interface, and they're playable. So is this problem evident only when calling status.txt?

Craig, James \(IT\)
2007-02-15, 03:02
Yes, it seems to work fine within SlimServer because all URLs are
double-escaped before they hit this function.
So, I fixed the problem by double-escaping my calls to status.txt, but
it did seem a bit dangerous to me.

James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

2eleven
2007-02-15, 10:31
So, since I'm new here, I'm going to ask a dumb question. Jim has attached a patch to the bug, but who actually checks this stuff in? Is there a code review process? I hunted around in the wiki, but couldn't find a lot of information on this.

kdf
2007-02-16, 11:45
On 15-Feb-07, at 9:31 AM, 2eleven wrote:

>
> So, since I'm new here, I'm going to ask a dumb question. Jim has
> attached a patch to the bug, but who actually checks this stuff in? Is
> there a code review process? I hunted around in the wiki, but couldn't
> find a lot of information on this.
>
The process is to file a bug report and attach the patch. As this has
been done, it will eventually be reviewed and targetted in turn with
all the rest of the filed bugs/requests. As you can imagine, the
efficiency of this can depend highly upon well-written summaries,
direct and informative reports. A number of reports end up simply
being support issues; no bug, just a long time spent trying to inch
through an issue. Good new is, you can edit the code and use the patch
immediately, as long as you use slimserver.pl to run slimserver.

-kdf

JJZolx
2007-02-16, 12:07
What exactly is going on with SlimServer development right now?

It appears as though nearly all development on SlimServer has stopped. Even bugs, both major and minor, are no longer being addressed and fixed with the same urgency that they once were.

SlimServer on Windows right now is a mess, with all the problems with Vista (Microsoft's completely unexpected OS release) and the problems with running SlimServer in userland and the odd decision to install SlimServer's MySQL as a service.

kdf
2007-02-16, 12:13
just so misconcieved...there isn't a response for that. sorry.
-kdf