I don't think I copied the commands correctly the first time as it seems
to work correctly now for both FLAC and LAME on Windows. Do you think
the Mac will be different?
Neil
--
Neil Sleightholm
Neil Sleightholm's Profile
I hope a mac is the same, but it is worth a mac user testing. The only
reason for being unsure is that I think the hardware of one is little
endian and the other big endian, so it may need the -x and --endian
definitions changing..
--
Triode
Neil,
You may need to play with more of the options for flac and lame on
windows [perhaps the defaults are different]
With the wave header, lame and flac pick up all details about the
stream from the wave header. Without it, we need to specify all the
paramters necessary to treat the stream as
If I try nowaveheader on Windows it doesn't seem to work at all. Does
anyone else see this?
Neil
--
Neil Sleightholm
Neil Sleightholm's Profile: http://forums.slimdevices.com/member.php?userid=131
View this thread: http:/
Seems to work for me (on FLAC). I don't have Lame installed so can't
test MP3.
Ubuntu/svn5029/SB2
Good work BTW, I've never had a live stream running for 3hrs 20mins ;-)
--
Patrick Dixon
www.at-view.co.uk
___
plugins mailing list
plugins@lists.sli
OK for unix users, do these alternative convert commands work for
people? They avoid the waveheader being passed to lame/flac and hence
the 3 hour 22 minute problem...
Code:
rtsp mp3 * *
[mplayer.sh] -really-quiet -vc dummy -vo null -cache 128 -af
volume=0,r
I'm at 3hr 37 when using WAV - your header theory looks right.
I think this problem was never noticed because there were few BBC
programs longer than 3hrs except live broadcasting.
Thanks Adrian - now to write up the latest Mplayer patch.
--
bpa
__
Assuming using wav removes the 3 hours 22 minutes problem, we probably
want to change the slimserver-convert.conf commands for flac and mp3.
At present they use the waveheader to get stuff like bitrate to lame
and flac to avoid configuring them, but it should be possible to avoid
the wave header
OK - I'll try that - especially as you had some input into patching that
file already.
I think I may have found the last garbled audio bug as well - so this
could be a good day where I can put Mplayer away.
--
bpa
___
plugins mailing list
plugins@li
Bryan,
Definately try streaming with wav - the convert commands actually mean
that mplayer does not add a wav header in this case. [But flac and mp3
do to get the info into flac or lame]
Looking at the mplayer source, I think libao2/ao_pcm.c generates a wav
header with:
wavhdr.data_leng
I have used flac and Lame under linux. When flac was used Softsqueeze
elasped time display froze and stream did not restart.
I have gone through different permutations of the 3hr 23 because I
think it is a timer or wrap around as well. The 44.1Khz is interesting.
It is also 203 minutes which a
Bryan,
Are you using flac or lame? [post suggests both? Could I suggest
streaming as wav to remove the extra process from the pipeline]
To remove flac, have you tried streaming as wav to softsqueeze.
[unselect rstp->flc *and* wav->flac from file types]
Sounds like something is wrapping?
I
This problem is consistent but so tedious as it takes 3hr 22 mins to
happen.
On Windows the stream restarts regardless whether Softsqueeze (2.0b1)
is on the same Windows PC or another (linux ) box. Output was in MP3.
On a Linux (Suse 9.3) box Slimserver 6.2.1, Alien 0.99 output to
Softsqueeze u
This problem is reproducible. I made it happen twice more today. It is
definitely time related - on Softsqueeze it said 3:22:54 just before
it reset to zero. I made a log of -d_source -d_http and an ethereal
log as well.
I've attached a fragment of the log just when it stops and restarts
mplay
Bryan,
try --d_source and --d_http
assuming you are using a recent server the http one should be less
noisy.
Adrian
--
Triode
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/plugins
15 matches
Mail list logo
