Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.2 Followup Releases Info
#1
This thread is for me to provide info about 4.2 follow up releases.

Normally we do this kind of thing in the beta area, but I've been doing followups on 4.2.0 for a few reasons, some obvious and public and some private. We want to get a solid and higher performance 4.2 version out there before we move on to doing major surgery for 4.3.

The currently available versions are:

Official: 4.2.17 (available on the web site)
Unofficial: [None at this time]

See the posts below for a list of changes made in the various follow up releases.

If you are on any previous 4.2 version, it is highly recommended that you upgrade to 4.2.17, which has many new improvements and features. It's unlikely that there will be any more 4.2 versions. We are now on to 4.3 beta land. So I'm unstickying this post.
Dean Roddey
Explorans limites defectum
Reply
#2
Info for versions 4.2.1 through 4.2.5:

  • Fix some issues with the Denon 3805 driver, which has to power on Z2/3 in order to get their status during driver connect. It would sometimes fail to turn the zones back off if it powered them on, and it would sometimes not be able to connect if the power was already on and would just cycle.

  • There's an issue that can cause a driver prompt to be lost if a driver manifest has both a fixed and a user provided prompt whose name hashes to the same value.

  • Update the NWS driver to support URL redirection from the server, which they have started doing lately, breaking the existing driver.

  • Add support to the Leviton Z-Wave driver for controllers. They just exist so that they can see button presses on scene controllers so far. When they see a button press, they send out an user action trigger. This involves improving the ability of the user to provide configuration info, and some internal plumping improvements. Add an association from the scene controller to the VRCOP and that should cause the VRCOP to see the scene activations and send out the trigger.

  • Add a new standard runtime value that holds the host name where the master server is running.

  • The VRCOP driver's association setting dialog is reversing the target/source values, so associations don't work correctly when sent to the server side driver to do.

  • In the Interface Designer, if you do a Revert on a progress bar widget, the fill mask bitmap doesn't get set back up, so if you go to the PBar tab and it tries to access to the raw pixel data, it fails and you can't ever get the PBar put back unless you close the interface and re-open it. It should create a new fill mask when a progress bar object is copied under the designer.

  • Go back and do another round of optimization related to field access. This one will be brain crushing but should result in a very substantial improvement when there are large to larger numbers of drivers and/or fields involved and noticeable improvements in general. A 'field cache' is often used, so that all available drivers can be available to clients for quick access when doing things like running actions or loading templates. We can do some stuff there to make it a lot more efficient.

  • Improve use of the ORB's object id cache, so that fewer remote interface accesses require a lookup call to the name server. This will significantly improve performance.

  • Provide a low level (IP name lookup level) short term cache of name to address lookups, which will make a significant difference in performance during the bursts of activity that accompany loading a new program, runing an action, or loading a user interface.

  • Make spin box controls so that they will wrap around when you hit the start or end, so that, if there are a fairly large number of values, you don't have to go back through all the values to get back to the other end.

  • Some not well thought out code was causing a clicked on widget (one that invoked the popup) to redraw just before the popup came up. That would be particularly heavy and visually obvious for things like the cover art browser, and it would make the fade in of the popup more ragged.

  • The CML base driver class' GetFldErrState method is wrong in a couple ways. Currently it is checking the state of the driver and, if the driver itself is not connected, it's considering the field in error state (though it's doing that wrong as well and returning the wrong thing.) But it shouldn't even be doing that. It should just return the state of the field itself.

  • The new advanced media item browser widget isn't honoring the search and replace operation when template paths are selected. This is also causing the autogeneration stuff not to update it, so that it's still point to the original one over in the System area, which isn't appropriate, in case we should change it at some point.

  • The flyover text for the Host Admin dialog's Pause/Resume button is incorrect.

  • In the event server, for daily or weekly events (which have a specific time of day to run), the Start At value wasn't being correctly used. If you set up a Daily event for, say, 9PM. Then you bumped the start time up to 9:01 and saved it. The start time should have moved up to 9PM tomorrow, but it woudln't do that since the newly entered Start Time wasn't being correctly used as the basis for calculating the next runtime.

  • When the auto-generation stuff was changed to use new the advanced media item browser, it wasn't correctly updated to copy over and update the layout template.

  • The auto-generation stuff could fail if both music and movie players weren't set, because it wasn't always making sure the moniker had been configured before trying to use it.

  • The frame window class wasn't correctly overridding the text change notifictaion and was therefore getting the default response, which is to redraw the window. It should override and do nothing since nothing is necessary in this case. This was happening was in the triggered event filter screen, where typing in the description would make the whole dialog box blink on every keystroke.

  • The low level IP lookup cache should be periodically flushed of all out of date entries, so that a long running system that was accessing different external IPs over time won't pollute the cache. And it should also do a flush pass if the cache should ever get full. A similar sort of thing should be done with the ORB object Id cache as well.

  • The RIVA server never got updated to support the logoff command from clients. So even if they sent it, it wouldn't cause a clean shutdown and you'd get a socket error message in the logs. Preferably clients will send a logoff opcode before they exit. It's not acked or anything, it just tells the server to close that session down and not try to use the socket anymore. Update the C++ RIVA client to send one.

  • If the IP driver connection object is asked to format the address info, it should only use the actual end point object if it has already been successfully resolved. If not, it could cause an exception when trying to format the info. It should instead in that case just use the raw address/port info provided by the user and format that out.

  • Get the most recent version of the LG TV Universal driver into the build (version 0.17 currently.)

  • The fundamental ORB lookup operation, connecting to the name server (which uses the only fixed address in the system, the master server address) is currently such that it wouldn't really recover from the address of the master server changing. Instead of pre-looking up the address and storing it, just use the object id cache as with all the other object ids, which will let it remain cached as long as it works, but remove it and force a re-resolution if the server can't be connected. That will provide just as good performance in a working system, but allow for better recovery if issues occur. The IP address will still be cached in the low level name lookup, so even if a burst of operations occur while the MS isn't available, they won't cause rapid repeated address lookups, even through the object id is being rejected and recreated repeatedly.

  • Since we've improved networking efficiency so much, reduce the cycle period that servers renew their name server binding lease. This will allow for faster recovery if the master server (or name server specifically) cycles, since the other servers will get themselves re-registered considerbly more quickly.

  • The recent optimizations of the field cache woudln't appropriately remove a cached object id from the cache if it failed. It would catch a change in a CQCServer's address, but not a cycle of the server where the IP was the same but the per-invocation generated interface id was different. So clients wouldn't recover from a cycle of a CQCServer for minutes.

Dean Roddey
Explorans limites defectum
Reply
#3
Info for versions 4.2.6 through 4.2.9 (Part II):

Version 4.2.6 Changes:
  • Make some significant improvements in the ORB and particularly its object id cache, moving it to a lower level facility, so that we can watch for object not found exceptions from the servers and quickly remove invalidated object ids from the cache, allowing for faster recovery if a server cycles.

  • The field poller engine (used in various places) hasn't been updated to make use of the new ORB object id cache, so update it. This will further increase system performance, and recovery from server cycles, because it will allow the polling engine to avoid lookups. And lookups it happens to do initially during template loads will mean they won't have to be done by actions invoked by the template later.

  • There are a couple places in the RIVA server where it bumps the outgoing sequence id, then does some work to fill in the outgoing message, then sends it. If an error occurs while it's doing that in between work, the server will attempt to gen up an exception message to send to the client. But it will then bump the sequence id again, and the client will see an out of sequence error, which will cover up the actual error that occurred. The same could happen if the server times out trying to send the message becaues the other side is backed up. So change it so that it only bumps the sequence id after successfully sending a message.

  • If the master server goes down, clients will repeatedly log an error about not being able to access the name server. This should be made a more verbose level message so as not to fill up the logs.

  • The installer's backup panel was only allowing itself to be visible in upgrade mode. It should have been instead making itself visible unless in clean (brand new) install mode.

  • The Leviton Z-Wave driver client isn't counting the little optional info unit configuration as part of unit quality, so the Save button doesn't get enabled if you just change that bottom combo box setting. So you can't save those values unless you some them along with some other change.

  • The C++ string class' method that caps strings at the first instance of a given character wasn't updating the string length member, so it wasn't actually capping the string, except for when it was passed to system APIs that just go by the null terminator. Though it may have caused other issues, it was showing up when the new master server host name runtime value was being expanded in an action command parameter. It would cap the HOSTTongueORT string at the colon, but that wouldn't really cap it, so it the port would still show up.



The 4.2.7 changes:
  • The classes that store the values of driver fields assume that their 'set value' methods won't be called unless the base driver class has determined that the new value being written by a client is different from the current value (or it's write always/write only.) However, if the xxxFldChanged() callback writes to the field, when the callback returns the driver will store the value as well, for another write. That will cause two event triggers to be sent if one is set on the field. So the field value classes will have to do a second, semi-redundant check of the value they are being asked to store in order to possibly avoid sending a second trigger.

  • The driver install wizard's summary screen shows IP connection info as the resolved address. But it should display whatever the user actually entered in terms of host/port.

  • The RIVA server should try to give a little more time for the client to absorb messages before it times out because it can't send.

  • Both the simulator media renderer driver and the Dune HD media renderer driver fail to update the ActiveRepository field when the SetRepository field is written to, so you can't change the current repository. Both were updated to do the right thing, which is to store the new incoming value to ActiveRepository, unless it is empty in which case they set ActiveRepository to the default repo set during driver installation.

  • The CML driver IDE's change field popup should allow an empty value, since that's sometimes a valid value to write to a field. Currently it's telling the generic input dialog it uses to get the value not to allow the user to accept an empty value.

  • Thing are coming up so fast now with the recent performance optimizations that the event server should wait a little longer than it currently does before it starts processing event triggers and scheduled events, to give drivers time to come online (which is not something that we can make go faster typically.)



