Fuppes 0.5.4 seems to work with the SLA5500, but there are several problems:
fuppes crashes on my x86_64 system:
#0 0x00002b057c65447b in raise () from /lib/libc.so.6
#1 0x00002b057c655da0 in abort () from /lib/libc.so.6
#2 0x00002b057c253974 in __gnu_cxx::__verbose_terminate_handler ()
from /usr/lib/libstdc++.so.6
#3 0x00002b057c251af6 in std::set_unexpected () from /usr/lib/libstdc++.so.6
#4 0x00002b057c251b23 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0x00002b057c251c0a in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x00002b057c1eede7 in std::__throw_out_of_range ()
from /usr/lib/libstdc++.so.6
#7 0x000000000040ae6b in CMessageBase::SetMessage (this=0x5bf6b0,
p_sMessage=<value optimized out>)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:306
#8 0x0000000000419dae in CHTTPMessage::SetMessage (this=0x5bf6b0,
nMsgType=HTTP_MESSAGE_TYPE_200_OK, p_sContentType=@0x43805aa0)
at HTTP/HTTPMessage.cpp:129
#9 0x0000000000473544 in CFuppes::HandleHTTPRequest (this=0x5bc840,
pMessageIn=0x5bf3d0, pMessageOut=0x5bf6b0) at Fuppes.cpp:321
#10 0x000000000047763c in CFuppes::OnHTTPServerReceiveMsg (this=0x13be,
pMessageIn=0x13c9, pMessageOut=0x6) at Fuppes.cpp:292
#11 0x000000000041e858 in CHTTPServer::CallOnReceive (
this=<value optimized out>, pMessageIn=0x5bf3d0, pMessageOut=0x5bf6b0)
at HTTP/HTTPServer.cpp:183
---Type <return> to continue, or q <return> to quit---
#12 0x0000000000422765 in SessionLoop (arg=0x5befd0) at HTTP/HTTPServer.cpp:303
#13 0x00002b057bbbf3ca in start_thread () from /lib/libpthread.so.0
#14 0x00002b057c6f155d in clone () from /lib/libc.so.6
#15 0x0000000000000000 in ?? ()
When I configure it should listen on my eth0 (default it picks localhost).
commenting line 129 in HTTP/HTTPMessage.cpp (CMessageBase::SetMessage()) seems to fix this.
Another problem I have is that (when transcoding, haven't listen withouth transcoding) is that the music is sounds "garbled" from time to time.. like it plays a little part ALOT to fast.
beside that it seems to work perfect...
Thanks for your nice work.
Qball
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to work fine on debian x86 (not 64bit)
but I have another problem, music that is transcoded has a noise floor in it (files that are already in mp3 sound fine). This noise floor is so big that it makes it unusable.
(it's converted from flac to mp3)
lame : (version: 3.97)
I've tried playing with the BITRATE setting (in TranscodingCache.cpp) lowering it (possible the device doesn't work with 320kbit mp3's)
Is this is a known problem? if so how can I solve this? if not where do I have to start looking?
thx
Qball
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I've found the reason for the crash on 64 bit machines. The problem is the comparison of an 32 bit unsigned int with string::npos wich is a 64 bit unsigned int on 64 bit machines. The comparison returns true for an empty string though it should return false. The following substr() raises an unhandled out of range exception and fuppes crashes.
Can you please change the type of nPos (MessageBase.cpp, Line: 65) from "unsigned int" to "std::string::size_type" and check if it works?!
Nevertheless line 129 in HTTP/HTTPMessage.cpp is unnecessary.
Big thanks for reporting this one. As I don't have a 64 bit machine I would never had found this.
Sorry, the transcoding problem is not known. Have you tried it with ogg and/or mpc? I just have two flac encoded albums and no problems with those. Maybe you cen send me a flac that does not work for you.
mail AT ulrich-voelkel DOT de
Big thanks.
uli
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tested it, ogg indeed doesn't seem to have the noise floor. So the problem is flac related.
(btw, I am running it on 32bit linux for the moment)
I will glare over the flac code, to see if I can spot the problem.
(I have flac @ quality 8, 16bit 44.1khz)
thx,
Qball
p.s. Is it possible to make the bitrate that lame uses configurable? it is running on a relatively low end machine (dual 466mhz Celeron), and 160kbit is for my purpose sufficient and 320+prebuffering on the philips makes skipping slow(er)
p.s.2 Do you have a cvs/svn server?
p.s.3 Can you include id3 tags in the output? (I think lame has a problem doing this "streaming)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got your flac patch. Will test it later that evening. Thanks!
1. Making lame settings configurable is planned
2. Yes. svn runs on http://fuppes.ulrich-voelkel.de. Anonymous access is not available at the moment but I can enable it if needed.
3. I'm not sure if lame can write ID3 tags before encoding is finished. I will have a look at that.
But UPnP has space for further information like album, genre, etc. I read out the tags via taglib and extend the UPnP description. Not sure if it fixes the problem for your device. e.g. the Noxon ignores the additional information. I'm currently implementing this feature so the next release should have it.
Thanks,
uli
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Fuppes 0.5.4 seems to work with the SLA5500, but there are several problems:
fuppes crashes on my x86_64 system:
#0 0x00002b057c65447b in raise () from /lib/libc.so.6
#1 0x00002b057c655da0 in abort () from /lib/libc.so.6
#2 0x00002b057c253974 in __gnu_cxx::__verbose_terminate_handler ()
from /usr/lib/libstdc++.so.6
#3 0x00002b057c251af6 in std::set_unexpected () from /usr/lib/libstdc++.so.6
#4 0x00002b057c251b23 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0x00002b057c251c0a in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x00002b057c1eede7 in std::__throw_out_of_range ()
from /usr/lib/libstdc++.so.6
#7 0x000000000040ae6b in CMessageBase::SetMessage (this=0x5bf6b0,
p_sMessage=<value optimized out>)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:306
#8 0x0000000000419dae in CHTTPMessage::SetMessage (this=0x5bf6b0,
nMsgType=HTTP_MESSAGE_TYPE_200_OK, p_sContentType=@0x43805aa0)
at HTTP/HTTPMessage.cpp:129
#9 0x0000000000473544 in CFuppes::HandleHTTPRequest (this=0x5bc840,
pMessageIn=0x5bf3d0, pMessageOut=0x5bf6b0) at Fuppes.cpp:321
#10 0x000000000047763c in CFuppes::OnHTTPServerReceiveMsg (this=0x13be,
pMessageIn=0x13c9, pMessageOut=0x6) at Fuppes.cpp:292
#11 0x000000000041e858 in CHTTPServer::CallOnReceive (
this=<value optimized out>, pMessageIn=0x5bf3d0, pMessageOut=0x5bf6b0)
at HTTP/HTTPServer.cpp:183
---Type <return> to continue, or q <return> to quit---
#12 0x0000000000422765 in SessionLoop (arg=0x5befd0) at HTTP/HTTPServer.cpp:303
#13 0x00002b057bbbf3ca in start_thread () from /lib/libpthread.so.0
#14 0x00002b057c6f155d in clone () from /lib/libc.so.6
#15 0x0000000000000000 in ?? ()
When I configure it should listen on my eth0 (default it picks localhost).
commenting line 129 in HTTP/HTTPMessage.cpp (CMessageBase::SetMessage()) seems to fix this.
Another problem I have is that (when transcoding, haven't listen withouth transcoding) is that the music is sounds "garbled" from time to time.. like it plays a little part ALOT to fast.
beside that it seems to work perfect...
Thanks for your nice work.
Qball
It seems to work fine on debian x86 (not 64bit)
but I have another problem, music that is transcoded has a noise floor in it (files that are already in mp3 sound fine). This noise floor is so big that it makes it unusable.
(it's converted from flac to mp3)
lame : (version: 3.97)
I've tried playing with the BITRATE setting (in TranscodingCache.cpp) lowering it (possible the device doesn't work with 320kbit mp3's)
Is this is a known problem? if so how can I solve this? if not where do I have to start looking?
thx
Qball
Hi Qball!
I think I've found the reason for the crash on 64 bit machines. The problem is the comparison of an 32 bit unsigned int with string::npos wich is a 64 bit unsigned int on 64 bit machines. The comparison returns true for an empty string though it should return false. The following substr() raises an unhandled out of range exception and fuppes crashes.
Can you please change the type of nPos (MessageBase.cpp, Line: 65) from "unsigned int" to "std::string::size_type" and check if it works?!
Nevertheless line 129 in HTTP/HTTPMessage.cpp is unnecessary.
Big thanks for reporting this one. As I don't have a 64 bit machine I would never had found this.
Sorry, the transcoding problem is not known. Have you tried it with ogg and/or mpc? I just have two flac encoded albums and no problems with those. Maybe you cen send me a flac that does not work for you.
mail AT ulrich-voelkel DOT de
Big thanks.
uli
I've tested it, ogg indeed doesn't seem to have the noise floor. So the problem is flac related.
(btw, I am running it on 32bit linux for the moment)
I will glare over the flac code, to see if I can spot the problem.
(I have flac @ quality 8, 16bit 44.1khz)
thx,
Qball
p.s. Is it possible to make the bitrate that lame uses configurable? it is running on a relatively low end machine (dual 466mhz Celeron), and 160kbit is for my purpose sufficient and 320+prebuffering on the philips makes skipping slow(er)
p.s.2 Do you have a cvs/svn server?
p.s.3 Can you include id3 tags in the output? (I think lame has a problem doing this "streaming)
Got your flac patch. Will test it later that evening. Thanks!
1. Making lame settings configurable is planned
2. Yes. svn runs on http://fuppes.ulrich-voelkel.de. Anonymous access is not available at the moment but I can enable it if needed.
3. I'm not sure if lame can write ID3 tags before encoding is finished. I will have a look at that.
But UPnP has space for further information like album, genre, etc. I read out the tags via taglib and extend the UPnP description. Not sure if it fixes the problem for your device. e.g. the Noxon ignores the additional information. I'm currently implementing this feature so the next release should have it.
Thanks,
uli