AlienBBC spurious stream restart

[bpa]

This a branch from the Garbled Audio thread in General as a spearate problem seem to have been discovered.

Twice yesterday and once today while testing AlienBBC with SoftSqueeze on a Linux box and Slimserver 6.1.2 on Windows, the R4 stream restarted by itself. "Hangtight" had a similar experience but not definite.

I had ethereal running for last 2 events. The problem is a result of Slimserver sending a TCP packet with FIN set from port 9000. This results in a RST on the Mplayer connection to the BBC and then Mplayer restarts with a new connections.

The time between first packet on port 9000 and first Fin packet was 12197 and 12183 seconds. A difference of only 14 seconds in 12,000 on two separate days with a different number of lost packets - that is too small a difference to be a coincidence. Any timers of about 200-203 mins/ 12000-12100 secs in slimserver ? I think the tets problem is reproducible but it take 3.5 hrs to run - any suggestion (e.g. a debug flag to set) for next run ?

DEBUGPIPE on second run did not show "Stalled" just "kill movedata thread" so socketwrapper is not the culprit.

[Triode]

Bryan,

try --d_source and --d_http

assuming you are using a recent server the http one should be less noisy.

Adrian

[bpa]

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 mplayer. Error 10054 is ECONNRESET - connection has been reset. Line 1977 refers to the following line of code in source.pm. The server build is a nightly of 6.1.2.

		$::d_source && msg("end of file or error on socket, opening next song, (song pos: " .
				$client->songBytes() . "(tell says: . " . systell($client->audioFilehandle()).
				"), totalbytes: " . $song->{totalbytes} . ")\n");

Any ideas - this problem is a bit of a curio but it means I can't be sure of test of Mplayer.

Edit : Mon 12:30 - I reran the test with last night 6.2.1 build - same problem restart after 3:22:53. I have turned on the d_http, d_http_v and d_http_async flags. I'll look at the log later today.

I've looked at the log - nothing significant so I've put in a backtrace call in closeHTTPclient and am rerunning the test

[bpa]

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 using Flac - at 3hr 22 output to Softsqueeze stops and elapsed time freezes. Mplayer is still running and there is network traffic presumably from BBC as there was no other activity. When output in MP3 the stream restarts.

Everything is pointing at Slimserver. The Ethereal trace of Windows & Linux tests showed comms with Softsqueeze stopped after FIN closing the TCP connection to BBC from slimserver.

Besides the closesong where else could a stream from Mplayer/Lame be closed ? I put in a debug message in closesong and it was called after the "Readlen undef" message.

Any ideas on what to try next ? Shall I log it as a bug ?
It is annoying as I am debugging Mplayer and this behaviour means I can't do long tests.

[Triode]

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 make 3 hours 23 mins = 12180 seconds
For a PCM 44.1 stream this is 2148552000 bytes
Which very close to 2^31 ?

But if this is the problem, it is related to a stream at 44.1 rate, i.e. not slimserver if you are sending as flac as in this case slimserver only sees the flac rate...

Adrian

[bpa]

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 also looks very round.

I'll do another runs with wav later today - at the moment I have one going with a backtrace in close routine in Pipeline.pm.

[Triode]

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_length=le2me_32(0x7ffff000);

Where le2me_32 does byte swapping for big endian.

So assuming I have this right the wav header tells the next process in the pipeline that it is 3 hours 22 minutes 54 sec long...

[bpa]

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.

[Triode]

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 and add some extra params for flac and lame - I'll look at this.

[bpa]

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.