The 4.2.8 changes:
  • There's a potentially bad bug in a low level string method. It was previously only semi-dangerous, but dangerous nonetheless, but a change made to that method in 4.2.6 allowed it to become more dangerous. It's of the sort that could potentially explain sort of any kind of wierdness, i.e. potential memory corruption under the right circumstances.

  • The methods for accessing template values are not supposed to be available in the OnPreload stage of loading a template. At that point, when invoking popups, the new popup layer's context hasn't been created and pushed onto the stack yet, so you are really accessing the underlying template's values, which is not desirable. It would be confusing to allow that to happen. So these have been disabled in the OnPreload and should be done in the OnLoad. Hopefully no one was inadvertantly depending on this, but if so it could be a breaking change. Sorry about that, but it needs to be done.


The 4.2.9 changes:

This one just has a couple small fixes, mostly one to deal with the problem some folks had on 9/12 where some kind of clock rollover problem caused some peole's systems to stop. No need to worry about it now since it won't likely happen again for along time anyway. But, if it does, it won't be an issue now.
Dean Roddey
Explorans limites defectum
Reply
#4
Info for version 4.2.10. This version just introduces some documenation fixes and some small fixes. If you are on 4.2.9, then no particular reason to upgrade to it yet unless you use the File Tag Repository driver, which it has some fixes for.
  • Update the Sonos Zone Player driver docs to explain the trick of grabbing the CurTrackURI when a radio station is playing, and then you can write it back later via the SetTransURI command (of the COmmand field), which isn't even documented currently.

  • The docs for the CML Time class' GetJulianDate() incorrectly indicate it returns today's Julian date, when it actually returns the date for the current time stamp in the time object.

  • A change a while back to handle the installer scenario where nothing but the RIVA client is installed (and therefore we need to suppress various things), was incorrectly done and now the master server connection test panel doesn't show up if you have the RIVA client selected in any scenario. Sigh... If it weren't for stupid, I'd not be smart at all.

  • Add Bitrate and user rating to the info we extract from media files, and update the FileTag repo to use those new values. However, rating is useless currently for MP3, AAC or WMA files because it's not standardized for MP3/WMA files and not defined for AAC files. Bit rate isn't defined for AAC files either. It may exist but it's a proprietary format so I can only go by what folks have discovered so far, and I don't see one for bit rate. Bit rate for MP3s should become available now though if set in the file.

  • There's a bug in the loading code of the File Tag repo driver that makes the year always be set to zero.

  • The auto-generated weather screen spells the precipitation prefix incorrect, percip instead of precip.

  • There is a bug in the GetTmplVal action command. If you say the value doesn't have to exist, and it actually doesn't, it should create the target variable anyway and just set the value to empty. But, instead, it doesn't create and set the variable, so you can fail if you try to use that target variable subsequently. This was showing up in the auto-generated media player playlist mode screen. When you select random category, you have to select a category to play from. It checks if you selected one or now and warns you, but due to the above it causes an error when it tries to check if the value has been set yet.

  • The dialog box that gets the latitude/longitude info, if you enter an invalid number, creates an error box to display the error, but doesn't actually display it, so you never know why it's not exiting. And, now that the error is being displayed, make it more informative as to what is expected for the values.

  • The File Tag Repo's short description in the manifest calls it a Browser. Change that to Repository instead, since that's more consistent.
