PDA

View Full Version : Intermittent cover art?


jaga
2004-03-14, 22:52
i have created a folder.jpg for all my music folders, and when they display, they look great. however, not all of them display, and it's not the same ones that don't show each time. what i mean by this is that sometimes all the shallow (top level) icons show while none of the deeper ones do. other times, it's only one large folder (deep) folder that shows while all others don't. when i look at xbmc.log, the [relevant] messages i see are:

14-03-2004 13:50:22 picture::docreatethumbnail: unable to cache file xbms://192.168.2.5:1400/audio/sublime/1996 - sublime/folder.jpg

and this is repated a whole lot. i'm using ccxstream on linux and everything works well. when i go into q: -> albums -> thumbs -> temp and delete everything, it seems to recache some of them, but not all. is there a maximum # of thumbs that it can have cached? does anyone have any tips/ideas/hints/suggestions for me?

--jaga

burriko
2004-03-15, 01:55
i have pretty much the same problem. i have folder.jpg images for all of my albums, yet some of them don't show and i can't figure out why.

jaga
2004-03-15, 02:28
do you have the same (or a similar) error in xbmc.log? is there any way to increase the debugging level so that we might get a more informative message? are you using ccxstream or another transport? i know covert art is considered 'fluff' by a lot of people, but it really makes things look a lot better (especially combined with this latest/greatest skin + fountain.vis).

--jaga

jaga
2004-03-15, 03:46
ok, i believe i've found the problem. i'm not sure if it's the xbox as a whole, or xbmc, or the xdk, but as soon as it encounters a 0 byte file, everything gets f'd. so, take a look through your folder.jpg's to make sure all are valid, and none are 0 bytes. if your on a linux/unix/bsd system try this:
find <some path> -name "folder.jpg" -size 0b -ls
it would be nice if xbmc could report this in it's log, but i think it may be a larger xdk issue.
--jaga

burriko
2004-03-15, 14:16
i'm using smb shares. i've checked and there are 3 zero byte folder.jpg files, but they are for albums that i've never played in xbmc so i don't think xbmc will have ever seen those folders.
i haven't had a chance to check the log file yet.

did deleting the 0 byte files completely fix the problem for you?

jaga
2004-03-15, 18:17
afaik, the way xbmc displays it's thumbnails is to look for a folder.jpg inside each of the 1st level child directories. so if you have a directiory /albums/ *and in there you have the folders album1, album2, and album3 inside of that, xbmc will look in each of those folder/directories for folder.jpg -- even if you never play album3. once any xbox program [that i've come across, so it must be the xdk] encounters a 0 size file, you can't really count on anything working reliably. i'm sure one of the developers could shed some light on this, but deleting those bad files fixed my problem.
* * * * * *--jaga

burriko
2004-03-15, 19:37
it seems our problems are different. deleting the zero byte files didn't help. i have noticed this in xbmc's log though which is obviously the culprit.

15-03-2004 17:21:22 picture::docreatethumbnail: exception: z:\cachedpic.jpg

and once that has happened i then get the following each time xbmc tries to load a folder.jpg.

15-03-2004 17:24:11 picture::docreatethumbnail: unable to cache file smb://192.168.0.2/music/american analog set/promise of love/folder.jpg

so i need to try and work out why certain folder.jpg images cause an exception in docreatethumbnail. could it be something simple like the filesize is too large? the images that cause a problem are over 150kb, which i suppose is quite large for a small thumbnail.

burriko
2004-03-15, 19:52
i tried resaving the problem jpegs at a higher compression rate, which brought them down from about 150kb to about 25kb, and now they work perfectly. note that i didn't resize them, so the fact they are 300x300 isn't a problem, it's just that the fact that they were 150kb in size.

burriko
2004-03-15, 20:01
i seemed to have narrowed this down to specific filesizes. every folder.jpg file that is 50kb+ will cause the exception, which then stops any susequent folder.jpg thumbs from being loaded. every folder.jpg that is smaller than 50kb seem to work fine.
can anyone else back this up?

edit: i've gone through and resaved all of the large jpegs, and now everything is working fine. i don't think filesize was the issue, as i've resaved some at over 100kb and they're working fine, i think the program i'd previously been using to make thumbnails may have been making bad jpegs.

jaga
2004-03-15, 23:34
neat. i wonder if the dev's can put incorporate these finding to produce a more usable log message.
--jaga

pepehdez
2004-03-15, 23:51
i'm having the exact same problem, i'm using my old tbn files from xbmp, all of them are under 10k and they are 64x64, i rename them to folder.jpg and some of them work and some don't.

jaga
2004-03-16, 01:15
we have both fixed our problems by either:
deleting the 0 size files.
-or-
resizing the really large files down to a usable size (under 50k).

what does your xbmc.log say?

Bobbin007
2004-03-16, 15:39
hi all,

i've found a bug in copying files like folder.jpg's when using xbms protocol. (every remote folder.jpg is cached to xbox hdd for faster loading nexttime.) if the filesize is larger then approx. 120k these files will not get copied correctly.

this is fixed in cvs now.

i've also checked the other network protocols, if they show the same behavior and they work as desired. :)

greets

bobbin007

jaga
2004-03-16, 19:08
thank-you. is it possible to also have it ignore the file if it is not a valid jpg image? i.e. often people use automated programs to download the images, and sometimes an html file gets named folder.jpg, or gif file gets named folder.jpg. now xbmc will still try to cache these, and display nothing for the html file, and sometimes display the .gif file (i belive it will display it initially as it loads/caches it, but on subsequent views it shows blank). if it can't ignore it, maybe it could print a log message?
--jaga