PDA

View Full Version : GIF in a JPEG cover.jpg file !



Vince
2005-02-23, 05:44
Hi,
I'm working with nightly build of 5.4.1 and I noticed something
strange. If I request a fake cover art from the slimserver (let's say
http://192.168.0.95:9000/music/test/cover.jpg), I get in return from
the server a 1*1 pixels picture file named cover.jpg, I'm ok for that !
But when you look inside the file, in fact it's a gif file ! (begin of
the file is GIF89a..). Is it normal that server returns a gif file in a
jpeg named file ?
Thanks

Vincèn

kdf
2005-02-23, 11:36
Quoting Vince <mailing (AT) vincen (DOT) org>:

> Hi,
> I'm working with nightly build of 5.4.1 and I noticed something
> strange. If I request a fake cover art from the slimserver (let's say
> http://192.168.0.95:9000/music/test/cover.jpg), I get in return from
> the server a 1*1 pixels picture file named cover.jpg, I'm ok for that !
> But when you look inside the file, in fact it's a gif file ! (begin of
> the file is GIF89a..). Is it normal that server returns a gif file in a
> jpeg named file ?

because cover.jpg is just a url for a thumbnail. if a gif is found, or in this
case...some sort of artwork is detected but no proper image is found, you get
spacer.gif.

check the help section of the slimserver, under technical information for more
details on artwork.

-kdf

Vince
2005-02-23, 13:02
>> I'm working with nightly build of 5.4.1 and I noticed something
>> strange. If I request a fake cover art from the slimserver (let's say
>> http://192.168.0.95:9000/music/test/cover.jpg), I get in return from
>> the server a 1*1 pixels picture file named cover.jpg, I'm ok for that
>> !
>> But when you look inside the file, in fact it's a gif file ! (begin of
>> the file is GIF89a..). Is it normal that server returns a gif file in
>> a
>> jpeg named file ?
> because cover.jpg is just a url for a thumbnail. if a gif is found,
> or in this
> case...some sort of artwork is detected but no proper image is found,
> you get
> spacer.gif.

OK so is there a way that the server sends something else than
spacer.gif ? either by modifying by hand a preference file or by hack
of one of the file of the slimserver ?

Thanks

Vincèn

kdf
2005-02-23, 13:13
Quoting Vince <mailing (AT) vincen (DOT) org>:

> >> I'm working with nightly build of 5.4.1 and I noticed something
> >> strange. If I request a fake cover art from the slimserver (let's say
> >> http://192.168.0.95:9000/music/test/cover.jpg), I get in return from
> >> the server a 1*1 pixels picture file named cover.jpg, I'm ok for that
> >> !
> >> But when you look inside the file, in fact it's a gif file ! (begin of
> >> the file is GIF89a..). Is it normal that server returns a gif file in
> >> a
> >> jpeg named file ?
> > because cover.jpg is just a url for a thumbnail. if a gif is found,
> > or in this
> > case...some sort of artwork is detected but no proper image is found,
> > you get
> > spacer.gif.
>
> OK so is there a way that the server sends something else than
> spacer.gif ? either by modifying by hand a preference file or by hack
> of one of the file of the slimserver ?
>
spacer.gif is hard coded. There are other ways to test if cover art exists so
that you avoid callign for art when non exists. What are you trying to do that
requires this?

-kdf

Jeff Coffler
2005-02-23, 13:26
Hi kdf,

> spacer.gif is hard coded. There are other ways to test if cover art
> exists so
> that you avoid callign for art when non exists. What are you trying to do
> that
> requires this?

Vincen is a tester that's using the NetLinx module I'm writing to drive the
SlimServer.

Or, stated another way, he's working with Fred Thomas and I; Fred makes the
CLI changes, I use the CLI changes to write a NetLinx integration module,
and then Vincen, Fred, and I use the end result with our automation systems.

We require the 1x1 pixel to remove cover art from the touchpanel. There are
other ways to do this, but unfortunately the CLI doesn't currently tell us
when cover art does or does not exist.

Perhaps the solution here is that Fred should add a tag/value in "status" to
give this indication. With that information, I could use another mechanism
to "hide" the cover art (if there isn't any, or if nothing is currently
queued), and then we'd never hit the problem that the new firmware in
NetLinx panels is barfing on rendering spacer.gif.

That's what caused Vincen to look into this issue to begin with (a firmware
upgrade - that I don't have yet - appears to be unable to render spacer.gif
properly).

-- Jeff

kdf
2005-02-23, 14:03
Quoting Jeff Coffler <jeff-list-slimdev (AT) taltos (DOT) com>:

