Bug#501860: mt-daapd: does not stream m4a (aac) files
Rogério Brito
Severity: normal
Hi, Julien.
I just installed the package mt-daapd on the powerpc NAS that I
mentioned to you in a private e-mail and everything is fine with MP3
files (I have not tested with FLAC files yet). [*]
Unfortunately, it seems that it is not streaming m4a files. With both
Amarok and Rhythmbox, it starts like it will start playing the song,
showing the metadata, but both players just sit there, stuck at 0:0
seconds (no matter if I am using the clients on Ubuntu or Debian).
I will try to see if it happens with iTunes on a Mac that I have and I
will report back what I see.
Have you seen this happen? Do you need further information?
Regards, Rogério Brito.
[*] Actually, with some VBR MP3 files, the song duration is enormously
wrong. I have one 20min song (Symphony X's "The Divine Wings of
Tragedy") that shows as 3min only.
-- System Information:
Debian Release: lenny/sid
APT prefers hardy-updates
APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rogério Brito
I just tested with a PowerPC Mac running iTunes 8 and the m4a files are
not played there either.
I guess that we could get a tcpdump of the communication to see what is
happening differently between m4a and mp3 files. :-(
Unfortunately, tomorrow I will be attending a conference on software
design methodologies and won't be able to test further.
Thanks, Rogério Brito.
Julien BLACHE
Hi,
> Unfortunately, it seems that it is not streaming m4a files. With both
AAC support has been broken upstream for more than a year.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Julien BLACHE
Hi,
> Unfortunately, it seems that it is not streaming m4a files. With both
> Amarok and Rhythmbox, it starts like it will start playing the song,
> showing the metadata, but both players just sit there, stuck at 0:0
> seconds (no matter if I am using the clients on Ubuntu or Debian).
Please get a log by running
mt-daapd -f -d 10
and send it to me.
I'm working on fixing a scanning bug on AAC files because I could not
even get my AAC files to show up in the playlist. I've identified the
bug and hope to have it fixed soon.
With a workaround I've been able to get my AAC files recognized and I
can play them just fine, if only with a little delay at the start.
All my AAC files are produced by FAAC, I have no Apple AAC files.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
Rogério Brito
On Oct 12 2008, Julien BLACHE wrote:
> > Unfortunately, it seems that it is not streaming m4a files. With both
> > Amarok and Rhythmbox, it starts like it will start playing the song,
> > showing the metadata, but both players just sit there, stuck at 0:0
> > seconds (no matter if I am using the clients on Ubuntu or Debian).
>
> Please get a log by running
>
> mt-daapd -f -d 10
>
> and send it to me.
Will do that right now (the debug level seems to go up to 9, according to
the help screen).
> I'm working on fixing a scanning bug on AAC files because I could not
> even get my AAC files to show up in the playlist. I've identified the
> bug and hope to have it fixed soon.
We just thought about this at the same time. I decided to go through the
scanninc code on AAC files and found some strange things like this:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(...)
* @returns offset of the atom, or -1 if unsuccessful
*/
uint64_t scan_aac_drilltoatom(IOHANDLE hfile,char *atom_path,
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Obviously, that function needs to return a int64_t (more correctly, it
would return a size_t, if I understood it correctly).
But I have have not yet found the bug (as I mentioned, yesterday I was on a
very long conference and I was simply "destroyed" after I came back home).
Your e-mail prompted me to chase it, though, since upstream doesn't seem to
be that active.
> With a workaround I've been able to get my AAC files recognized and I
> can play them just fine, if only with a little delay at the start.
>
> All my AAC files are produced by FAAC, I have no Apple AAC files.
I used to have a mix of them here. The Apple AAC ones were not produced by
me :), while the others that I produced were with FAAC.
But as I am upstream for lame and seeing how it generates very good quality
VBR MP3 files, I just reencoded the files to MP3. I had not noticed that
FAAC files weren't being recognized.
BTW, my AAC files are tagged with easytag(-aac), taken from Marillat's
repository (why can't we have easytag in Debian with aac support?). It's
just tagging, for $DEITY's sake!
Anyway, sorry for the long story, but there is few people here that
understand the situation and to whom I could vent my frustrations.
Regards, Rogério Brito.
P.S.: Care to share your workaround here? I want to test it.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
Julien BLACHE
Hi,
>> Please get a log by running
>>
>> mt-daapd -f -d 10
>>
>> and send it to me.
>
> Will do that right now (the debug level seems to go up to 9, according to
> the help screen).
Nope, 10 is the max, trust me :)
> We just thought about this at the same time. I decided to go through the
> scanninc code on AAC files and found some strange things like this:
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> (...)
> * @returns offset of the atom, or -1 if unsuccessful
> */
> uint64_t scan_aac_drilltoatom(IOHANDLE hfile,char *atom_path,
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Yeah, I took care of that first, and then I uncovered the real bug.
> Obviously, that function needs to return a int64_t (more correctly, it
> would return a size_t, if I understood it correctly).
Yes that should be a size_t, except that there's an abstraction layer,
so it's a uint64_t.
> But as I am upstream for lame and seeing how it generates very good quality
> VBR MP3 files, I just reencoded the files to MP3. I had not noticed that
> FAAC files weren't being recognized.
MP3 sucks, no matter how good the encoder is. AAC is somewhat better,
but it still sucks compared to CD.
> BTW, my AAC files are tagged with easytag(-aac), taken from Marillat's
> repository (why can't we have easytag in Debian with aac support?). It's
> just tagging, for $DEITY's sake!
Needs libmp4v2, which we cannot have in Debian due to patent issues
around MPEG4.
> P.S.: Care to share your workaround here? I want to test it.
If you could clarify your situation first, I'm a bit confused now. Do
you have your files in the playlist or not? Do they play or not?
JB.
--
Julien BLACHE <jbl...@debian.org> | Debian, because code matters more
Debian & GNU/Linux Developer | <http://www.debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
Rogério Brito
> > Will do that right now (the debug level seems to go up to 9,
> > according to the help screen).
>
> Nope, 10 is the max, trust me :)
Ooops. I didn't read the code. :-) That should be fixed, though.
> > We just thought about this at the same time. I decided to go through the
> > scanninc code on AAC files and found some strange things like this:
> > (...)
>
> Yeah, I took care of that first, and then I uncovered the real bug.
Nice.
> > Obviously, that function needs to return a int64_t (more correctly, it
> > would return a size_t, if I understood it correctly).
>
> Yes that should be a size_t, except that there's an abstraction layer,
> so it's a uint64_t.
Sorry. I'm a bit lost here. Did you intend to say int64_t? I think that
the abstraction layer may be changed a little bit, so that we do the
right thing (returning -1 when the function says that it will return an
unsigned int is not a good signal).
The code inside the function and the documentation should be trusted here.
> > But as I am upstream for lame and seeing how it generates very good
> > quality VBR MP3 files, I just reencoded the files to MP3. I had not
> > noticed that FAAC files weren't being recognized.
>
> MP3 sucks, no matter how good the encoder is. AAC is somewhat better,
> but it still sucks compared to CD.
I have no golden ears. :-) And I feel a bit uneasy with the lack of faac
development, especially in the psycho-acoustic part.
> > BTW, my AAC files are tagged with easytag(-aac), taken from
> > Marillat's repository (why can't we have easytag in Debian with aac
> > support?). It's just tagging, for $DEITY's sake!
>
> Needs libmp4v2, which we cannot have in Debian due to patent issues
> around MPEG4.
Perhaps we can grab some files from libmp4v2 for the sake of compiling
easytag with aac support... (Just a wild thought, knowing nothing about
the complexity of this task).
> > P.S.: Care to share your workaround here? I want to test it.
>
> If you could clarify your situation first, I'm a bit confused now. Do
> you have your files in the playlist or not? Do they play or not?
1 - The AAC files here were generated by iTunes;
2 - They show up in the playlist;
3 - The don't play.
Hope this helps to clear the situation.
Regards, Rogério Brito.
Julien BLACHE
Hi,
>> Nope, 10 is the max, trust me :)
>
> Ooops. I didn't read the code. :-) That should be fixed, though.
9 is the last useful level for users. 10 is advanced debug stuff.
>> > Obviously, that function needs to return a int64_t (more correctly, it
>> > would return a size_t, if I understood it correctly).
>>
>> Yes that should be a size_t, except that there's an abstraction layer,
>> so it's a uint64_t.
>
> Sorry. I'm a bit lost here. Did you intend to say int64_t? I think that
> the abstraction layer may be changed a little bit, so that we do the
No, I meant uint64_t to match the size_t through the abstraction
layer. I was essentially telling that the code was correct in using an
unsigned type for the offset, not taking into account the fact that
the return value of the function should only indicate success/failure.
> right thing (returning -1 when the function says that it will return an
> unsigned int is not a good signal).
You'll not there was a FIXME in the file about that :) But still, that
code was horribly broken.
> I have no golden ears. :-) And I feel a bit uneasy with the lack of faac
> development, especially in the psycho-acoustic part.
They've been shut down due to patent threats, if memory serves me well.
>> Needs libmp4v2, which we cannot have in Debian due to patent issues
>> around MPEG4.
>
> Perhaps we can grab some files from libmp4v2 for the sake of compiling
> easytag with aac support... (Just a wild thought, knowing nothing about
> the complexity of this task).
Read-only support might be OK, write support probably not. I don't
know if anyone tried to get it in Debian, a quick search did not turn
anything up. Might be worth investing a bit of time into that.
> 1 - The AAC files here were generated by iTunes;
> 2 - They show up in the playlist;
> 3 - The don't play.
>
> Hope this helps to clear the situation.
OK, so the fix for the scanner won't help you here. (though you can
test the fix with iTunes files which would be a good thing)
I'd need a log snippet when you're trying to read an AAC file. The log
you sent only contains the startup :)
Rogério Brito
On Oct 12 2008, Julien BLACHE wrote:
> Rogério Brito <rbr...@ime.usp.br> wrote:
> > Ooops. I didn't read the code. :-) That should be fixed, though.
>
> 9 is the last useful level for users. 10 is advanced debug stuff.
Perhaps it should be documented. The documentation shouldn't assume that
all users are extremely dumb. This is a Microsoft-esque thing.
> > Sorry. I'm a bit lost here. Did you intend to say int64_t? I think
> > that the abstraction layer may be changed a little bit, so that we
> > do the
>
> No, I meant uint64_t to match the size_t through the abstraction
> layer. I was essentially telling that the code was correct in using an
> unsigned type for the offset, not taking into account the fact that
> the return value of the function should only indicate success/failure.
Oh, right.
> > right thing (returning -1 when the function says that it will return an
> > unsigned int is not a good signal).
>
> You'll not there was a FIXME in the file about that :) But still, that
> code was horribly broken.
Perhaps we can refactor it a little bit.
> > I have no golden ears. :-) And I feel a bit uneasy with the lack of
> > faac development, especially in the psycho-acoustic part.
>
> They've been shut down due to patent threats, if memory serves me
> well.
Those blasted patents. :-/
> > Perhaps we can grab some files from libmp4v2 for the sake of compiling
> > easytag with aac support... (Just a wild thought, knowing nothing about
> > the complexity of this task).
>
> Read-only support might be OK, write support probably not. I don't
> know if anyone tried to get it in Debian, a quick search did not turn
> anything up. Might be worth investing a bit of time into that.
I will perhaps try asking debian-legal if writing just a *tag* would be
acceptable or not.
> > 1 - The AAC files here were generated by iTunes;
> > 2 - They show up in the playlist;
> > 3 - The don't play.
> >
> > Hope this helps to clear the situation.
>
> OK, so the fix for the scanner won't help you here. (though you can
> test the fix with iTunes files which would be a good thing)
Yes, I want to test with those files. Unfortunately, I don't have the
WAVs for them, if you know what I mean. :-)
> I'd need a log snippet when you're trying to read an AAC file. The log
> you sent only contains the startup :)
Ok, sending it again. This time trying to play an iTunes generated AAC
file.
Regards, Rogério Brito.
P.S.: Did you get the manpage that I wrote for mt-daapd? I'm not sure if
all my mails are getting through. :-(
Julien BLACHE
Hi,
>> 9 is the last useful level for users. 10 is advanced debug stuff.
>
> Perhaps it should be documented. The documentation shouldn't assume that
> all users are extremely dumb. This is a Microsoft-esque thing.
I'd rather have people send a log at level 9 before they send one at
level 10. 10 is very verbose (the level is called L_SPAM ...) and
makes very large logs that are difficult to read.
>> You'll not there was a FIXME in the file about that :) But still, that
>> code was horribly broken.
>
> Perhaps we can refactor it a little bit.
Done already, as I wrote in the previous mail :)
>> Read-only support might be OK, write support probably not. I don't
>> know if anyone tried to get it in Debian, a quick search did not turn
>> anything up. Might be worth investing a bit of time into that.
>
> I will perhaps try asking debian-legal if writing just a *tag* would be
> acceptable or not.
You should check what libmp4v does for real and see what can be done
from here. I haven't looked into it in details, just using a local
build for gtkpod for my iPod.
>> I'd need a log snippet when you're trying to read an AAC file. The log
>> you sent only contains the startup :)
>
> Ok, sending it again. This time trying to play an iTunes generated AAC
> file.
OK, so the log tells that it's working fine. The file is being
streamed to the client just fine, with a content-type of audio/m4a
Emitting reponse header Content-Type: audio/m4a
I'm afraid you have a player FAIL here, and not a server FAIL ;)
If you can send make the file available somewhere, I'd try playing it
on my SoundBridge. It's playing my m4a files just fine.
> P.S.: Did you get the manpage that I wrote for mt-daapd? I'm not sure if
> all my mails are getting through. :-(
Yep. I'll rework it somewhat and include it in an upload later today,
together with the AAC scanning patch, so you can try that out and tell
me how it goes. (mt-daapd -f -d 9 -D scan for that purpose, if
scanning fails on one or more files, do it again with -d 10 and send
me the log snippet for that particular file)
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Rogério Brito
On 13/10/2008, at 07:30, Julien BLACHE wrote:
> Rogério Brito <rbr...@ime.usp.br> wrote:
>
>> Perhaps it should be documented. The documentation shouldn't
>> assume that
>> all users are extremely dumb. This is a Microsoft-esque thing.
>
> I'd rather have people send a log at level 9 before they send one at
> level 10. 10 is very verbose (the level is called L_SPAM ...) and
> makes very large logs that are difficult to read.
Yes, I read that in the code. :-) Funny thing.
>> Perhaps we can refactor it a little bit.
>
> Done already, as I wrote in the previous mail :)
Nice. :-)
>> I will perhaps try asking debian-legal if writing just a *tag*
>> would be
>> acceptable or not.
>
> You should check what libmp4v does for real and see what can be done
> from here. I haven't looked into it in details, just using a local
> build for gtkpod for my iPod.
Perhaps I didn't expressed myself clearly. I was thinking of
including just the needed files from libmp4v2 to easytag's diff.gz
(as a patch). It seems to me (IIRC), that there's one header that
needs to be included, but the core of the functionality is already
enabled in easytag.
>>> I'd need a log snippet when you're trying to read an AAC file.
>>> The log
>>> you sent only contains the startup :)
>>
>> Ok, sending it again. This time trying to play an iTunes generated
>> AAC
>> file.
>
> OK, so the log tells that it's working fine. The file is being
> streamed to the client just fine, with a content-type of audio/m4a
>
> Emitting reponse header Content-Type: audio/m4a
>
> I'm afraid you have a player FAIL here, and not a server FAIL ;)
No, I read the log before I sent it to you and the behaviour that I
see is that mt-daapd sends the *whole* file at once, *before* the
player even plays a second of it.
Tested with rhythmbox (with gstreamer back-end), with amarok (with
xine back-end), and with iTunes proper. Neither of these worked.
> If you can send make the file available somewhere, I'd try playing it
> on my SoundBridge. It's playing my m4a files just fine.
Right. We can talk about this in private in e-mail.
>> P.S.: Did you get the manpage that I wrote for mt-daapd? I'm not
>> sure if
>> all my mails are getting through. :-(
>
> Yep. I'll rework it somewhat
Does it need any major surgery? :-) At least it is a good start, I
think. :-)
> and include it in an upload later today,
> together with the AAC scanning patch, so you can try that out and tell
> me how it goes.
Quite nice.
> (mt-daapd -f -d 9 -D scan for that purpose, if
> scanning fails on one or more files, do it again with -d 10 and send
> me the log snippet for that particular file)
OK with me. (Even though I don't seem to think that the problem is
scanning, or doesn't seem to be, based on the fact that the files are
all sent immediately to the client).
Regards, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Julien BLACHE
Hi,
> Perhaps I didn't expressed myself clearly. I was thinking of including
> just the needed files from libmp4v2 to easytag's diff.gz (as a
> patch). It seems to me (IIRC), that there's one header that needs to
> be included, but the core of the functionality is already enabled in
> easytag.
Might be OK.
>> I'm afraid you have a player FAIL here, and not a server FAIL ;)
>
> No, I read the log before I sent it to you and the behaviour that I
> see is that mt-daapd sends the *whole* file at once, *before* the
> player even plays a second of it.
Did you see it in realtime ? Because what I am seeing is mt-daapd
streaming the file in 4k blocks.
> OK with me. (Even though I don't seem to think that the problem is
> scanning, or doesn't seem to be, based on the fact that the files are
> all sent immediately to the client).
I know scanning is OK with your files, the test is to make sure the
patch doesn't break scanning for you (and others).
It's in incoming already, built for powerpc but the buildd hasn't
uploaded yet.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
Rogério Brito
On 13/10/2008, at 18:25, Julien BLACHE wrote:
>>> I'm afraid you have a player FAIL here, and not a server FAIL ;)
>>
>> No, I read the log before I sent it to you and the behaviour that I
>> see is that mt-daapd sends the *whole* file at once, *before* the
>> player even plays a second of it.
>
> Did you see it in realtime ? Because what I am seeing is mt-daapd
> streaming the file in 4k blocks.
No, *all* the log lines were generated at once. No pause between
them. The client didn't ask for them yet, but mt-daapd just crammed
them down the clients. The 4k chunks were definitely just spit out on
the log as fast as the log could be written.
When the player was going to play, it had no data and just sit there,
waiting for the server to suply something.
>> OK with me. (Even though I don't seem to think that the problem is
>> scanning, or doesn't seem to be, based on the fact that the files are
>> all sent immediately to the client).
>
> I know scanning is OK with your files, the test is to make sure the
> patch doesn't break scanning for you (and others).
Ok, I can test it. Not breaking is a good start. :-) I will also test
with some files generated by faac.
> It's in incoming already, built for powerpc but the buildd hasn't
> uploaded yet.
Unfortunately, I missed it: the dinstall occured before I could grab
the sources and see for myself. :-( And the mirror that I checked
didn't have your new version. :-/
Thanks, Rogério.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Julien BLACHE
thanks
Rogério Brito <rbr...@ime.usp.br> wrote:
Hi,
> Unfortunately, it seems that it is not streaming m4a files. With both
> Amarok and Rhythmbox, it starts like it will start playing the song,
> showing the metadata, but both players just sit there, stuck at 0:0
> seconds (no matter if I am using the clients on Ubuntu or Debian).
OK, this is the story with this bug.
AAC files must be optimized for "fast-start streaming". Those files
have the metadata at the start of the file, rather than at the end.
Recent iTunes version produce such files, pretty much all other
encoders don't (FAAC doesn't).
What you can do is grab the mpeg4ip suit and run
mp4creator -optimize foo.m4a
on your files. They'll play fine after that.
The better part is, there's not one player that will tell you there's
a problem with your file/stream, but they all tear down the connection
after a couple of blocks if they haven't found the meta-data.
So, in essence, not an mt-daapd bug.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
Rogério Brito
On Oct 15 2008, Julien BLACHE wrote:
> What you can do is grab the mpeg4ip suit and run
>
> mp4creator -optimize foo.m4a
>
> on your files. They'll play fine after that.
The files work fine after that workaround (with the latest version of
mt-daapd installed). Thanks for that.
> The better part is, there's not one player that will tell you there's
> a problem with your file/stream, but they all tear down the connection
> after a couple of blocks if they haven't found the meta-data.
Oh, I see. Thanks for the clear explanation and the solution to the
problem. Also, the files are slightly smaller after being processed with
mp4creator.
Thanks, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
Julien BLACHE
Hi,
>> The better part is, there's not one player that will tell you there's
>> a problem with your file/stream, but they all tear down the connection
>> after a couple of blocks if they haven't found the meta-data.
>
> Oh, I see. Thanks for the clear explanation and the solution to the
> problem. Also, the files are slightly smaller after being processed with
> mp4creator.
You're welcome. I suggest you file bugs on Amarok and Rhythmbox as
they fail to give any useful feedback to the user when that happens.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--