Dean Roddey
Explorans limites defectum
Reply
#5
I've posted 4.2.11. This one includes a substantial reworking of how clients (and servers are almost always clients of something else as well) cache information about how to find the servers they need to talk to. Caching improves performance. But, it also means that you can get stuck with now out of date information if that server goes away. Not that that's a huge problem, if the server isn't there you weren't going to contact it anyway. But, when servers cycle it can also happen as well, the server is back up but you still are using the old (cached) contact info.

So it's always a compromise between having to go practively find servers (which lowers performance) and reasonable recovery time when servers have to be cycled for some reason. This one provides a much better compromise between those two needs, and does so very efficiently, and in a way that doesn't require lots of nitpicky (and therefore easy to break) coding by me. So it's way better all around. It might actually also be a bit faster as well, since it caches more stuff, now that I can be sure that out of date info won't hang around long.

It also includes a number of small improvements, in the auto-generation configuration screens and in the CML driver test harmness, and a new driver.
  • Add a driver that supports the Roku streaming player.

  • If a scheduled event is paused, don't display the next runtime value on the right. Change it to indicate it's paused, just to be consistent.

  • If you edit a paused scheduled event, it doesn't correctly get the paused icon set back when you save it.

  • If you do a fully custom install, and you get to the RIVA client and the host you had set up there previously is not found, it won't let you get past that panel. It should warn you, but allow you to continue if you want, so that you can still install even if that host isn't available.

  • In the CML driver test harness, the stuff done from the field monitor dialog is queued up and processed asynchronously by the driver. Crrently, there's no way to wait for the operation to complete and get status info back from the driver. So, fix this and allow for the driver to put data back into the queued up item and give it back, so that the field monitor can wait for it to complete and get status/data back.

  • Now that we can get back data from the driver in the CML IDE's field monitor dialog, allow for testing of the querying of driver text, since that would be very helpful for testing of drivers that support text query backdoor commands.

  • Now that we can get back data from the driver in the CML IDE's field monitor dialog, report errors or timeouts that come back from the driver, instead of just having to watch the logs for them.

  • Do the same thing for the logic server's Admin Intf dialog that we do for the event server. Do a quick test of whether the remote interface is registered and quickly indicate if not. Don't just try to try to create the remote interface with the usual timeout.

  • Do another huge update of the ORB infrastructre, in order to provide a much cleaner, self-maintaining balance between keeping the ids of remote interfaces cached locally and being able to recover quickly if the master server cycles. This new scheme is almost completely transparent to code that uses the ORB, and works for all remote interfaces. Those that are active and working will remain cached, and those that are sparsely used will time out fairly quickly so that they won't be hanging around to be accidentally used after a master server cycle.

  • In the auto-generation stuff, in the security zones section. If the driver you previously used is not present, you can't delete the zones because the popup won't come up due to complaining about the previously used driver not being available. In any cases where you select a device and later other selections are made based on that device, we need to be able to give the user the option to reset the data.

  • In the auto-generation configuration, change it so that errors are displayed as a list and you can either choose to just go ahead and save, cancel saving, or double click one to go to the error and fix it. They should be presented by template and room, so that it's obvious what each error applies to.

  • In the auto-generation configuration, go through and find all the drivers that are referenced and make sure these are in their respective lists, even if those drivers don't currently appear to be loaded. Otherwise, we can silently remove them when the configuration is saved. We'll just warn the user that they don't exist when they try to save or access them.