> Hi kdf,
>
> > spacer.gif is hard coded. There are other ways to test if cover art
> > exists so
> > that you avoid callign for art when non exists. What are you trying to do
> > that
> > requires this?
>
> Vincen is a tester that's using the NetLinx module I'm writing to drive the
> SlimServer.
>
> Or, stated another way, he's working with Fred Thomas and I; Fred makes the
> CLI changes, I use the CLI changes to write a NetLinx integration module,
> and then Vincen, Fred, and I use the end result with our automation systems.
>
> We require the 1x1 pixel to remove cover art from the touchpanel. There are
> other ways to do this, but unfortunately the CLI doesn't currently tell us
> when cover art does or does not exist.
>
> Perhaps the solution here is that Fred should add a tag/value in "status" to
> give this indication. With that information, I could use another mechanism
> to "hide" the cover art (if there isn't any, or if nothing is currently
> queued), and then we'd never hit the problem that the new firmware in
> NetLinx panels is barfing on rendering spacer.gif.
>
> That's what caused Vincen to look into this issue to begin with (a firmware
> upgrade - that I don't have yet - appears to be unable to render spacer.gif
> properly).

ah ok. The server should be sending the correct CT in the header despite the url
being cover.jpg (its lagacy cruft on the name). If your firware upgrade
handles the spacer ok, you are fine with this?

-kdf

Jeff Coffler
2005-02-23, 14:38
Hi kdf,

> ah ok. The server should be sending the correct CT in the header despite
> the url
> being cover.jpg (its lagacy cruft on the name). If your firware upgrade
> handles the spacer ok, you are fine with this?

Vincen has been dealing with this on his own since I don't have a firmware
update for my model panel yet (and frankly, hearing what Vincen has been
dealing with, I'm hesitant to be first on the block with that ;-) ).

If our firmware upgrade handles spacer ok, I'm fine. But that's not
currently the case. Unfortunately, for reasons stated in the paragraph
above, I'm not certain what the problem is, other than "this used to work
and now it doesn't, and the firmware upgrade was the cause". Vincen was
playing with this, thus his prior messages to this list.

As I said, I have other ways of dealing with this - if the CLI was extended
to tell me if there was (or wasn't) cover art. I'm sure Fred will chime in
next time he's online. Or we can change how spacer.gif is encoded. Or
something.

-----

And while we're talking about HTML rendering, I'm having another problem on
my side:

For architectural reasons, I can't send very long paths to the touchpanels
for rendering. I'm limited to somewhere around 80-100 bytes or so, total (I
didn't figure out the exact count, but it's close to that). The problem is
that the filenames are based on how the music was scanned. For example, I
ran into problems trying to render:

http://slimserver.taltos.com:9000/music/file:///home/media/music/Elton%%20John/Captain%%20Fantastic%%20and%%20the%%20Brown%%20Dir t%%20Cowboy/Captain%%20Fantastic%%20and%%20the%%20Brown%%20Dir t%%20Cowboy.flac/cover.jpg

As you can see, that's a good amount above my 80-100 byte total.

We came up with a buncha possible methods to solve this:

a) Make the music paths really really short, or create a mirror directory
that pointed to the "real" stuff via soft links (that would work on Unix,
but not necessarily on Windows), and point SlimServer to that mirror
directory,

b) Point to an alternate WWW server that issued "redirects" to the real
music paths, and have the panel look at that WWW server,

c) Extend the SlimServer software to keep a cache of URLs.

-

(a) is problematic if you use iTunes (I don't, but Vincen pointed out that
tags don't work right with iTunes, so the tags are in part based on the
filenames), and totally breaks browsing by filename in any reasonable way,
particularly for very short, automatically generated links,

(b) is the method we're currently looking at, but if the touchpanels don't
reliably handle redirects (not clear yet), we're screwed,

(c) was deemed to be "not generally useful to the Slim community", although
I'm unsure of that. I was sort of thinking of something like this:

(c.1) file:///... would work as is, or
(c.2) The CLI would have an option to request a "cached" address, like:
cache:///<seq#> (cache:///1). If specified, then the full path would be
stored in a small hash (indexed by seq#), and that cache would be
automatically cleansed (to contain, say, the last 50 items or so -
duplicates okay). So, if I asked for a cached address, I might get a tag
(in 'status') like 'cache' with a value of 'cache:///532'.
(c.3) If the server got something like "music/cache:///532/cover.jpg", then
it would look up "532" as the key to a hash to get the "real" URL and then
respond normally. It would be nice if this was used in all cases (i.e.
allow the "cache:///532" to be used anywhere a URL is allowed), but I really
only care about cover art today. *I* can handle long paths, it's just the
panels that can't when rendering images.

If I worked with Fred on the CLI changes for (c), would that be acceptable
to you guys? Or do you agree that this isn't a very palatable feature for
the SlimServer software?

Thanks in advance, kdf (or others),

-- Jeff

kdf
2005-02-23, 15:19
Quoting Jeff Coffler <jeff-list-slimdev (AT) taltos (DOT) com>:

> Hi kdf,
>
> > ah ok. The server should be sending the correct CT in the header despite
> > the url
> > being cover.jpg (its lagacy cruft on the name). If your firware upgrade
> > handles the spacer ok, you are fine with this?
>
> Vincen has been dealing with this on his own since I don't have a firmware
> update for my model panel yet (and frankly, hearing what Vincen has been
> dealing with, I'm hesitant to be first on the block with that ;-) ).
>
> If our firmware upgrade handles spacer ok, I'm fine. But that's not
> currently the case. Unfortunately, for reasons stated in the paragraph
> above, I'm not certain what the problem is, other than "this used to work
> and now it doesn't, and the firmware upgrade was the cause". Vincen was
> playing with this, thus his prior messages to this list.
>
> As I said, I have other ways of dealing with this - if the CLI was extended
> to tell me if there was (or wasn't) cover art. I'm sure Fred will chime in
> next time he's online. Or we can change how spacer.gif is encoded. Or
> something.

My apologies for not be more. I seem to recal some metion of grabbing song
attributes, and album attributes through the CLI. If that is true, then cover
art should be part of those, at least for 6.0 stuff. I've mostly forgotten
5.4.x by now :)

> And while we're talking about HTML rendering, I'm having another problem on
> my side:
>
> For architectural reasons, I can't send very long paths to the touchpanels
> for rendering. I'm limited to somewhere around 80-100 bytes or so, total (I
> didn't figure out the exact count, but it's close to that). The problem is
> that the filenames are based on how the music was scanned. For example, I
> ran into problems trying to render:
>
>
http://slimserver.taltos.com:9000/music/file:///home/media/music/Elton%%20John/Captain%%20Fantastic%%20and%%20the%%20Brown%%20Dir t%%20Cowboy/Captain%%20Fantastic%%20and%%20the%%20Brown%%20Dir t%%20Cowboy.flac/cover.jpg
>
> As you can see, that's a good amount above my 80-100 byte total.
>
> We came up with a buncha possible methods to solve this:
>
> a) Make the music paths really really short, or create a mirror directory
> that pointed to the "real" stuff via soft links (that would work on Unix,
> but not necessarily on Windows), and point SlimServer to that mirror
> directory,

