Bug 10589 - Radio stations continue streaming even when not being played
: Radio stations continue streaming even when not being played
Status: RESOLVED WORKSFORME
Product: Logitech Media Server
Classification: Unclassified
Component: Streaming To SlimServer
: 7.3.1
: PC Other
: -- major (vote)
: Investigating
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-07 14:36 UTC by Mary Gardiner
Modified: 2009-01-12 09:08 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mary Gardiner 2009-01-07 14:36:34 UTC
Behaviour:

We listen to an Australian radio station on our Boom. (Specifically Triple J, which is an Australian radio station found under World -> Find a city -> Australiasia -> Australia -> ABC -> Stations -> Triple J Radio (Sydney, NSW)). If we stop (pause) the stream, the data continues to download indefinitely, confirmed by tcpdump. The radio station has to be removed from the playlist entirely to stop downloading data.

The stream is currently being proxied by Squeezecenter but this behaviour seems to persist if the player makes a direct connection too. It happens with radio stations and podcasts too.

Expected behaviour:

Australian broadband users have caps on their usage of between 1GB and about 40GB for the entire month. (Ours is 12GB.) Continuous streaming of a 128kbps file for 12 hours, as could happen easily if we forget that we not only have to turn off our alarm and stop the player but also go in and empty the playlist entirely, could be some hundreds of MB.

The expected behaviour is therefore that unless we are listening to a stream, it is not downloading. (I expect the publisher of the stream would rather like this too.)

If this behaviour is being implemented so that someone who briefly stops the playing can restart it without interruption related to a reconnection, for Australian users about 5 minutes of 'silent' streaming would be OK.
Comment 1 Mary Gardiner 2009-01-07 14:37:21 UTC
As a specific example of bandwidth usage, we seem to have consumed about 3/4 of a GB in a day doing this.
Comment 2 Andy Grundman 2009-01-07 15:04:22 UTC
You should really stop the station by holding pause.

But while paused, you're right, it should not continue downloading like that: once the player's buffer is full it should stop.  This is definitely how it works in direct streaming mode, I can't say for sure what happens in proxied mode.

Alan: thoughts?
Comment 3 Alan Young 2009-01-09 00:51:16 UTC
I cannot really see why proxy streaming should be different. I could imagine that there might be some odd circumstances in which the stream source disconnects in such a way that either the player or proxy streaming code reports an error to SC which causes it to restart the stream, but in this case the player would not remain paused.

Once paused, the player will continue to fill its buffer, and there may also be some network buffers with a little more data. I just tried the station mentioned (with proxy streaming) and I get just under 5 minutes of buffered data. After that, c. 100s later, the connection is closed by the stream source. I confirmed this by monitoring the network traffic.

Nonetheless, as Andy mentioned, the safe way to stop a stream is to press-and-hold Pause, rather than just pause it.

Set also bug 7320 and bug 10163.

Assigning to QA to see if they can reproduce this. Otherwise I would close this with WORKSFORME.
Comment 4 Mary Gardiner 2009-01-09 04:44:40 UTC
I haven't been able to reproduce yet with some careful tcpdump efforts, so I suspect my initial bug report was mistaken.

Thanks for the careful investigation on your end.