Bug 569 - When there is conma "," or period "." in the file name, SB cannot display after it.
: When there is conma "," or period "." in the file name, SB cannot display aft...
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: unspecified
: PC All
: P2 normal (vote)
: ---
Assigned To: KDF
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-21 17:24 UTC by Ken Hokugo
Modified: 2008-09-15 14:37 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
use raw filename for plainTitle (855 bytes, patch)
2004-09-22 10:19 UTC, KDF
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Hokugo 2004-09-21 17:24:53 UTC
I have reported this a while ago on the discuss list but no one confirmed.  
However it is there in my set-up and I believe it has something to do with the 
firmware.  It's been consistent since my purchase in July.

Points to be clarigied:
- iTunes is not utilized for SB operation (but CDs are ripped by iTunes).  
Ripped via iTunes, the files are relocated to my special folder under nicely 
structured directories.
- I only browse from music folder
- In many classical CDs, the track names are long and often includes "," or "." 
in the track title.
- The title should be exactly the .wav file name, excluding ".wav" portion.
- When there is "," or ".", SB cannot display the rest of the title.  For 
example, when the file name is "Concerto No.2 Allegro", the SB displays 
only "Concerto No".
- Not too sure whether the behavior is the same for the similar situations.

Thanks for your attention.
Comment 1 KDF 2004-09-21 18:28:13 UTC
This is likely the result of the Guess Tags. They try to match the file name and
create tags to fit.  If you wish to have filename only, you can change your
server settings, formatting.  Then wipe out each of the guesstags lines.  You
might also just want to try a simple entry of TITLE if that is what your
filename is meant to be.
Comment 2 Ken Hokugo 2004-09-22 07:21:52 UTC
Thanks.  I tried both of your suggestions but no change.  But I agree that the 
guesstag has something to do with this.

Specific example:
File name is "1-01 Concerto No. 1 F major.wav".  Both screen and display 
shows "1-01 Concerto No" and that is it.  All the tracks in that CD is named 
that way and they all show "x-xx Concerto No".  Now, the server setting-
formatting, I changed to "TITLE" and clicked "Change".  No change.  Rescan.  No 
change.  Delete all the guesstag lines.  Rescan.  No change.

Maybe the space between "No." and "1" may be bad?  I deleted the space.  
Rescan.  Wow, the track name is GONE!  The screen shows the existence of the 
track, but no associated track name.  I put the space back in.  Rescan.  The 
track name never came back.  I had to uninstall and re-install the 5.3.0.  The 
track name came back as it was (meaning, imcomplete wrong track name).  Isn't 
this a bug?

Anyway, I kind of agree the guess lines may have something to do.  But how 
should I re-define the guesstags so that the guesstag would understand the "." 
and/or "," is actually a part of the title?  The structure or mechanism of 
guesstag line is not so clear to me.
Comment 3 KDF 2004-09-22 10:03:40 UTC
I tried this out, using d_info and I can certainly see the server deciding on
the 'plain title' just as you have outlined.  I haven't looked up that part of
the code, but I am guessing that's some sort of fallback when it doesn't match
any guesstags.

here is the log:
2004-09-22 10:07:30.1406 Request for CT on file
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
2004-09-22 10:07:30.1406 cache miss for
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
2004-09-22 10:07:30.1406 Converting
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav to
D:\mp3\test\1-01 Concerto No. 1 F major.wav
2004-09-22 10:07:30.1406 wav file type for
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
2004-09-22 10:07:30.1406 Updating cache for:
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
2004-09-22 10:07:30.1562 Info: no title found, using plain title for
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
2004-09-22 10:07:30.1562 Guessing tags for:
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
2004-09-22 10:07:30.1562 Using format "(ARTIST - ALBUM) TRACKNUM - TITLE" =
/\(([^\/]+) - ([^\/]+)\) (\d+) - ([^\/]+)/...
2004-09-22 10:07:30.1562 Using format "/ARTIST/ALBUM/TRACKNUM - TITLE" =
//([^\/]+)/([^\/]+)/(\d+) - ([^\/]+)/...
2004-09-22 10:07:30.1562 Using format "/ARTIST/ALBUM/TRACKNUM TITLE" =
//([^\/]+)/([^\/]+)/(\d+) ([^\/]+)/...
2004-09-22 10:07:30.1562 Using format "/ARTIST/ALBUM/TRACKNUM. TITLE" =
//([^\/]+)/([^\/]+)/(\d+)\. ([^\/]+)/...
2004-09-22 10:07:30.1562 Plain title for: D:/mp3/test/1-01 Concerto No. 1 F major
2004-09-22 10:07:30.1562  is 1-01 Concerto No
2004-09-22 10:07:30.1562 Newsong: 1 for
file:///D:/mp3/test/1-01%20Concerto%20No.%201%20F%20major.wav
Comment 4 KDF 2004-09-22 10:19:29 UTC
Created attachment 138 [details]
use raw filename for plainTitle

aha...I found it.  ever since guesstags was inserted, it removes the .WAV from
teh filename.  so, when it passes to plainTitle, another suffix is removed.
passing the full filename instead of a munged one is the proper way to go.
Comment 5 Ken Hokugo 2004-09-22 10:46:44 UTC
Thanks.  I am getting it.  Exactly, "." makes the s/w confuse it with the end 
of the file name (after which is just the extension of the file), right?  Is 
there anything else I should do on my side?  I thought I saw the same behavir 
with ",".  I will find out tonight.

Good work, kdf!
Comment 6 KDF 2004-09-22 11:10:24 UTC
I tried adding a comma in the filename you give in yoru example and it cam up
fine with the patch I've already put in here.  I've also sent the patch to Dean
for review.  In all likelyhood it will be in tomorrows build, so you can test it
out then.  If you are running the non-slim.exe version, then you can try the
patch out ahead of time.  Otherwise, let me know what you find with tomorrow's
build and we can close this off if all is well.
Comment 7 KDF 2004-09-22 12:20:07 UTC
*** Bug 362 has been marked as a duplicate of this bug. ***
Comment 8 Ken Hokugo 2004-09-24 19:25:51 UTC
9/24 nightly (fw 39) does not seem to cure this issue.  Has it been 
incorporated?
Comment 9 KDF 2004-09-24 22:21:34 UTC
yes, it has.  you may need to wipe the cache.
server settings, performance..wipe cache
Comment 10 Ken Hokugo 2004-09-24 22:56:54 UTC
Oh my!
Yes, it is working.  Now this bug has been fixed, for me at least.  Thanks!
Comment 11 KDF 2004-09-25 01:47:10 UTC
we'll update the DBversion to force a rescan on the next full release so that it
should work for everyone.
Comment 12 Chris Owens 2006-06-16 14:40:35 UTC
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.