murat8505 / android-xbmcremote

Automatically exported from code.google.com/p/android-xbmcremote
0 stars 0 forks source link

Album art shown partially #14

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.select listen to music
2.
3.

What is the expected output? What do you see instead?
Expect all albumart shown in list. Do not see the albumart that is taken
from images in a albumfolder (example cover.jpeg or folder.jpeg) Albumart
added trough xbmc "add album info" is shown.

What version of the product are you using? On what operating system?
0.4.1 bleeding edge on HTC magic fw 1.5 kernel 2.6.27-00393-g6607056
buildnr crc1
XBMC svn pre-9.10 r23321

Please provide any additional information below.
When going to now playing all albumart is shown!

Original issue reported on code.google.com by f.dallme...@gmail.com on 4 Oct 2009 at 11:04

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
Issue 13 has been merged into this issue.

Original comment by phree...@gmail.com on 6 Oct 2009 at 10:57

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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