after trying to work with a multiple music paths patch, I've come to despise the
whole virtual/absolute conversion, so I'm going to hide from this one :)

Architecture really falls to Dean anyway, so he'll have to determine if c) is
something Slimserver can handle.

-kdf

Jeff Coffler
2005-02-23, 21:19
Dan, do you have comments on this (see end of message)?

Attached is the original message that made kdf say:

> Architecture really falls to Dean anyway, so he'll have to determine if c)
> is
> something Slimserver can handle.

Thanks in advance for your input,

-- Jeff

----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Wednesday, February 23, 2005 2:19 PM
Subject: Re: [Developers] GIF in a JPEG cover.jpg file !


> Quoting Jeff Coffler <jeff-list-slimdev (AT) taltos (DOT) com>:
>
>> Hi kdf,
>>
>> > ah ok. The server should be sending the correct CT in the header
>> > despite
>> > the url
>> > being cover.jpg (its lagacy cruft on the name). If your firware
>> > upgrade
>> > handles the spacer ok, you are fine with this?
>>
>> Vincen has been dealing with this on his own since I don't have a
>> firmware
>> update for my model panel yet (and frankly, hearing what Vincen has been
>> dealing with, I'm hesitant to be first on the block with that ;-) ).
>>
>> If our firmware upgrade handles spacer ok, I'm fine. But that's not
>> currently the case. Unfortunately, for reasons stated in the paragraph
>> above, I'm not certain what the problem is, other than "this used to work
>> and now it doesn't, and the firmware upgrade was the cause". Vincen was
>> playing with this, thus his prior messages to this list.
>>
>> As I said, I have other ways of dealing with this - if the CLI was
>> extended
>> to tell me if there was (or wasn't) cover art. I'm sure Fred will chime
>> in
>> next time he's online. Or we can change how spacer.gif is encoded. Or
>> something.
>
> My apologies for not be more. I seem to recal some metion of grabbing
> song
> attributes, and album attributes through the CLI. If that is true, then
> cover
> art should be part of those, at least for 6.0 stuff. I've mostly
> forgotten
> 5.4.x by now :)
>
>> And while we're talking about HTML rendering, I'm having another problem
>> on
>> my side:
>>
>> For architectural reasons, I can't send very long paths to the
>> touchpanels
>> for rendering. I'm limited to somewhere around 80-100 bytes or so, total
>> (I
>> didn't figure out the exact count, but it's close to that). The problem
>> is
>> that the filenames are based on how the music was scanned. For example,
>> I
>> ran into problems trying to render:
>>
>>
> http://slimserver.taltos.com:9000/music/file:///home/media/music/Elton%%20John/Captain%%20Fantastic%%20and%%20the%%20Brown%%20Dir t%%20Cowboy/Captain%%20Fantastic%%20and%%20the%%20Brown%%20Dir t%%20Cowboy.flac/cover.jpg
>>
>> As you can see, that's a good amount above my 80-100 byte total.
>>
>> We came up with a buncha possible methods to solve this:
>>
>> a) Make the music paths really really short, or create a mirror directory
>> that pointed to the "real" stuff via soft links (that would work on Unix,
>> but not necessarily on Windows), and point SlimServer to that mirror
>> directory,
>
> after trying to work with a multiple music paths patch, I've come to
> despise the
> whole virtual/absolute conversion, so I'm going to hide from this one :)
>
> Architecture really falls to Dean anyway, so he'll have to determine if c)
> is
> something Slimserver can handle.
>
> -kdf
>