Re: [slim] [ANNOUNCE] Music-Playback now on ANDROID! SqueezePlayer released to the market ...
Hi Bluegaspode. I have been away travelling in my work for some time, but now I am back. I was thinking what state we left this question in? I think my original posting was this: http://forums.slimdevices.com/showpost.php?p=650467&postcount=236 And the problem was when I move into an area with bad mobile network reception where the downlink bitrate cannot keep up with the streaming bitrate, then (of course) the music starts to glitch stutter etc. as buffer repeatedly gets emptied. You know. The player shows repeatedly buffering - playing - buffering - ... cycle with low percentages all the time. In this state it is not possible to control the player. From the commander I cannot pause or stop it, so the only exit is to disconnect the player. Which is really bad since restarting everything takes an effort: The commander loses track of the player, and then it has to find it, and then go back to your favourite radio station etc. so that could easily take up to a minute. For a start, it would be a good step forward if I just could pause or stop the player from the commander instead of being forced to disconnect. Can you reproduce this issue? Regards, Stefan bluegaspode;650579 Wrote: > Hi undret, > > thanks a lot for your feedback. > > > It could be that SqueezePlayer ignores the 'pause' command, while it is > buffering. > Seldom have loads of rebufferings, so didn't check that. > Will investigate! > > I think it would be still the best way, if the user needed to actively > stops the stream (and it worked) when he thinks it would not get > better. > > > I'm afraid I cannot change that :( -- undret undret's Profile: http://forums.slimdevices.com/member.php?userid=31038 View this thread: http://forums.slimdevices.com/showthread.php?t=87364 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] [ANNOUNCE] Music-Playback now on ANDROID! SqueezePlayer released to the market ...
bluegaspode;650736 Wrote: > Yes Controller commands first go to the server, which sends them back > (if needed) to the player. > So there is just an indirect connection between SqueezeCommander and > SqueezePlayer. > So it might be that the 'pause' command can get lost on the way back or > forth. But this is a really small packet so a slow network (working) > connection shouldn't be a big problem. > > As said: I rather think that SqueezePlayer only accepts a 'pause' when > it's in the playing state (as buffering right now is implemented as an > (automatic) pause - so I guess an explicit pause is just ignored). Yes. Have you reproduced? After a few more tests, I think that the problem appears if the buffer goes empty while playback regardless of why. Then as soon as a piece of data is written on it, that piece is immediately consumed for playback leaving the buffer empty again. And there it seems to be stuck in that loop showing buffering/playing one second each approx with small percentages shown. When playing I copied large files across the WLAN to put load on it, and then the player kept stuttering in the loop even though network capacity later had returned. Even in HSPA, there can be small periods with low throughput. If that is enough for the player to empty its buffer, there we go again. Stuck there even though network is improved. It was now a while ago, but I have seen it also when I connect to an internet radio station where the data from the stream initially appears low. That happened mostly with shoutcast streams. If I am on a mobile network, then if I press |<< or >>| it sometimes happen as well. If the buffer is allowed to fill up slightly more before playing, then that might help (in addition to what you write in your comment)? Or what do you think? Or if the user could do some configuration of a threshold value here if this is device-dependent. It is very hard to give exact instructions to reproduce since it all depends on network conditions. And probably on my device as well. Thanks! -- undret undret's Profile: http://forums.slimdevices.com/member.php?userid=31038 View this thread: http://forums.slimdevices.com/showthread.php?t=87364 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] [ANNOUNCE] Music-Playback now on ANDROID! SqueezePlayer released to the market ...
Hi. I really love the combo of player + commander. It gives me a uniform UI regardless of network streaming service together with a almost prompt playback. The commander is sometimes slow to connect, though. I am wishing that no user intervention should be necessary if the behavior can be configured. I would like it to work like the following: 1. When the reception goes bad (player detecting this situation when playback empties the buffer and network connection is not able to keep up): Player pauses the stream + perhaps give some notification (like vibrating). 2. When in bad conditions, player monitors reception and perhaps signal strength if possible to assess the current network condition. When fine, streaming is resumed. I as user, can be able to set my conditions in a coarse manner. This would be for me when the modem indicates UMTS coverage (3G is displayed with at least one bar on signal strength) or when I am connected to WLAN. But actually, point 2 there should on a phone with a decent modem be handled as the opposite of point 1, meaning that the player can detect if the network connection delivers data at a rate greater than the stream bit rate. And that the rate has been stable for like 5 seconds or so. This could be done automatically. Because while running or biking in the Swedish forest I do not want to stop to check the phone. I would be happy to help out here in any way I can. But a good step forward would be to make the player responsive from the commander when the buffer goes low. I realize that if network situation has gone really bad, the commands might not be able to transmit? Or, I do not know how the player control works, but are the commands proxied by mysb.com? I am working in mobile telephony with some Android experiences as well, so I might be able to help out or contribute. Thank you. -- undret undret's Profile: http://forums.slimdevices.com/member.php?userid=31038 View this thread: http://forums.slimdevices.com/showthread.php?t=87364 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] [ANNOUNCE] Music-Playback now on ANDROID! SqueezePlayer released to the market ...
I am using the Player and Commander on my Android Nexus one and connected to mysb.com. I listen to internet radio stations (almost all saved from the TuneIn Radio app) while on the move outdoors. So I stream over the mobile network. Usually it works well. This combo is superior to the tunein app which takes a good amount of time to connect, download presets, and buffer the stream before play. It can take up to half a minute before music starts playing. BUT there is a big problem, and it might be just that it happens on my particular phone model and operators When I have good network coverage (meaning access to high-speed access technologies UMTS, HSPA, and "best" variants of Edge) I get nice playback. But when I enter an area with bad coverage where the downlink bandwidth is not sufficient to support the bitrate of the audio stream, the music starts to glitch and interrupt. At this point the behaviour is pathological: Player goes into an endless loop (repeatedly showing playing, buffering, connecting with a few percent shown), The player gets uncontrollable and does not respond to any Commander commands (like pause or power off). Only way to exit is to disconnect player from the server, and then wait to connect it again until I have better reception. Then the modem of my phone behaves crappy as well. It seems like it sticks to a certain bearer as long as it is available and there is a connection using it. So if I have the player connected with UMTS, lose coverage of that and the device switches to poorer Edge with insufficient bandwidth, it will then tend to stick to that even if I move back into UMTS coverage again! It will not switch as long as player is connected. The handling of this situation could be improved. I suggest: * If the player buffer levels drops under a certain level and where the rate of data from the network cannot sustain the playing rate then the player could pause the downloading of the stream, silence the music and give an indication to the user. * Then it can wait and monitor better network reception. When that happens the streaming can resume. Of course it is difficult to predict if you will indeed get a sufficient bitrate in your downlink beforehand, but UMTS and HSPA should do fine. Edge could be excluded since that almost never works for me. I don't know if it should also disconnect from the server, though. Any thoughts or experiences? -- undret undret's Profile: http://forums.slimdevices.com/member.php?userid=31038 View this thread: http://forums.slimdevices.com/showthread.php?t=87364 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
