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).
Results 4,151 to 4,160 of 5329
Thread: iPeng support thread
2012-01-29, 13:15 #4151
2012-02-01, 14:38 #4152
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.2 x SB3 (wired), Receiver (wired), Boom (wireless), Controller, iPeng on iPhone 4 & iPad, muso on remote computer running Win 7 64-bit | 7.7.3 on Win XP
2012-02-01, 17:12 #4153
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.
2012-02-01, 23:13 #4154
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.2 x SB3 (wired), Receiver (wired), Boom (wireless), Controller, iPeng on iPhone 4 & iPad, muso on remote computer running Win 7 64-bit | 7.7.3 on Win XP
2012-02-03, 09:45 #4155
- Join Date
- Feb 2010
2012-02-03, 10:03 #4156
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.
2012-02-05, 16:37 #4157
- Join Date
- Feb 2010
2012-02-05, 17:18 #4158
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.
2012-02-05, 21:30 #4159
- Join Date
- Dec 2005
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).
2012-02-05, 21:50 #4160
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.