Dean Roddey
Explorans limites defectum
Reply
#6
I've put up a 4.2.12, which is just to get a new Z-Wave and OmniTCP driver out. Both of them needed fixes now and I couldn't wait until I finished up the stuff I'm working on.

http://www.charmedquark.com/Web2/Downloa...4_2_12.Zip

The stuff I'm working on is replacing the App Ctrl program with a new Tray Monitor program that subsumes the App Ctrl stuff, plus adds more stuff, and works as a regular tray app, which is much nicers. However, it's not really working, so don't download this version if you need app control, since you'll be out of luck for now. The tray monitor program is installed and is in the start menu but don't run it.

The OmniTCP driver changes are to deal with a change in format that occurred in like 3.10B or C or some such. It's a legal change, the driver just wasn't being smart enough to deal with it. That has been changed now.

The VRCOP driver changes are to much improve it in terms of dealing with changes in configuration which can leave old configured units in the list though there's no longer any such unit out there. We don't want to remov the config since that would destroy the configuration work done if a unit just happened to be non-responsible temporarily. So they are left in the list and you have to remove them. They are now marked as missing to make it clear, and there's a delete button to delete them. And there's now a Rescan button to force the driver to rescan after you have copied new unit configuration data to the VRCOP.

The detailed changes for this drop are:
  • Update the auto-generation configuration classes to support exporting their info to XML format. This is in preparation for making it accessible via the XML Gateway.

  • Implement a new platform abstraction class in the CIDLib layer that supports Windows tray apps, so that we can have a tray app in CQC.

  • If a unit is configured but not found when the VRCOP is scanned for units, then they are marked as missing, but the client side interface doesn't indicate this in any way, or provide any means to delete it from the configuration. So provide a delete button, and display the missing ones in red, and disable all the stuff on the right when a missing one is selected.

  • Recent Omni firmware introduce some changes in the data format, and the driver wasn't being smart enough to deal with this as it should, so this made it mis-interpret the data. This should be fixed now and it should not be affected by such changes in the future.

  • The VRCOP client side driver provides no means to force a re-scan of the units, and it doesn't have any way to update when the configuration changes. Even when a given client driver pushes up configuration, it's not until the VRCOP has been re-scanned that the new config is stored (and it might include newly found units on the network, not just the stuff in the pushed configuration), so we need to be able to update after that sort of scan completes as well.

  • The VRCOP client driver doesn't go offline when the server side driver goes offline, therefore you don't know the server side driver is not there, and it also means it never recycles the ORB connection so when the driver does come back, the client side continues to use the (now bad) connection and it can't reconnect.

  • The VRCOP driver wasn't correctly dealing with secure status notifications, which don't follow the normal general report format, so they have to be dealt with specially to get them into the format that the unit classes expect. That way the unit classes don't have to care if the reports were security or non-securely sent.

  • Update the installation config classes and the installer to replace the old app control server with the new tray monitor program. The new tray monitor isn't working yet, but we needed to get this much done in order to get a side release out with some Omni and Z-Wave VRCOP driver fixes out for testing.
