Android client keeps stopping despite enough bandwidth.

[zapt0]

Hello! I have tried using the Android client for Subsonic 4.4. Despite having enough bandwidth songs keep skipping. I am currently transcoding to 128Kb and it keeps skipping despite me having double that in bandwidth.

I am fairly confident this is due to overly pessimistic buffering algorithms. For example, many songs stop after 2-3 seconds to display "Buffering 600KB" which in 128Kb is over 30 seconds into the song and should never stop playback when there is data left in the buffer.

Edit: I have also noted that FLAC songs, albeit transcoded still take forever to buffer. It basically does not even allow me to play 60 seconds of the song without forcing me to buffer it completely. This makes absolutely no sense since the song received is mp3, not flac.

Something interesting I noticed is that LAME only takes up about 10-20% CPU, is this by design? I have tried multiple LAME versions but always same result.

I am displaying below the bandwidth graph that causes skipping:


In the log I see:

Code: Select all

[4/26/11 10:53:16 PM CEST]    INFO   PlaylistInputStream   admin listening to "A-Teens - Pop Til You Drop\A-Teens - 05 - Hi And Goodbye.mp3"
[4/26/11 10:53:16 PM CEST]    DEBUG   TranscodeInputStream   Starting transcoder: [c:\subsonic\transcode\lame] [-S] [-h] [--resample] [44.1] [-b] [128] [--tt] [Hi And Goodbye] [--ta] [A-Teens] [--tl] [Pop 'Til You Drop!] [C:\Musik\A-Teens - Pop Til You Drop\A-Teens - 05 - Hi And Goodbye.mp3] [-]

Using Samsung Galaxy S, Android 2.2.1

Oh yes, I forgot the correct problem description:

Playback Application and version: Android client from market
Subsonic Version: 4.4 (build 2172) – February 6, 2011
Server Version: jetty-6.1.x, java 1.6.0_07, Windows 2003 (41.1 MB / 49.6 MB)
Hardware Platform: Windows Server 2003
Java Memory Limit: 100MB

[yourlord]

I'm having the same issue. Even when I force lame to encode at 64Kbps the player on my wife's android phone will randomly stop playing to buffer more. It will stop playing a 64Kb mp3, after a few seconds of play, and display that it is downloading over 1MB into the song.This should be several minutes worth of the song at 64Kbps and should not cause the player to stop playing while it buffers data that won't be played for several minutes. It seems to randomly do this. At higher bitrates (128) I've had it pause in the middle of the song to download the last few KB of the file; something that should NEVER happen.

The player even exhibits this behavior when playing off the demo server.

The player was downloaded 2 days ago from the android market.
At this point the issues with the player are preventing me from being able to convince my wife to donate. She can't justify paying for an app that is essentially useless.

My bandwidth chart on the server shows the client downloading at the full upstream bandwidth of my internet connection, even though the android player on the server is configured to limit bandwidth to 128Kbps, and the player on the phone is set to limit to 128Kbps as well.

Another symptom I've noticed, but not yet confirmed to 100% of my satisfaction, is it appears that if there is a pause in the upload of the stream, the player will briefly pause for maybe half a second. It also seems to do this when the download finishes.

[zapt0]

To the developer: How are we looking on this issue? This is very serious and even though it doesn't seem to affect all android users it makes the android app completely unusable for some of us.

[GJ51]

There are numerous factors that can affect the performance of SS on the Android app, not the least of which is the service provided by you cell carrier. In addition, server and network configuration, as well as your ISP and upside bandwidth can play a role. It takes having all the stars in the right alignment to get consistently good results.

The first step you need to take is to pinpoint the cause(s) of the problem. Is it the server, the router, the ISP, the phone carrier, the phone, or perhaps, some combination of factors that's preventing good performance.

Test your phone on the demo server. How does it perform?

[zapt0]

There are numerous factors that can affect the performance of SS on the Android app, not the least of which is the service provided by you cell carrier. In addition, server and network configuration, as well as your ISP and upside bandwidth can play a role. It takes having all the stars in the right alignment to get consistently good results.

The first step you need to take is to pinpoint the cause(s) of the problem. Is it the server, the router, the ISP, the phone carrier, the phone, or perhaps, some combination of factors that's preventing good performance.

Test your phone on the demo server. How does it perform?

Did you read my original post? I have investigated every one of your suggestions (I even posted a bandwidth graph).

The demo server gives me the same issues as my private server. (no surprise there) Seeing "buffering 2.3MB...2.4MB" and it stops ten seconds into a song.

[GJ51]

My apologies. Good luck with your issues.

[yourlord]

A little more detail. I had a chance over the weekend to use the app while driving to my in-laws.

The problem seems to mostly affect the 1st song being downloaded. I saw the problem more dramatically than it would normally impact one in general use because since I was testing, and not using, I was starting random songs and noticing the buffering and pauses on that song and not continuing.

When you queue up several songs and just listen, the stops and starts happen the most on the 1st song. By the time the 1st song is done playing, the app has downloaded all the songs it's configured to cache in the background (which should lay to rest any questions about bandwidth being the problem) and from that point on it plays fine (from the flash drive)..

It really seems the problems occur while the player is downloading from the network while also playing a song. The observations posted by the original poster above about it pausing and stating it's downloading several MB into the file when it's literally only played a few seconds of the song are spot on. If you have 1-3MB of a 128Kbps mp3 file downloaded then there is NO reason you would need to stall playback within the 1st 10-20 seconds in order to buffer more.

Again it does this same behavior with the demo server.

[dispatch]

I experience the same problem:

- queue several songs that aren't already on mobile device
- first song starts playing, then "skips" for a split second anywhere from 5-30s in
- seems to correlate to first song finishing downloading and/or second song starting downloading
- Server is Win7Pro, mobile device is Atrix running Android 2.2.2

Workaround for me is to, after queuing songs, immediately pause playback until second song starts download.

[zapt0]

Any news? I don't mean to sound like an but my trial is about to run out and I'd like to know if this can/will be fixed.

[steez]

Who is your cell provider? I have heard Verizon does some traffic shaping. It sees you are downloading MP3s and throttles you.

Do you experience the problem when using only Wifi?

Have you tried running your server with HTTPS?

[nlandas@gmail.com]

Any news? I don't mean to sound like an but my trial is about to run out and I'd like to know if this can/will be fixed.

I believe I have seen this problem on Wifi as well. Is this the case for you as well? This correlates to a strange pause I had experienced and once you mentioned that it was only in the first song to start playing, I can see how it would fit with your description.

This happens to me on wifi with a 43MBps pipe incoming. Of course my pipe at home is only about 1MBps up but it's fast enough for the task and it only happens on the first song just as you describe.

I'm wondering if it's not something in the buffering algorithm that only kicks in when the second song starts to buffer.

[zapt0]

Who is your cell provider? I have heard Verizon does some traffic shaping. It sees you are downloading MP3s and throttles you.

Do you experience the problem when using only Wifi?

Have you tried running your server with HTTPS?

The same problem persists over Wifi, yes. My ISP does not have any traffic shaping.

I have not tried https, as I am sure it is not a problem with traffic shaping (see my bandwidth graph in first post).

I believe I have seen this problem on Wifi as well. Is this the case for you as well? This correlates to a strange pause I had experienced and once you mentioned that it was only in the first song to start playing, I can see how it would fit with your description.

This happens to me on wifi with a 43MBps pipe incoming. Of course my pipe at home is only about 1MBps up but it's fast enough for the task and it only happens on the first song just as you describe.

I'm wondering if it's not something in the buffering algorithm that only kicks in when the second song starts to buffer.

Yes. Same problem. Now hopefully the developer can look at it.

[zapt0]

The plot thickens. Updating to Android Gingerbread (2.3) seems to have solved the issue with stuttering files for me. However, transcoded FLAC files still buffer for unreasonably long (600-800KB into the file for playback to begin).

However, it appears playback no longer stops and skips to buffer other than the initial buffer.

[chemikalguy]

I have the same problem, but can't upgrade to anything above Android 2.1, as my phone sucks. Still, it's a bummer to have it stop and buffer every few seconds...

[zapt0]

Still having this issue with the latest version of the app (2012-12-26).

Buffering too long, and 2-3 second pauses at random.

Galaxy Nexus / Jelly Bean (4.1.1)