iPeng support thread

[pippin]

OK, then let's see whether the next update fixes it, there's been some changes around this which are not in the current release, they might be in the current iPad release (not sure, though).

[vagskal]

This one is strange. I have three players in a group. When I set a new alarm on a player that is not shown at the top of the list of the grouped players (I.e. is not the "primary" player, I think it is called), the alarm is instead set on the top/"primary" player. If I instead activate an alarm already set, the activation will not "stick", but nothing is set on the top/"primary" player, I.e. no alarm at all is set/activated. I must ungroup the player I want to set the alarm on to have the alarm set on that player; I could not find a way in iPeng to reorder the grouped players.

[pippin]

Is this the latest version?
I thought this was already fixed in 1.2.6; this is iPeng for iPad, isn't it? Not sure it's the same in the iPhone version.

Regrouping doesn't help, it's the server which decides which player is the master.

There's an iPeng update waiting for App Store approval that will fix this issue.

The problem is that for synced players iPeng always sends menu commands to the master. This is to avoid issues many users had (not only iPeng users but Squeezebox users in general, you can easily have the same problem with the controller) with accidentally powering up players in a sync group. If you have several players synced and the one you are controlling is powered off, sending any "play" actions to it will power the player on, even though others are already playing. Now, often you don't realize you aren't actually controlling the player you are listening to, it doesn't seem to matter anyway since they are synced, with iPeng's group volume even volume changes work as expected... until you accidentally power up that Squeezebox in the bedroom...

Obviously this behavior should be different for player settings.... fixed in next update.

[vagskal]

Yes, iPeng for iPad 1.2.6 with latest LMS 7.7.2 Windows build. All grouped players were switched on with synced volume, although one player had its volume set to 100%.

Thanks for fixing this for the next version! It was confusing and it took a while to figure out what was going on.

[mps]

I tried setting "Pause On Call" and testing it over the last few days. It successfully paused five times (although it failed one other. I'll let you know if I figure out how to reproduce).

Thanks so much for supporting this valuable functionality,

Mike

Spoke too soon It doesn't work at all when ipeng is in the background. Any hope for a fix?

Thanks,
Mike

[pippin]

Spoke too soon It doesn't work at all when ipeng is in the background. Any hope for a fix?

Well, iPeng has to run to be able to do that, iPhone doesn't wake up background Apps when a call comes in, why should it?
The next release (currently waiting for App Store approval) will have a changed behavior for background execution that I originally added for another purpose (being able to use the lock screen for volume/skip/pause and the volume keys) but that works with call pausing, too:
If you enable "Settings->iPeng Settings->Preserve Connection" iPeng will stay active in the background for up to an hour, during this time "Pause on call" will work.
But please be aware that this costs some battery.

[mps]

Well, iPeng has to run to be able to do that, iPhone doesn't wake up background Apps when a call comes in, why should it?
The next release (currently waiting for App Store approval) will have a changed behavior for background execution that I originally added for another purpose (being able to use the lock screen for volume/skip/pause and the volume keys) but that works with call pausing, too:
If you enable "Settings->iPeng Settings->Preserve Connection" iPeng will stay active in the background for up to an hour, during this time "Pause on call" will work.
But please be aware that this costs some battery.

Preserve connection did the trick, thanks! Looking forward to the long term solution but happy in the meantime.

[pippin]

Preserve connection did the trick, thanks! Looking forward to the long term solution but happy in the meantime.

Err... It did the trick now? Interesting, but this should only work behind the screen saver and not in the background, right? That was the change to be coming....

Oh, and which iOS version is this? I thought it would not work in iOS 5 (until the next update).

There is nothing else I can do in the long term, the App has to be awake and there is no other way to make sure it is other than keeping it running.

[treble]

Is it possible to use iPeng playback when I remotely connect to my server with https/ssl tunneling (as described in the following wiki page: http://wiki.slimdevices.com/index.ph...cting_remotely ). I have set up the proxy thingy to redirect incoming request to port 9000 internally.

I can enter the server fine in iPeng settings, but it doesn't connect. I guess because it is sending packets on port 3483. I tried the same proxy thingy for this port but it still doesn't work. Maybe something else needs to be done?

When I have port 9000 open on my router, I can connect fine to the remote server (using http://myserver.com rather then https://myserver.com).

Thanks,

[pippin]

Does only the playback not connect or does already the remote control connection fail? If remote control works you should at least find your library.

If it's the playback only you've probably used a different port from 9000 externally which doesn't work, the external and internal port always have to be the same because the server keeps telling the player to use port 9000 otherwise.