Dean Roddey
Explorans limites defectum
Reply
#7
Version 4.2.13 is posted. This has some quite substantial changes. Most importantly is the new Tray Monitor program. This program takes over the job of both the old App Control server and the old iTunes Tray program. Plus it provides a popup menu to start/stop the CQC service.

There is a new iTunes repository driver to work with the new iTunes part of the tray program. It is faster and it also handles incremental updates, meaning if you make changes in iTunes they are picked up immediately by the driverIf you are using the old iTunes tray app/driver, go ahead and remove those before you upgrade and then install the new ones afterwards.

Things to consider:

1. If you had App Control installed previously, it will be installed in place of that automatically, though no iTunes functionality will be enabled, and it will only be set up to run manually.
2. If you want to enable the Tray Monitor, or add the iTunes functionality or the auto-start option, then do a Fully Custom install and set up the new Tray Monitor options.
3. Auto-start means it'll start up after you login. There will be a delay just in case the system is starting up, then it'll come up. The auto-start is done via the Windows task scheduler.
4. If iTunes is enabled, then when the Tray Monitor runs, iTunes will be started automatically. If you try to stop iTunes, the Tray Monitor will just start it back up, and do a reload, since it has to stay in communications with iTunes to work.
5. You can right click the Tray Monitor icon and stop/start the CQC service if it's loaded. If you put the mouse over it you'll get an indication whether the service is running or not. If the service starts or stops, you'll get a balloon popup indication.
6. If you have no local service, and neither iTunes nor App Control is enabled in the Tray Monitor settings, it will ignore the request to install it since it will have nothing to do.
7. If you left click on the icon, you'll get the main window which has a tab each for App Control and iTunes, with status info and some control over things available.
8. The new iTunes driver has to run on the same machine as the Tray Monitor it is to work through.

I forgot to deal with running the Tray Monitor when it is already running, so be careful of that. You'll get an exception if you try to run it and it's already running, and it may cause bad things to happen, not sure. I'll deal with that in the next drop.


The detailed list of changes are:
  • Implement support for tray apps in our CIDLib object framework, so that we can implement a Windows Tray based program to replace the App Control server.

  • Using the new tray app support functionality, implement a CQC level tray app that can be used for multiple things. It will provide a convenient means to do service start/stop, provide system status info in a popup bubble and flyover text, and support a few optional pieces of functionality, see below.

  • Move all the old App Control functionality over into the new Tray Monitor program. It will now be just one tab available in the Tray Monitor's main window (available by clicking on the icon in the tray.)

  • Improve the App Ctrl functionality by no longer requring it to become visible in order to do certain 'force to front' type operations on controlled applications.

  • Implement another tab in the new Tray Monitor program that interfaces to iTunes and maintains a standard CQC media repository by pulling data over from iTunes. It will provide an interface for a new iTunes driver to get to the data. And it will watch change notifications from iTunes and update its in-memory database on the fly to reflect those changes on the fly.

  • The above iTunes repo driver requires that we factor out the standard repo driver functionality that manages the in-memory database, because heretofore it's always been an actual repo driver that used it and therefore it is integrated into the base repo driver class. This is a lot of work and affects all repo drivers.

  • Implement a new iTunes driver that talks to the Tray Monitor program. It will just be a passthrough to the Tray Monitor's iTunes module. Retire the original (XML file based) iTunes driver, which was never very successful because Apple doesn't either document that file or keep it consistent. So it's not likely used by anyone anymore. The previous driver, which talked to the old tray app, will be kept around for now until everyone has had time to move over to the new one.

  • Update the installer to support the new tray monitor. It has to both install the tray monitor with the correct options, but also to install an auto-start option if you select that. It will only install if the service is running locally, or the iTunes or App Ctrl options are enabled. Else there's nothing for it to do.

  • Update the uninstaller to get rid of the new optional Startup folder link for the Tray Monitor.

  • In all of the places where the old 'app control binding' type value was referenced, replace that to indicate that it is referring to a target tray monitor now. In the installer, default the old binding value to the local host name, which probably everyone will just accept since it works fine. That will simplify installation, without breaking existing installations (so we can just take the old app control binding and use it for the new tray monitor.)

  • Update the media system so that you can get cover art via media items. Update the Media Image widget so you can associate it with item cookies (in addition to title/collection cookies.) This way, you can get the right cover art even when an item is played via a playlist.You will have to change your Media Image widgets to be associated with the current item field instead of the current collection field before you will see this change.

  • The recent change to allow the CML driver IDE's field browser window to wait for field writes and other driver commands to complete (so that it can show the status of those operations) didn't take into account that you might have a break point in the code that handles that. So the field monitor window (and it's command invoking dialogs) should just disable buttons and use a timer to watch for the current command to end before allowing a new one. This avoids all of the issues of deadlocking, while still not allowing more than one command at a time to be queued up.

  • In the CML IDE, it shouldn't complain about the driver not being in connected state when doing a verbosity level set. If the driver isn't loaded yet, then just store it as the default verbosity in the IDE to be used on the next driver start. Otherwise, we can always queue it up as long as the driver is running at all (i.e. any active driver state, not just connected.)

  • The CML IDE is logging an unknown exception error in the Idle callback when in high verbosity because it was accessing something when it hadn't actually been set yet. This was introduced in the same changes mentioned above.

  • The VRCOP driver should be updated to have lock units watch for alarm report/get notifications and use the code to infer a lock/unlock change. Some locks send this instead of a regular lock/unlock report.

  • Create a new Lock Status type standard event trigger. It will be sent out by devices that control locks. It includes the source driver moniker, the status of the lock ("locked" or "unlocked"), the name of the lock (driver specific, however they identify locks), and optionally a user code if the lock makes that info available. Add new filters to the triggered event filter system to filter for these types of events.

  • Update the VRCOP driver to send out the new lock trigger when it sees the lock state change.

  • Udpate the XML GW server to support reporting a list of available room configurations (a list of room names) and to query the info for a specifc room. And have the data server cache the latest info in memory now, so we don't have to read it from file every time its accessed.

  • The new changes to the media database to support incremental update mean that we need to have unique ids assigned to items now, where before we didn't. The CQSL repo, which stores ids persistently, will need to generate unique ids for all items upon first load after the upgrade.

  • The Web Browser widget isn't honoring hidding via states. Also try to make it a little better about hiding initially based on state, by delaying the showing of the browser to the last minute, so that the initial field scan may have time to get the state correctly set.

  • The recent changes to optimize field definition access in the Intf Designer lost the ability of the widgets to pass judgement on fields, so as to limit the options in the Fields tab to only those fields that are actually useable by the Widget. So get that added back.

  • Add current precipitation and UV fields to the Weather Underground driver. The precip is inches or metric depending on the mode the driver is installed in.

  • The JRRiver repo can fail if more than one track in an album has the same track number, or of course if two albums with the same name exist. Deal with albums of the same name and the track number issue.

  • Add a binary 'state' field for the VRCOP dimmer units, in addition to the dimmer level field. This will make them useable via the auto-generation system, which currently only supports light on/off. And just make it generally easy to do simple on/off commands on them.

  • If the installer fails to run due to lack of Admin rights, have the popup explain what to do to fix that.
Dean Roddey
Explorans limites defectum
Reply
#8
Version 4.2.14 is posted. It just fixes a couple issues that were introduced in .13 with all the media changes. And it adds a driver for basic control of iTunes as a player, which also works through the Tray Monitor.
  • Recent changes to the media stuff required that we start setting a unique id on media items (tracks.) The update to the File Tag repo to deal with that was using the track number as part of the unique id, but it would break if two tracks had the same track number in their metadata, because the value wouldn't be unique.

  • The new iTunes repo isn't protecting itself against multiple images coming out with the same id, so we get a dumplicate id error and the load can't continue. Actually it was protecting itself, but the standard reaction is to bring the already running instance forward, but that won't work with a tray app.

  • Add a driver for controlling the player aspects of iTunes. It will also work through the Tray Monitor, since that's what is in contact with iTunes. So you'll need the Tray Monitor running if using either the Repo or player control drivers for iTunes.



Version 4.2.15 is posted. Just a couple updates to the iTunes player driver and some improvements with the new Lock Status event trigger to make it more useful.
  • A few fixes for the new iTunes player control driver. The Volume field didn't have a range limit, so it wasn't showing up for sliders. Add Visual On/Off commands. Full screen commands aren't working.

  • Add a new SelTrackByCookie command to the iTunes player driver. You write an item cookie to it, and it will pass it on to the Tray Monitor, which will look up that track in iTunes and start playing it.

  • Protect ourselves even more against duplicate cover art paths.

  • Update the new lock status event triggers to include a 'type' value, which indicates whether it was caused by a keypad action, a manual operation, a remote access operation, or some other type of operation. This will allow the handler of these triggers to decide now to interpret the status change, and whether the code value is of interest.

  • Provide a new GetLockStatusInfo() command on the TrigEvent action command target, to make it easy to grab out the info from a lock status trigger within an event handler. It takes four variable names, which are filled in with the state (locked/unlocked), ID (name of the lock involved), code (if any is available), and type (remote,pad,manual, or other.) If pad, then the code (if available from the device) indicates the user code entered.



Version 4.2.16 adds some new features to the iTunes player control (by way of Tray Monitor) driver. It fixes an issue with setting scheduled event schedules via the action interface.
  • Add a new panel to the installer. It will check to see if any GUI apps appear to be running and show a list of them. It provides a button to try to force them down if the user wants to do that, or just asks them to stop them manually if they want. It can't deal with every possibility, but should handle 95% of possible cases. It's also possible it might not be able to stop an app. But it'll come back and show them that some things appear to still be up after it attempts its shutdown pass, so that they can investigate those.

  • Add the usual PBPercent field to the new iTunes player control driver to provide support for playback progress widgets.

  • Add support to the new iTunes stuff to start playing a playlist by title cookie. So you send the title cookie of a playlist (not a regular title but a playlist) to the SelPLByCookie field and it will start that playlist playing on the 1st track.

  • Add Fast Forward/Rewind values to the iTunes player control driver's Command field. Update the control logic in the tray program so that, if the player is currently in FF/Rew mode, then Play does a Resume command, else it does a Play command, so that it acts reasonably in either case. Play won't stop FF/Rewind mode, you have to do a Resume.

  • When setting a scheduled event schedule via the action interface, the start time isn't being adjusted to the hour/minute set in the scheduled before calculating the next time. So it's coming out relative to the current hour/minute, not the scheduled hour/minute.

  • Add support in both the Elk and Omni drivers for a standard, generic area arm/disarm command, so that the auto-generation stuff can get rid of a lot of fiddly code and be updated to use these generic commands. Another wee step towards some standardization. The old commands are there, so it won't break existing systems, but it provides a generic way forward. Update the auto-generation system to use this new generic command.

    Note that this means you have to be using the official Elk driver in order for the auto-gen stuff to work now.
Dean Roddey
Explorans limites defectum
Reply
#9
(Reserved 5)
Dean Roddey
Explorans limites defectum
Reply
#10
(Reserved 6)
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Omni arming mode user info dlmorgan999 2 152 05-02-2019, 04:42 PM
Last Post: dlmorgan999
  Driver info/stats rbroders 6 1,476 09-02-2018, 08:34 PM
Last Post: Dean Roddey
  5.2.0 follow up releases Dean Roddey 25 8,224 01-30-2018, 01:52 PM
Last Post: Dean Roddey
  5.1.0 followup releases Dean Roddey 47 19,011 07-17-2017, 11:38 AM
Last Post: Dean Roddey
  Problem with editing auto generation info ghurty 9 2,356 01-08-2015, 12:16 PM
Last Post: Dean Roddey
  A 4.3 followup release candidate Dean Roddey 11 4,203 06-02-2013, 07:24 PM
Last Post: Dean Roddey
  M1 alarm triggered info znelbok 36 5,525 03-31-2013, 07:46 PM
Last Post: rbroders
  Weather info MSDW 4 1,427 08-17-2009, 06:16 PM
Last Post: MavRic
  Get Event Schedule Info eded9698 0 1,161 04-28-2009, 11:16 AM
Last Post: eded9698
  Where does CQC store setup info? anogee 2 1,361 09-07-2008, 02:26 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)