I do apologise for the tardiness in the beta 5 release.
The feedback on the existing beta 5 has not picked up too many issuesand they were fixed in the minor rev updates (except passwords ..which we have now fixed) . However Martyn and myself keep finding the odd thing we need to tweak so I'm guessing we need more beta testers to pick these things up.
We've also been adding a few new things and in doing that have moved from the stability of that pre beta 5 introducing some work in progress code and until we get back to a stable build it won't be released. We're not far off but there are some loose ends still. One significant change to the code is causing me a real headache on the Joggler (works fine on a PC) and I need to address that. Martyn had another similar issue but he's now fixed that.
Coordinating multiple contributors into one build is more awkward than I anticipated - getting everyone in synch at the same time.
Some documentation still to do (yawn - so boring) as things have changed quite a bit . As we will have quite a few new users trying the next beta I need to improve the docs and I do hope that everyone will chirp in and help them with their questions on this forum. There's likely to be a few xAP based questions too.
Real soon now... Kevin
Great news Kevin.
Haven't found much else except the random reboots on my Joggler.
I still need to try and look into that. Oh and the loss of status from HAH but waiting for new HAH release to see if thats fixed.
I was using DHCP with a statically reserved IP for the Joggler. I have had some issue with this method before i.e. Squeezeboxes didn't like it. Have now changed that to fixed IP and will monitor.
I'd like to restart the iServer daily but can't find a way to start the app with a specific security profile active, does that matter?
I use reserved DHCP addresses on quite a few bits of kit and seems to work OK - only reason I don't use more is that my router only supports ten of these. Interesting that SB devices didn't like this - although I think mine are all now static. I mainly use the DHCP allocations for my Sonos gear which doesn't allow static , plus any roving devices like my phone.
Re restarting iServer every day - short answer no it doesn't matter,
(typically) longer KH answer .... It shouldn't be needed and if it is for some reason I'd rather try and find out why. I'd recommend you don't do this. If you are wanting to build in resilience a system that monitored iServers heartbeats and warned or restarted iServer should it be stopped or fail would be far better. As xAPFlash isn't as yet providing unattended control it's not in a particularly critical role. It's more like a fancy lightswitch currently. Implementing iServer as a Windows service might be a useful change though.
iServer does various things at startup and for about 15 minutes afterwards , for example building it's internal list of 'known xAP' devices. Although not used by xAPFlash, iServer also models the state of known xAP BSC endpoints which takes around 10 minutes to complete. At the point you restart iServer any connected devices will lose their state synch for a short while.
Re active profiles. If iServer is restarted then any devices connected to iServer will detect that their socket connection was broken and should reconnect pretty much immediatley when iServer starts again , so you don't need to worry there, it's all handled automatically. xAPFlash might be a bit aggressive in this respect sending too many reconnect requests as I have seen a race condition occasionally where iServerr shows more connected clients than actually exist. This may already have been fixed. iServer supports multiple different profiles concurrently. I've also occasionally seen a situation where the xAP button in xAP Flash shows an increasing count of absent xAP devices. I need to get to the bottom of that, I have changed some code here in the next beta - we'll see if that fixes it.
xAP Flash can create xAP endpoints for all of it's internal elements plus status reporting and control for internals like volume, screenbrightness, screensaver etc . All buttons(two endpoints each), textboxes, pages report via BSC and are controllable for visibility. There can be quite a lot of these if you have them all always reporting - my larger template design presents around 800 I think ! Instead of enabling all these globally the next beta allows individual elements to be xAP enabled which is much better.
iServer has an (arbitrary) limit of 5000 endpoints it stores, and the more there are the harder it has to work as it has to search all these at startup for every incoming xAP message . I don't expect anyone to ever reach this limit although interestingly whilst testing various peoples xAPFlash templates, and because iServer remembers every endpoint it's ever heard, I have managed to exceed it. I need to consider how to better handle this within iServer. The number of entries in the knownxAP.txt file shows how many devices it has ever heard.
Keeping the number of xAP endpoints as low as possible on your xAP networks is the recommended way as it reduces traffic. Disable the reporting of things that can't possibly ever change state . A xAP Netiom I/O board for example reports over a hundred endpoints out of the box. If you're only using 6 of the inputs/outputs then disable the rest.
K
Last edited by Kevin; 4th November 2010 at 02:22 PM.
Is label offset only for vertical alignment?
I have some buttons I designed where i'd like the label to appear over the button but the button has an icon LHS - so I'd like to offset the label to the right.
Is this possible, or is that a feature request?
Thanks,
Paul.
Ah, I also noticed that the on state button (using my custome PNG button) overwrites the label (or the label disappears). The offset for the label was -40 so it'd appear over the button - is this a bug or are labels not intended to appear over the buttons?
It's not currently possible, it wouldn't be overly hard to do - but there's another way assuming the buttons aren't individually changing visibility*.
It's not a bug, labels were intended to be outside of the button area. Externally loaded buttons use two or more image files that are swapped as necessary and hence this happens should the label be offset into the image area. I may be able to stop this happening however..
You might be able to get around this using a BSCtext field associated with the button but this would be fixed position wise and centralised to the button which is not what you're wanting...
The way around this would be to place a text box over the button. Textboxes within a page are added after buttons so they should be on top of both button images and you can set it's x,y at pixel resolution
K
* A label is associated with a button whereas a text box isn't. If a button becomes invisible or moves then it's label will to , as would it's BSC text field. This would only be a problem for individual buttons - and not for buttons on a page where the page visibility changes and hence hides the buttons and textboxes within that page.