Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 13
  1. #1
    Member 2eleven's Avatar
    Join Date
    Mar 2006
    Location
    Santa Barbara, CA
    Posts
    88

    Help with stripAnchorFromURL ?

    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

  2. #2
    Member 2eleven's Avatar
    Join Date
    Mar 2006
    Location
    Santa Barbara, CA
    Posts
    88
    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/ser...=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

  3. #3
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,548
    Quote Originally Posted by 2eleven View Post
    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/ser...=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.

  4. #4
    NOT a Slim Devices Employee kdf's Avatar
    Join Date
    Apr 2005
    Posts
    9,493

    Help with stripAnchorFromURL ?

    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

  5. #5
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,548
    Quote Originally Posted by kdf View Post
    > 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.

  6. #6
    Member 2eleven's Avatar
    Join Date
    Mar 2006
    Location
    Santa Barbara, CA
    Posts
    88
    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

  7. #7
    Craig, James \(IT\)
    Guest

    Help with 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.

    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.

  8. #8
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,548
    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?

  9. #9
    Craig, James \(IT\)
    Guest

    Help with stripAnchorFromURL ?

    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.

  10. #10
    Member 2eleven's Avatar
    Join Date
    Mar 2006
    Location
    Santa Barbara, CA
    Posts
    88
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •