Closed GoogleCodeExporter closed 9 years ago
Reproduced, will take a look at it later on.
Original comment by phree...@gmail.com
on 5 Oct 2009 at 10:59
Issue 13 has been merged into this issue.
Original comment by phree...@gmail.com
on 6 Oct 2009 at 10:57
[deleted comment]
I added some pseudo-debug code in Util.cpp, in the method "GetCachedMusicThumb".
(diff shown at the end of this text.)
It basically dumps path and calculated crc to the log.
Now, note the quite interesting outputs below:
When XBMC scans a directory to the music library:
-----SNIP-----
03:43:19 T:3041601424 M:3479248896 DEBUG: Mikkle: doing crc for path:
[/media/nas/Music/System Of A Down/Mezmerize]
03:43:19 T:3041601424 M:3479248896 DEBUG: Mikkle: no-slashed path:
[/media/nas/Music/System Of A Down/Mezmerize]
03:43:19 T:3041601424 M:3479248896 DEBUG: Mikkle: resulting thumb:
[8/89c19c65.tbn]
-----SNAP-----
When I call the HTTP API interpreted as "Album;Artist":
http://10.22.42.2:8080/xbmcCmds/xbmcHttp?
command=GetThumbFileName(Mezmerize/;System%20Of%20A%20Down)
-----SNIP-----
03:54:53 T:3041601424 M:3423170560 DEBUG: Mikkle: doing crc for path:
[Mezmerize/System Of A Down]
03:54:53 T:3041601424 M:3423170560 DEBUG: Mikkle: no-slashed path:
[Mezmerize/System Of A Down]
03:54:53 T:3041601424 M:3423170560 DEBUG: Mikkle: resulting thumb:
[e/ee2c2e38.tbn]
-----SNAP-----
When I call the HTTP API interpreted as "Album;Full-Path-To-Artist":
http://10.22.42.2:8080/xbmcCmds/xbmcHttp?
command=GetThumbFileName(Mezmerize;/media/nas/Music/System%20Of%20A%20Down)
-----SNIP-----
03:57:10 T:3041601424 M:3422384128 DEBUG: Mikkle: doing crc for path:
[Mezmerize/media/nas/Music/System Of A Down]
03:57:10 T:3041601424 M:3422384128 DEBUG: Mikkle: no-slashed path:
[Mezmerize/media/nas/Music/System Of A Down]
03:57:10 T:3041601424 M:3422384128 DEBUG: Mikkle: resulting thumb:
[c/c70a78f1.tbn]
-----SNAP-----
When I call the HTTP API interpreted as "Full-Path-To-Artist;Album":
http://10.22.42.2:8080/xbmcCmds/xbmcHttp?
command=GetThumbFileName(/media/nas/Music/System%20Of%20A%20Down/;Mezmerize)
-----SNIP-----
03:58:55 T:3041601424 M:3422457856 DEBUG: Mikkle: doing crc for path:
[/media/nas/Music/System Of A Down/Mezmerize]
03:58:55 T:3041601424 M:3422457856 DEBUG: Mikkle: no-slashed path:
[/media/nas/Music/System Of A Down/Mezmerize]
03:58:55 T:3041601424 M:3422457856 DEBUG: Mikkle: resulting thumb:
[8/89c19c65.tbn]
-----SNAP-----
The documentation for GetThumbFileName says: GetThumbFilename(album;location)
This is obviously wrong, it's the other way around!
Andorid-XBMC-Remote calls the HTTP API interpreted as "Album;Artist" as above.
This shouldn't work at all, so I can't really figure out why some album covers
do
make
it onto the android device!(?)
Anyway, this finding explains why - at least - some of the covers are missing
in the
album view.
Any thoughts? Should this behaviour be raised as a bug in XBMC (at least the
docs
should be reviewd, I guess)
:O) Mikkle
The diff for producing the above output follows here:
-----SNIP-----
Index: Util.cpp
===================================================================
--- Util.cpp (revision 23588)
+++ Util.cpp (working copy)
@@ -3219,14 +3219,17 @@
CStdString CUtil::GetCachedMusicThumb(const CStdString& path)
{
+ CLog::Log(LOGDEBUG, "Mikkle: doing crc for path: [%s]", path.c_str());
Crc32 crc;
CStdString noSlashPath(path);
RemoveSlashAtEnd(noSlashPath);
+ CLog::Log(LOGDEBUG, "Mikkle: no-slashed path: [%s]", noSlashPath.c_str());
crc.ComputeFromLowerCase(noSlashPath);
CStdString hex;
hex.Format("%08x", (unsigned __int32) crc);
CStdString thumb;
thumb.Format("%c/%s.tbn", hex[0], hex.c_str());
+ CLog::Log(LOGDEBUG, "Mikkle: resulting thumb: [%s]", thumb.c_str());
return CUtil::AddFileToFolder(g_settings.GetMusicThumbFolder(), thumb);
}
-----SNAP-----
Original comment by mukkenb...@gmail.com
on 11 Oct 2009 at 2:12
Thanks Mikkle, that help a lot!
I think XBMC has different ways of treating the covers. One way is when the
cover is
read from the ID3 tag of the MP3 file, then you can access it by crc(name +
artist).
The other way is when there's a folder.jpg in the albums directory. Then
obviously it's
not linked to the name of the album but to the physical path.
I'll investigate further and see if we can have a fallback that doesn't cost
too much.
Original comment by phree...@gmail.com
on 11 Oct 2009 at 9:41
Added download-by-path in revision 166, more stable since revision 179.
Original comment by phree...@gmail.com
on 12 Oct 2009 at 4:42
Original issue reported on code.google.com by
f.dallme...@gmail.com
on 4 Oct 2009 at 11:04