Official 4.0 Beta Discussion Thread

[Dean Roddey]

This is the old discussion thread for the 4.0 beta development process. It is now closed and just left around for future reference if needed. A new thread will be started for the 4.1 beta process.

[Dean Roddey]

So, I'll just start off by saying that the biggest thing by far in the 3.5 release will be ease of use, and hopefully to get to the point where anyone can set up a CQC system fairly easily. After going around and around in my brain about a thousand times, I think I've settled on a strategy to take, though of course once I dig in I can't promise I won't change it again based on what I find.

My high level scheme is something along these lines:

Driver Standardization

This just has to happen. It'll be a little painful, but no way out of it. Obviously this cannot involve just tossing all the existing drivers, so there will have to be a co-existence of old and new type drivers for a while until they all can be updated. The old ones just won't be able to participate in the new super-magical stuff.

This will involve coming up with standard sets of field names, and strict definitions of what those fields mean, what values they can have, and how the drivers should react to them. This won't be on a driver basis but a 'device class' basis, and some drivers will implement more than one of them. The manifest file will indicate what classes the driver implements and what versions of those classes. The driver IDE, knowing all these device classes, will be able to verify that any given driver meets at least the syntatical requirements of the classes claimed.

Since we'll have to have coexistence, I think it'll be common to add a driver prompt that indicates whether a driver can run in old or new mode. Since most drivers just create, register, and then look up their fields, the impact of this will be somewhat less than it would otherwise be. The fact that the field is called this instead of that will only impact the driver at the point of creating the fields.

In some cases, maybe just a new driver is started, but this could get even messier and inevitably fixes may need to end being made in two places, etc... So it may be better where it's not going to introduce undue complexity to try to go the dual mode route. Or, in other cases, the driver may choose to just maintain both sets of fields if they have little in common, but that should be rare. Any given device class is going to expose the obvious stuff that any driver of that class is likely to support. So it's mostly generally going to be a renaming of fields, and some stuff like 0 to 100% for volumes and dimmers and such instead of a device specific value.

Anyway, obviously there'll be a period there where it will inevitably be a bit more complicated, but we will eventually just say, look we are going to split off the drivers at this point, and the old ones will receive nothing but bug fixes from here on out, and eventually we'll just deprecate them completely. For drivers that are really stable and not likely to change at all, maybe just creating a new one for the new world is the better thing to do. But it'll be kind of case by case.

It may be that case that the commands that a driver can react to in this new scheme are moved more to a standard backdoor command instead of being so much field based, so that they can be standardized. And, since they are standardized, full prompted configuration of them will be possible, even more so than the field based stuff today.


Auto-Discovery

A new method will be added to the driver interface, called something like TestProbe(), which will basically do a quick check on the passed serial port or IP end point (or other type of connection if that's what they use) to see if the device they support is on the other side. So they'll open the port, do some basic testing, then close it back down again and return a result.

This will be used in a new configuration tool to assist the user in finding devices. So it'll be able to ask them, do you have a light system? Can you pick it from this list, can you tell me what serial port it's on? No, ok, I'll test them. Same with IP ports, of which of course there can only be 256 on a class C address of the type that will be used in a home network.

This will vastly reduce the complexity of setting up a system, even for more advanced users really.


Installer

The installer will be vastly improved and made far less technical, so that it asks functionality based questions instead of process based questions. It'll be things like, do you want to be able to manage your CQC system from this machine? Do you want to be able to control devices attached to this machine? Do you want to be able to run touch screen interfaces from this machine? Stuff like that, which don't depend on knowlege of how CQC is internally divided into functional units.


Super Configurator

Using all of the above stuff, a super configurator, or maybe system builder is the better term will be provided that will ask you some questions about how your home is laid out in terms of rooms, ask you what devices are in what rooms, and some other stuff like would you like to turn any things on or off at sunrise or sunset, etc... If you have audio or video switchers it'll ask you what outputs go to what rooms and what devices are connected to what inputs.

Then it will just generate a complete system for you, probably allowing you to pick between a few styles (though the layout will likely be the same with just the colors and graphics changing.) At that point, you can make modifications directly, but they will be overwritten if you run the builder thingie again. So you either stick with making changes in the builder and regenerating, or you generate it and then modify.

Either would be a viable scenario depending on what you want to achieve. For the non-technical users, just generating a system and using it will be fine. For the technical DIYer, it's a good way to get a head start, and then modify from there. For the integrator it's a way to generate new customer systems based on standard configurations (since the info you provide to the configurator can be stored and recalled.) They may then make customizations, but it'll vastly simplify their work to support a number of system variations, and to spit out new ad hoc variations as well.

There may be some capability to customize stuff in the configurator itself to some degree. But this will never become a substitute for a talented interface designer doing something completely customized. It can never match that. The point of it is to be able to create good systems quick, not to create ultimate systems. So it's only going to support the core stuff, lighting, multi-zone audio, security, HVAC, and weather, at least initially until enough feedback is gotten from users as to how we can take it further. And hence mostly only these drivers would need to initially make the transition to the new driver scheme mentioned above, with others doing so over time (though there will be other advantages to even advanced uses working through these new style drivers as well, for reasons of easy swapping of devices, so it would be good to have others moved forward as well, even if not needed by this builder thingie.)

One way it might offer customization is to generate some of the commands such that they really just invoke global actions, into which some standard functionality will be automatically generated. But then you can modify them to do other things. So they'd be stuff like LightsOnOff or something like that, and would receive the room indentifier and the on/off indicator. So you could choose to do other things when the user turns the lights off or on in the room. These I guess could remain unchanged during a regeneration of the system, with only new ones being created if needed.

One advantage is that, since they are just generated, there's no need to be super-fancy with them. So they don't need huge amounts of flexibility internally as a highly dynamically reusable type system would need. The generated stuff can be just straight to the point, and fairly easy to understand.

Another reason for doing it this way, instead of the specialized client we initially considered, is that it both offers benefits for everyone, and it means that these generated interfaces are prime targets for integrators to upsell the customer on customizations. They will be built using all the existing stuff, i.e. they'll be real IV interfaces, real scheduled events, and so forth. So it would just be a matter of picking up where the configuration tool left off and taking manual advantage of all of the power available, which the auto generator really can't.

[Dean Roddey]

General Tools Changes (too many characters for one post)

Assuming my brain is not fried by the above, and there's time left, some much desired general tool changes will also be implemented. Some of these can come towards the end while the big stuff above is being digested by everyone. Not all of these will get done. Even just getting the above done will be somewhat ambitious. But, where these can be done, they'll be done, else they'll be pushed to the next release.


Drag and drop of images into the image repository
Possibly converting to an Expression Blend style attribute bar interface in the interface editor, so that the tabs are all stacked up on the right instead of in a dialog box.
Beginning to get some context smarts in the CML editor, maybe starting with some assisted parameter prompting stuff and whatnot.
Logging tools improvements
I'd love to, as a first step towards tools integration, consolidate the remote data browsing interfaces to create a single hierarchy of macros, images, global actions, and interfaces, so that they can all be browsed from the Admin Interface and then the correct editor invoked from there (with the longer term goal of moving those editors into the Admin Intf as well.) Also, the abiltiy to create a new package creator where you just drag stuff from the hierchical view into a packager window to create them.
A simple but effective one would be to get rid of stuff like System::Equals in the action editor. They'd still actuall be there, but would be hidden and the actual display would be (x == y) and so forth. It would purely be a visual change, not a painful change in the actual action system. But it would make a lot of difference in terms of usability of the editor probably.



To Summarize

So anyway, there it is. It's pretty ambitious, but I'm going to once and for all get past this 'only geeks can understand it' thing, and do so without sacrificing any of the power that's available. If we can get it to the point where a reasonably intelligent person can answer some questions and get a system up with a pretty graphical interface first time out, in half a day or something, then I think that will be a massive step towards actually getting some sales. And not just in the DIY world. This is heavily required for integrators as well.

In subsequent releases we'll have to then drop down to the more detailed issues of usability. And I know some of you will be unhappy that all this time is being spent on something other than that. But this is really necessary to be successful. And I think that there will be so many benefits in terms of being able to swap out devices without change, and the huge benefits for being able to reuse your own or other people's interfaces.

[froop]

Dean,
If you can get half of what you've mentioned so far, I'm already loving it.

[SamVimes2]

All of those things sound great!

[personalt]

If you can't get microsoft tts working in windows 7, support for a third party tts api

[dirtracinfan]

I can't wait ,Ive almost given up on making CQC work for me.I have always got part to work but could never get the whole system figured out.Hopefully this will be so easy a caveman could do it.:-)

[beelzerob]

Sounds wonderful dean!

With the simplefldclient, is there no way to test that a driver is online? Do you just have to catch the exception and assume that means its offline?

[Dean Roddey]

If you are going to be reading fields anyway, then just catching the exception is best. If you explicitly just want to test one, yo could do a WaitDriverReady() call with a short timeout. Though that's not something to do for a really fast test, since it may wait a little longer than you indicate.

[anogee]

This would be great, and I agree, TTS in Windows 7 needs to be done. If it has to be done in a foreground app., then that would be fine, and could even be considered a great feature.

And while you are doing this :-D a way to start and pause the TTS queue would be fantastic. I use an audio switcher so I can change which speakers a message comes out of. If I could pause, switch, then speak, pause, switch, and speak and keep it all in-sync, I'd be so happy.

[George M]

TTS is the reason I have not converted my last computer to Win7. Master Server is still running on XP for that reason only.

[anogee]

TTS is the reason I have not converted my last computer to Win7. Master Server is still running on XP for that reason only.

Same here.

[robolo]

I think your on the right track.

[beelzerob]

Website: Dean, there's no clear way to get to the supported devices list from the front page (you actually have to go through "CML Runtime" to get there. Most new people won't figure that out.

Also, I don't see the Brultech driver listed anywhere...I assume the category would be Miscellaneous, and it's not there.

[Dean Roddey]

Right now all of them just bring up the little offline web site. That'll go away at some point. For now it's good enough. Hopefully they'll see the links to the other stuff. But since it's the old frame based stuff, there's no way to go a particular page.

On the Brultech, it doesn't seem to be there, and it's not in my directory of driver docs I need to do. So, if you sent me the docs, it must have gotten lost in the shuffle. Can you send it to me again? And I don't see it in the official list o' drivers in the release either. So maybe I just completely failed to get it processed altogether. If you can send it to me again, I'll get it in the 3.4.2 release here in a day or so probably.

[beelzerob]

Well, I don't mean the PAGE it brings up...I just mean there's not even a link on the main page that would indicate to anyone "click on me if you want to see the supported devices". Newbies aren't going to care about CML docs...only veterans. So, if given a choice, I'd think it'd be better to have the link be "Supported Devices" that opens up the other web page, and us CML junkies will know to go there to get our fix. Better to confuse us veterans than a new visitor.

[Dean Roddey]

Oh, sorry. I was originally going to move the devides stuff into the main web site, then bailed due to time constraints and failed to add a link for that. I'll do that.

[Dean Roddey]

I've put up a 3.4.2. This isn't a beta, just some fixes which, if no one has any issues with it, I'll make the new formal release version. The changes are:


The bulk loader is checking image paths for Alpha, instead of AlphaNum, so image names with numbers will get rejected.
The installer code that generates the command file to set up the CQC Command Prompt is setting the system id after another line that actually uses it. This causes some command line utilities to croak.
Increasing the scaling of the system font causes calculation underflow problems in the scroll bar control when they create scroll bars initially zero sized.
Add the Precon Humidity Sensor driver to the system.
Add the Yamaha Aventage A-1000 driver.
There's an error in the XML parser where if you get an anchor for the root note, it will fail because the anchor is not being set up correctly in that case. This will cause an unknown exception at the CML level.
The bulk loader fails if there's not at least one blank line at the end of the configuration file.


You can get it at:

http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_2.Zip

[fcwilt]

Suggestion:

Server pushes client configuration information to client.

Installed client is sort of a "boot loader" which expects information from server which the client uses to "construct" the screens to display.

The server can push different configurations based on the host name of the client (or some other naming scheme).

Server can publish a web page where the client can be downloaded and installed.

I know this is a bare bones description but this approach makes updating clients a simple matter of creating/editing the client screens, which are stored on the server and then they are pushed to each client the next time that client connects. No need to go to client locations to install anything once the basic client is in place.

[Fonceur]

Increasing the scaling of the system font causes calculation underflow problems in the scroll bar control when they create scroll bars initially zero sized.
I can confirm that this fixed the issue for the Driver editor.

Not sure if it's a side effect, but the installer had no OK/next button, so I couldn't install with a mouse. Good thing that I could just press ENTER on the keyboard to proceed, talk about blind faith... ;)

[Dean Roddey]

That may be another side effect. I'll look at that also. Oh, the tangled webs we weave when we program for GUIs.

[Dean Roddey]

Well it turns out there's a subtle bug in the socket stuff in 3.4.x. It was one of those things where there was a subtle bug to start with, which was fixed. But then it turned out that a couple other places had unknowingly compensated for this bug, which then broke them when the bug was fixed. Sigh... So a server can go down and the client might not recognize this fact and still think it's connected, so it won't try to reconnect.

Obviously this is not good. As a rule it would mostly likely only affect IP based drivers that don't poll their devices, i.e. they depend on async notifications. If the client sends something that expects a response, it'll obviously figure out the other guy isn't there. But if he doesn't, he won't notice during reads that the other side has gone away.

I put up a 3.4.3 for someone who was experiencing the problem to try it out. If that works, I'll post it for others to install. I'll probably need to heavily recommend that folks upgrade to this version. Sorry about that. Believe me, I hate it more than you since it's a lot of work for me to have to do these follow up releases for small amounts of fixes. Somehow these things manage to never get caught until after the big release is done, no matter how many people are using the betas.

[Dean Roddey]

OK, 3.4.3 is available now. I'd recommend upgrading to this one because of the issue discussed in the previous post. The changes since 3.4.2 are:


There's an issue in the socket class, which won't catch a disconnected socket correctly in all cases, so things can get stuck thinking they are still connected when they are not. This is a subtle but possibly evil bug that could cause non-obvious system problems. So probably everyone is going to need to upgrade to this one, sigh...
The new control panel button for the logic server doesn't work.


You can download it for now here, I'll make it the formal release after some folks have verified it's happy.

http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_3.Zip

[Dean Roddey]

OK, well I went back and really dug into the whole socket thing. There have been a number of things that maybe could have been related to corner cases in the socket processing, etc... It's come up in the HTTP client stuff, and in a few other places.

So I just wanted to really readdress it and make sure it was right. So here's another drop, which I think should be very solid on the networking front and take care of those types of cases. It should also be a bit quicker on noticing lost connections, and a bit more robust in general wrt to networking stuff.

Anyone want to give this guy a try and let me know how it works? I'd like to get it out there as the official release if possible.

http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_4.Zip

The changes are:


Deal conclusively with the issue of socket disconnection detection and get that stuff straightened out and robustified fully.
The CML level socket SetLinger method takes millis, but the underlying method takes seconds. Currently the millis are just being passed in, for a lot of seconds. It should be converting to seconds.
Correct the max volume of the Yamaha A-1000 driver's volume field range.


I beat on it hard, but of course there may always be some something off the the normal path that I might have upset, but I don't think that should be the case. If so, I can fix it quickly, but overall these changes will be worth it in the long run, so it would be nice to get some feedback on it so that I can get it out there as the status quo.

[batwater]

Dean I am getting the following error when I exit taRIVA (OTA) or iRIVA (WiFi), don't recall getting this before...

{
CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
An exception occured in the service loop of worker thread 8
}
11/30 11:44:44-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr16
{
CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
An exception occured in the service loop of worker thread 15
}
11/30 11:45:04-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr16
{
CIDSock, CIDSock_StreamSocket.cpp.663, Failed/Lost Connection, Error: 5017/1021/10053
The connect was aborted by the other side
Connection aborted
}
11/30 11:46:01-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr9
{
CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
An exception occured in the service loop of worker thread 8
}
11/30 11:49:16-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr16
{
CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
An exception occured in the service loop of worker thread 15
}
11/30 11:49:42-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr11
{
CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
An exception occured in the service loop of worker thread 10
}
11/30 11:50:00-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr11
{
CIDSock, CIDSock_StreamSocket.cpp.663, Failed/Lost Connection, Error: 5017/1021/10053
The connect was aborted by the other side
Connection aborted
}
11/30 11:50:26-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr9
{
CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
An exception occured in the service loop of worker thread 8
}

Same error for both clients. Also note the aborted message, this occurs with the taRIVA client but not at time of application exit. Since OTA, most likely it is a reconnect due to a lost handshake packet or something of the sort.

-Ben

[Dean Roddey]

What version are you running? Is it the new version I just posted above?

[batwater]

What version are you running? Is it the new version I just posted above?

Hi Dean, sorry, it's 3.4.4
-Ben

[Dean Roddey]

OK. It may just be that the RIVA client isn't doing a graceful shutdown, but just closing the socket. That might not have actually been reported before and now it is. It's not going to hurt anything, but probably it would go away if the RIVA client did a graceful shutdown (where you read any outstanding data, then disconnect, then close, the standard thing.) On a graceful shutdown it would likely get the standard disconnected error on my side, which I specifically don't log because it's expected. Since it's getting the aborted, it's getting logged. I could do the same for that error, but it's probably best to keep it there until we see if it's really caused by a non-graceful shutdown, or just ending the program perhaps without shutting down the socket.

[batwater]

OK. It may just be that the RIVA client isn't doing a graceful shutdown, but just closing the socket. That might not have actually been reported before and now it is. It's not going to hurt anything, but probably it would go away if the RIVA client did a graceful shutdown (where you read any outstanding data, then disconnect, then close, the standard thing.) On a graceful shutdown it would likely get the standard disconnected error on my side, which I specifically don't log because it's expected. Since it's getting the aborted, it's getting logged. I could do the same for that error, but it's probably best to keep it there until we see if it's really caused by a non-graceful shutdown, or just ending the program perhaps without shutting down the socket.

Okay, well, both Apple IOS and Android clients are doing the same thing...

[Fonceur]

Deal conclusively with the issue of socket disconnection detection and get that stuff straightened out and robustified fully.
Currently, the SageTV drivers figure that the connection was lost when they don't receive data (i.e. ping) for a certain amount of time, but do you mean that there is the equivalent of a OnDisconnect() available somewhere for third party drivers?

[Dean Roddey]

There's not an ondisconnect thing, but it was just that it wasn't obvious that the connection was lost and some drivers could get freaked out by that. And there were some other places where potentially a list little bit of data might get lost because of the fact that the socket really is 'disconnected' before all of the data is read in in a lot of cases. This stuff tightens up the handling of that, which is more an issue in cases where you connect, do something, then disconnect. That would be HTTP stuff, any devices that are not continuous connections, stuff like the RIVA image thread potentially, etc...

Anyway, it's just tighter in general I think should be more robust.

[bryanb]

Dean,
Would this fix the exception that we're getting about a missing colon in the new ethernet directv driver?

Thanks,
Bryan

[Dean Roddey]

Possibly. I recommended that he try it and see what happens.

[Dean Roddey]

OK, so the first step towards the 'Grand Unification Theory' system has been taken. It's a small but important step. A new set of 'semantic events' has been added to the system in addition to the current user action and field change events. These are for zone alarm changes, motion changes, and load changes.

There are a number of reasons for these to be added. Some I'm sure I've not forseen myself, but the ones I think are important are:


It means a lot less requirement to set up field triggers for common stuff that you'd want to react to. These will be sent out any time these things change. So, it comes at the cost of some extra overhead, since now any load or motion or zone status changes will be broadcast out. But these aren't things that will change really rapidly all the time.
It means it'll be easier to set up triggered events that react to these types of things in a way that's independent of device monikers. You don't have to know ahead of time what fields represent motion or zone status or loads. The fact that you got one of these events will be all you need to know. The field is the source, so you'll get the field in the event and can just use the field without having to know what it belongs to. The type of fields that send these events are defined, so you'll know how to interact with it.
They will be used in the uber-configuration tool that will be coming up. One of the things it will do, to help people who maybe didn't install the hardware is to say, OK, we are setting up the lights in the room named 'Living Room'. Toggle one of the lights in this room off and on (or on and off.) It'll see the event and know which light is being referred to. Same with motion detectors and zone sensors. So it will support a kind of live physical interaction mode of configuring what hardware is in what rooms.


I'm definitely in this release going to try to keep the docs updated (in an offline beta sort of way) as I go, because the changes will be significant and I don't want to do a binge at the end or have to explain these changes over and over again. And driver writers will need to address them as well of course, so they need to be well documented.

I haven't gotten the external content HTML (cml ref, drivers, etc...) docs section up yet for 3.5, but the event system reference is here and it explains these changes.

Event System Reference 3.5 (http://www.charmedquark.com/Web2/Downloads/Documents/3_5/EventSysReference_3_5.pdf)

I'll probably not update the non-external type content parts of the web sites for beta purposes, since they don't contain anything that would change anymore, other than the links to the technical docs and videos. So I'll probably just update the first post of this thread to contain links to the new technical docs and a link to the beta external type content when I get it up there.


Obviously drivers will have to be updated before these new events will be of use. The drivers have to send out these events as appropriate. I'm not sure if the drivers themselves will do it, or if the driver base class will do it for them. The latter could be done because fields are going to be marked semantically in the new scheme, as what type of field they are. So the driver base class could now when a motion sensor changes or a load changes. That's probably the better way to do it. The driver could always handle some special cases itself if required. The methods are there to send these events if they need to.

Fields won't have to be marked to keep working. So ever driver won't have to be updated. But those that are going to be compatible with the new scheme (and support these new events if the above is true), will need to be marked appropriate (and comform to the definition of that kind of field as well, since these semantic field types will be strictly defined and that's a huge part of making the new scheme so much more flexible.)


Anyway, comments on these changes as documented in the triggered event sections of the event sys ref are welcome. Best to catch problems now than later when they are being implemented in drivers. Some others could be added if there's big bang for the buck, but we don't want to get crazy. I purposefully didn't add anything like a 'system health' type event yet, because handling that coherently will require some heavy thought.

[beelzerob]

Even System Reference 3.5 (http://www.charmedquark.com/Web2/Downloads/Documents/3_5/EventSysReference_3_5.pdf)


Is there an Odd one coming out later? :tounge

[wuench]

In your uber setup tool, make sure you make it tolerant of multiple events happening at the same time or in very quick succession, maybe a message saying I got multiple replies, pick one. By that I mean, in your example of automatically figuring out which motion detector went of, two could go off at the same time. I have places in my house where I can dance a jig and set off more than one motion detector due to the open floor plan (and maybe poor placement :-) )

[Dean Roddey]

Yeh, the motion detectors in general will be more difficult for the configuration tool, also because by the time you get into the room it's already gone off. So it'll probably just keep track of the last few that have gone off and let you select. Or, if the device has a trigger button which some might, to allow you to press the trigger.

[Dean Roddey]

Is there an Odd one coming out later? :tounge

Some people would probably argue it's always been odd.

[pseigler]

i didn't see the doc for the XML Gateway in the Technical Doc section --- i may have overlooked it. i have a number of custom applications using the gateway to do things that would otherwise not be possible, even with RIVA.

Are there going to be any changes to the gateway...i know i'd like to see the ability to push multiple field values at once, maybe get a list of images in a similar way i can get a template and global action list now... :-D

[Dean Roddey]

You mean on the current web site it's not there? If so, I just have just missed it and I'll need to get it up there. Sorry. It's probably still there on the HTML site I'd imagine. Oops, I guess I did fail to get it into the new web site. I'll add it.

Anyway, yeh, it's still there and we can probably get a few improvements into it for the 3.5 release.

[Dean Roddey]

Version 3.4.5 is posted. This is not a beta yet. I don't think we've gotten into anything dangerous enough to require that, so I'm putting it up as a new release candidate after folks have beaten on it a bit. It does include some new stuff related to the big picture changes in the next release (the details of which are discussed four or five posts before this one.) But it also provides some fixes for other things that some folks will want to get as well.

The changes are:


The Aprilaire driver has some bugs related to the polling of sensors. If there are sensors on anything beyond the first thermo, you can get errors because of some index problems causing it to look at the wrong fields.
Add some more verbose mode logging to the RIVA server to help RIVA client developers with problem diagnosis during development and in the field.
The CQSL repo, when you create a new repository, should create fairly extensive initial default category lists for music and movies, so that folks don't have to create any generally. These will also be part of future functionality so we will need to figure out how to get them into existing repositories as well.
The RIVA server should do a mouse move event, at the press/release position, when the RIVA clients send press/release events, to emulate how Windows operates. This seems to be depended on somewhere down in the guts of the interface engine. Otherwise, initial press events on buttons and such seem to immediately think that the mouse is outside of the target widget and send the wrong image in the redraw.
The first moves towards the Grand Unification Theory system. Add some new system event types. These are LoadChange, Motion, and ZoneAlarm. These will be sent out by drivers that support lighting, motion sensors, and security zones, respectively. They will be generally useful, and will (at the cost of some extra network traffic) prevent the need for a lot of setting up of field triggers for common functionality. But mostly they are intended to support some nice new standard functionality comng up. Add new filter types for these events, with some pretty specific ones to avoid bogus triggers on these now more often being sent out events.
Duh! The XML GW is not escaping the values of fields as it formats out the XML, so if the field value has some reserved attribute character like a quote, the poll will fail. This is on the server side. Go through the client side XML GW support library and just do some more escaping in general as well for outgoing messages to the server, though they aren't required now, it'll be insurance against possibly changes in the future.
The CQSL WMP player wrapper that underlies the CQSL audio player in DirectShow mode isn't managing its end of media flag correctly. If a file fails to load, the end of media flag is not set, so the CQSL audio player doesn't think it needs to move to the next playlist item. It's also the case that some exceptions are not caught during the attempt to start up a new file, so that can cause the player to cycle and that will flush the playlist. So you'd lose either way. It should now just move to the next item in the playlist.
The triggered event filter editing dialog should add the extra value insertion helper menu entries on both the field and the comparison value entry fields, since sometimes you need these values in both.


You can down it here for now. Once it's been abused a while, I'll make it the formal 3.4 release version.

CQC 3.4.5 (http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_5.Zip)


There is a small chance that I whacked something in a subtle way wrt to the filtering of triggered events, but I don't think so. I tested themout pretty well, and there are a fair number of automated tests for the filters and none of them got broken. But it is the case that more validation and sanity checking was added, so it's possible that perhaps something that slipped by before wil now get caught. But, though that might be a little annoying, it'll be for the best in the long run. Mostly likely though you won't notice anything changed.

Do keep in mind that nothing is sending the new events yet. So don't bother trying to use them for the time being. This just added support for them, so that drivers can start sending them before too much longer.

[pseigler]

You mean on the current web site it's not there?

correct, on the web site...i'm really looking forward to having more utility-type access to CQC via the xml gateway. thanks dean

[potts.mike]

Version 3.4.5 is posted. This is not a beta yet. I don't think we've gotten into anything dangerous enough to require that, so I'm putting it up as a new release candidate after folks have beaten on it a bit. It does include some new stuff related to the big picture changes in the next release (the details of which are discussed four or five posts before this one.) But it also provides some fixes for other things that some folks will want to get as well.

The changes are:


The Aprilaire driver has some bugs related to the polling of sensors. If there are sensors on anything beyond the first thermo, you can get errors because of some index problems causing it to look at the wrong fields.
Add some more verbose mode logging to the RIVA server to help RIVA client developers with problem diagnosis during development and in the field.
The CQSL repo, when you create a new repository, should create fairly extensive initial default category lists for music and movies, so that folks don't have to create any generally. These will also be part of future functionality so we will need to figure out how to get them into existing repositories as well.
The RIVA server should do a mouse move event, at the press/release position, when the RIVA clients send press/release events, to emulate how Windows operates. This seems to be depended on somewhere down in the guts of the interface engine. Otherwise, initial press events on buttons and such seem to immediately think that the mouse is outside of the target widget and send the wrong image in the redraw.
The first moves towards the Grand Unification Theory system. Add some new system event types. These are LoadChange, Motion, and ZoneAlarm. These will be sent out by drivers that support lighting, motion sensors, and security zones, respectively. They will be generally useful, and will (at the cost of some extra network traffic) prevent the need for a lot of setting up of field triggers for common functionality. But mostly they are intended to support some nice new standard functionality comng up. Add new filter types for these events, with some pretty specific ones to avoid bogus triggers on these now more often being sent out events.
Duh! The XML GW is not escaping the values of fields as it formats out the XML, so if the field value has some reserved attribute character like a quote, the poll will fail. This is on the server side. Go through the client side XML GW support library and just do some more escaping in general as well for outgoing messages to the server, though they aren't required now, it'll be insurance against possibly changes in the future.
The CQSL WMP player wrapper that underlies the CQSL audio player in DirectShow mode isn't managing its end of media flag correctly. If a file fails to load, the end of media flag is not set, so the CQSL audio player doesn't think it needs to move to the next playlist item. It's also the case that some exceptions are not caught during the attempt to start up a new file, so that can cause the player to cycle and that will flush the playlist. So you'd lose either way. It should now just move to the next item in the playlist.
The triggered event filter editing dialog should add the extra value insertion helper menu entries on both the field and the comparison value entry fields, since sometimes you need these values in both.


You can down it here for now. Once it's been abused a while, I'll make it the formal 3.4 release version.

CQC 3.4.5 (http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_5.Zip)


There is a small chance that I whacked something in a subtle way wrt to the filtering of triggered events, but I don't think so. I tested themout pretty well, and there are a fair number of automated tests for the filters and none of them got broken. But it is the case that more validation and sanity checking was added, so it's possible that perhaps something that slipped by before wil now get caught. But, though that might be a little annoying, it'll be for the best in the long run. Mostly likely though you won't notice anything changed.

Do keep in mind that nothing is sending the new events yet. So don't bother trying to use them for the time being. This just added support for them, so that drivers can start sending them before too much longer.

I installed this version and its asking me to register again, is that to be expected?

[LesAuber]

Are these breaking changes to drivers that don't need this type of instant feedback? Audio equipment drivers for instance.

[Dean Roddey]

I installed this version and its asking me to register again, is that to be expected?

If you came from 3.3 or earlier it would be normal. Any move beyond a revision requires you to get a new license, because often the licensing will change and it also helps us keep up with who is using what versions and so forth.

[Dean Roddey]

Are these breaking changes to drivers that don't need this type of instant feedback? Audio equipment drivers for instance.

There's no breaking changes involved. Just the addition of new features for those drivers that will be able to be part of the new world to come.

There will come a point here soon where each driver will either have to be left in the current world (which will still work it just won't be able to participate in the new stuff), or perhaps an existing version left in the current scheme and a new one started for the new scheme, or to provide the ability to run either way based on a driver prompt. This will be related to the standardization of the names/semantics of fields for each class of device.

But, still, existing drivers that aren't updated will continue to work just fine. And existing drivers that are moved forward will either have to leave a version as is for existing customers, or support both modes (with the old mode being the deafult for existing customers.)

[Dean Roddey]

And a version 3.4.6 is posted, which fixes a few more issues and adds one feature Paul wanted. So this would likely be the next formal release version.

http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_6.Zip

I'm tellin' ya, one stupid decision in the socket stuff years ago and I'm paying for it now. I fixed the problem, and then all of the places working around the problem (without knowing it was a problem) are now coming back to haunt me. But I think that this one should be solid on the socket front. We'll see if it fixes the known issues out there now.

Note that it does tighten up one thing about CML strings, which might have slipped into some drivers and such and they just happened to get away with it not causing a bad error, and now they'll get an exception if so. Probably not since it most likely would have caused an error anyway (C++ level), but it could happen.

The changes are:


The CML string class isn't appropriately catching attempts to pass the string being operated on as the output of the method being called. This is never legal. It can cause C++ exceptions to leak through. So it should check those scenarios and throw an appropriate CML level exception.

Add a multi-write capability to the XML GW server. The element is CQCGW:MWriteField, and it just contains one or more CQCGW:WriteField elements (i.e. the same one you'd use for a single write.) Don't abuse it and send large numbers of fields. Keep it reasonable. The C++ and CML GW client classes were updated to support this new call as well.

Another small but important fix in the HTTP client and socket support that probably explains some issues folks have had where the response from the other side is a little delayed. It's setting the disconnect state too early in one case.

[pseigler]

Add a multi-write capability to the XML GW server. The element is CQCGW:MWriteField, and it just contains one or more CQCGW:WriteField elements (i.e. the same one you'd use for a single write.) Don't abuse it and send large numbers of fields. Keep it reasonable. The C++ and CML GW client classes were updated to support this new call as well.


yes! :-D thanks

[Dean Roddey]

Any folks using the 3.4.6 version? If it's happy, I'm going to doa 3.4.7 which has a fix for Z-Wave driver polling, and make that the new formal release version, and recommend everyone who is on 3.4.5 or before upgrade to 3.4.6 or 3.4.7 (if they need the Z-Wave fix.) And I think we finally have this socket silliness behind us. Actually though it was a good thing in the end, that problem could have accounted for various spurious things that wouldn't have happened often enough to really point a solid finger in a given direction. So it should increase the solidity of the product at the networking level.

[SamVimes2]

I'm on 3.4.6 and everything seems happy so far

[Dean Roddey]

Oops, the multi-write thing for the XML GW isn't exactly right. It's just calling the write field thing internally, but that guy sends an ack. So it's sending an ack for each field, which is bad. I'll fix that for the 3.4.7 release I'm going to put up here in a bit. Sorry.

[Dean Roddey]

OK, here is 3.4.7. If you are using the Z-Wave driver and are on 3.4.1 through 3.4.6, you'd want to upgrade to this one. Also, if you want to use the new multi-field write capability of the XMLGW server. Otherwise, if you are already on 3.4.6, you can stay there safely enough.

http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_7.Zip

The changes are:


In a fit of stupidity I broke the storage of incoming values for some of the unit types in the Z-Wave driver. So it polls but the values don't get stored.
The new multi-field write call on the XML GW server wasn't quite right. It was sending an ack for each field in the multi-field write, instead of one for the whole thing. This should fix that.


Assuming that these two issues are reported fixed, I'm going to make this the formal release version and I think it'll be safe now to start on some more intrusive big picture changes for the next version.

[jkish]

OK, here is 3.4.7. If you are using the Z-Wave driver and are on 3.4.1 through 3.4.6, you'd want to upgrade to this one. Also, if you want to use the new multi-field write capability of the XMLGW server. Otherwise, if you are already on 3.4.6, you can stay there safely enough.

http://www.charmedquark.com/Web2/Downloads/Installers/CQC_3_4_7.Zip

The changes are:


In a fit of stupidity I broke the storage of incoming values for some of the unit types in the Z-Wave driver. So it polls but the values don't get stored.
The new multi-field write call on the XML GW server wasn't quite right. It was sending an ack for each field in the multi-field write, instead of one for the whole thing. This should fix that.


Assuming that these two issues are reported fixed, I'm going to make this the formal release version and I think it'll be safe now to start on some more intrusive big picture changes for the next version.

Upgraded from 3.4.4 to 3.4.7 and now my NetCallerId driver isn't working correctly - the history fields do not populate properly anymore.

[Dean Roddey]

Upgraded from 3.4.4 to 3.4.7 and now my NetCallerId driver isn't working correctly - the history fields do not populate properly anymore.

Is it logging any errors? The only thing that changed in the meantime that would seem to be relevant would be the catching of invalid source/target string that it just happened to be getting by with before. But that would cause an exception and you'd think it would not work at all.

[znelbok]

Dean

Not sure if this is the right place but I don't want to create a new thread for it.

When there is an error in a popup, the IV, the popup cant be closed and the IV becomes totally unresponsive (alt+f4 works). This is not so bad on a PC, but on a touchscreen its not acceptable at all - with the screen needed to be re-booted to get out of the locked IV.

Should be an easy one to replicate, but if not let me know and I will work out a test page.

Mick

[jkish]

Is it logging any errors? The only thing that changed in the meantime that would seem to be relevant would be the catching of invalid source/target string that it just happened to be getting by with before. But that would cause an exception and you'd think it would not work at all.

I looked in the logs, but didn't see any errors due to that in there. However, I looked at the code briefly and there are try/catch's around a lot of the code that don't log anything in the catch.

This clearly has broken between those two releases and the change to the String handling is what I immediately thought of too.

Also, I had recently added an SNMP driver to my setup before I upgraded and there were a lot of unhandled exceptions from the driver base class that were showing up in the log every few seconds, but I don't know if those were there before or not.

[wuench]

The exception that was changed in 3.4.6 is very specific - The source and target string cannot be the same object. If the exceptions are being logged that is what you should look for. In the code look for any calls to string methods that use the same string as a parameter. For example:

strRawVal.ExtractUpTo(0,Char.kLF,strRawVal);


The SNMP driver should be logging any unknown exceptions, depending on the particular exception it may or may not be an issue. Due to the stateless nature of SNMP, it is designed to log the info and try to move on to the next object to poll versus reconnecting.

Edit: I just loaded a sample UPS SNMP file and haven't see the 3.4.6 exception, but let me know if you see any issues.

[jkish]

The exception that was changed in 3.4.6 is very specific - The source and target string cannot be the same object. If the exceptions are being logged that is what you should look for. In the code look for any calls to string methods that use the same string as a parameter. For example:

strRawVal.ExtractUpTo(0,Char.kLF,strRawVal);


The SNMP driver should be logging any unknown exceptions, depending on the particular exception it may or may not be an issue. Due to the stateless nature of SNMP, it is designed to log the info and try to move on to the next object to poll versus reconnecting.

I glanced at the code in the NetCallerId, but didn't have time to try to fish out the offending statements (if there).

The SNMP exceptions are being logged by the DriverBase class, not the driver itself. I'll post a log snippet once I get a chance. The device is an APC S20 UPS.

[Dean Roddey]

I don't have any means to run the caller id driver here in a realistic way, so you may have to bring it up in the IDE, enable exceptions at the the point of throw, and see where it's happening. I'm guessing it'll be a string operation of the source/target sort.

On the other one, the base driver generally only logs errors if they are exceptions that the CML driver isn't catching, so they make it back to the base driver.

[Dean Roddey]

On line 607 the NetCallerId driver does an extract substring from a string to the same string, so that's likely the issue. That might actually also be a logic bug, not just an invalid operation, but I'm not sure and I'm loath to try to modify a driver by eye when I'm not completely sure what it's doing. Can one of you guys who is using it take a look at that? It's probably a simple fix, it just needs to be verified in real use.

Actually, it's doing this:

CurTok.ExtractSubStr( 0, 3, CurTok);

If it's actually doing what it would seem the writer intended, that should effectively be the same as:


If (CurTok.GetLength() > 3)
CurTok.CapAt(3)
EndIf;


I would think? If so, that might be all that is required.

[znelbok]

Appears this got lost in the CID discussion

Dean

Not sure if this is the right place but I don't want to create a new thread for it.

When there is an error in a popup, the IV, the popup cant be closed and the IV becomes totally unresponsive (alt+f4 works). This is not so bad on a PC, but on a touchscreen its not acceptable at all - with the screen needed to be re-booted to get out of the locked IV.

Should be an easy one to replicate, but if not let me know and I will work out a test page.

Mick

[Dean Roddey]

Oh, no, I saw it. There's just not anything I can do right now. Anything to do with that will be tricky and will have to wait for the first beta release. I'm trying to get a nice, stable 3.4 release out so that I can start working on more dangerous things like this and others. I don't want to trade possibly breaking something unknown for this known but not hugely likely issue. I'll look at it for the first beta drop, so that there's not much chance that it'll be dangerous to move to that beta for anyone who is worried about this.

Actually there was some work done for this leading up the 3.4 release, and I thought I'd fixed it, but I guess there are some other possibilities. If you can come up with a simple example that does it, feel free to send it to me.

[LesAuber]

If your looking at error messages in the IV how about a way to supress minor ones. Like for the device not being awake yet. Or perhaps the ability to change the message to something less intimidating to non-users, push the button again dummy.

[Dean Roddey]

If your looking at error messages in the IV how about a way to supress minor ones. Like for the device not being awake yet. Or perhaps the ability to change the message to something less intimidating to non-users, push the button again dummy.

Generally you'd use the WaitDeviceReady command in those cases, to have the action pause until a device is ready (and only then to give up.)

But, yeh, having an OnError is something defintely on the list to do.

[jkish]

On line 607 the NetCallerId driver does an extract substring from a string to the same string, so that's likely the issue. That might actually also be a logic bug, not just an invalid operation, but I'm not sure and I'm loath to try to modify a driver by eye when I'm not completely sure what it's doing. Can one of you guys who is using it take a look at that? It's probably a simple fix, it just needs to be verified in real use.

Actually, it's doing this:

CurTok.ExtractSubStr( 0, 3, CurTok);

If it's actually doing what it would seem the writer intended, that should effectively be the same as:


If (CurTok.GetLength() > 3)
CurTok.CapAt(3)
EndIf;


I would think? If so, that might be all that is required.

Tried this out and it fixes the problem.

[Dean Roddey]

OK, I'll make that change for the next drop.

[Dean Roddey]

Anything on the SNMP driver? Since it's a shipped driver, if it's broken I'd like to get a fixed version in before I put up a new formal release version.

[Dean Roddey]

I've decided that, given all of the stuff that is probably going to happen for the next release, that it should be 4.0 instead of 3.5. So I've renamed the threads accordingly. If I had any links to a couple technical documents so far, they will have gotten whacked since those were changed to be 4.0 docs as well. I'll fix them as I find them, but only one I think was done so far. This will avoid a lot of going back and changing documentation later if we decided to do 4.0 towards the end, which has happened before. So best to just put the stake in the ground now.

[Dean Roddey]

Here is a document in which I start to get more into the thinking on the new device driver standardization stuff. If you can read through this and comment it would be helpful. This is going to be big stuff, and changing it after a lot of water has gone under the bridge is going to be painful. So it will be nice to get it right up front as much as possible.

http://www.charmedquark.com/Web2/Downloads/Documents/4_0/DeviceClassTrans.pdf

This isn't actual documentation, it's a transitional document that explains, relative to the existing system, what is going to be changing. At some point this document will have no more use really. It's just to provide a description to help folks more forward fro the existing scheme to the new.

This was all written out stream of consciousness, so let me know if you see any parts that seem to be in alien lingo or bad grammer of course. But mostly conceptually do you see anything wrong with the thinking or the ideas about what is going to change and how it will be backwards compatible and so forth.

[jkish]

Anything on the SNMP driver? Since it's a shipped driver, if it's broken I'd like to get a fixed version in before I put up a new formal release version.

I don't think the SNMP problem is the String issue based on these errors in the log:

12/15 20:36:58-automation2, CQCServer, CQCDrv_UPS_Thread23
{
CQCKit, MEng.System.CQC.Runtime.CQCLogger.110, Status/App Status
UPS-ProcessResponse: Unhandled Exception (MEng.System.CQC.Runtime.CQCDriverBase #7) - Value '0031 0033 0034 ' exceeds the limits for field $FailedWrite
}
12/15 20:36:58-automation2, CQCServer, CQCDrv_UPS_Thread23
{
CQCKit, MEng.System.CQC.Runtime.CQCLogger.110, Status/App Status
UPS-ProcessResponse: Unhandled Exception (MEng.System.CQC.Runtime.CQCDriverBase #7) - Value '0032 0030 0030 0030 ' exceeds the limits for field $FailedWrite
}

[Dean Roddey]

Oh, OK, that's almost always a failure to initialize a field id. The standard fields have the ids 0 to whatever. So when you get something like that, it's because the field id wasn't set or set properly, so you end up with a bogus field id value written to, and it's usually one of the standard ones which has those low values. Normally it's the $BadMsg one, since that's at zero and any unitialized field will have zero in it.

It might be better to post this on the thread in the Beta Drivers section, to make sure it gets attention.

[wuench]

So it sounds like something is botched in your SNMP config file and that is causing it to fail to create the fields properly. You're best bet is to build back your config file one or a few objects at a time until you identify the culprit.

[jkish]

So it sounds like something is botched in your SNMP config file and that is causing it to fail to create the fields properly. You're best bet is to build back your config file one or a few objects at a time until you identify the culprit.

I took the config file from this post: http://www.charmedquark.com/vb_forum/showpost.php?p=95875&postcount=3 and just changed the <Device></Device> entry to the ip address of my UPS.

As I read the log, it seems that it is a value out of range, not a field missing, but I could be mistaken.

[jkish]

So it sounds like something is botched in your SNMP config file and that is causing it to fail to create the fields properly. You're best bet is to build back your config file one or a few objects at a time until you identify the culprit.

And I believe this entry explains the first error I listed:

- <SNMPObject>
<FieldName>HighTransVolt</FieldName>
<OID>.1.3.6.1.4.1.318.1.1.1.5.2.2.0</OID>
<CQCType>String</CQCType>
<Limits>Enum:127,130,133,136</Limits>
<Access>ReadWrite</Access>
</SNMPObject>

It looks like it is getting back a 134 which isn't in the enum.

[Dean Roddey]

So I've made 3.4.8 the formal release now. The changes since 3.4.7 are:


The CML IDE is passing the main frame text as the title bar text of the open new manifest dialog, which doesn't make any sense. It should be passing a prompt to open a driver manifest file.
Do an inverted (white) set of the MPAA logos for when they are to be displayed against a darker background. Currently we only have black ones. Put them in a White scope under the existing \System\Logos\MPAA directory. Update the media repo image widget to support these.
The NetCallerId driver is doing an invalid string operation, and now that we are catching those, it's not working right. So that needs to be fixed.


If you are on 3.4.6, you don't actually need to upgrade unless you are using Z-Wave or the NetCallerId driver.

[Dean Roddey]

So, in terms of the 'semantic field types' that have been discussed, here is a list I've come up with. It's not intended to cover everything in the world. These are intended to help with auto-configuration and things like allowing the user to generate typed interface widgets (like a volume slider) according to a visual theme and such, so we need to be able to find things like volume fields.

These are the ones I think will cover those needs, but if there's something obvious I'm missing here, let me know. It seems like a small list in a way, but it covers the bulk of the most common stuff you'd ever do probably.


BoolSwitch
Contact Closure
Current Channel
Current Ext. Humidity
Current Ext. Temp
Current Temp
Current Weather
Digital Input
Dimmer
High Set Point
Humidity Sensor
LED Status
Light Switch
Low Set Point
Current Artist Name
Current Collection Name
Current Elapsed
Current Item Name
Current Title Name
Current Total Time
Mute
Motion Sensor
Power
Relay
RFID Tag
Security Zone Status
Source Input
TempSensor
Tuner Frequency
Volume
Volume Adjust


This, along with the overall type of the driver itself, will provide a fairly good idea of what such semantically marked fields are for. I.e. no need to have multi-zone audio specific power, volume, etc..., since the fact that the driver is marked as implementing the multi-zone audio class will make it clear what type of power or volume field it is.

[Dean Roddey]

So, I got to looking at what it would take to support the RIVA clients sending over environmental variable info, which we need to be able to do. This opened up a can of worms really. In actual fact, no CQC process supports currently more than one login session. Each of the RIVA client logins was really just overwriting the current user info of the last one, because it's stored in one place and everyone goes there to get it when they need it. One of those things where the future is just too far away at the time to see the need for this type of thing.

Soooo.... I've been doing the incredibly tedious work to stop storing current user info in a single place and allow the process to pass it into anything needs it (which is a lot of stuff.) This will finally allow the RIVA server (and the XML GW for that matter) to create completely virtualized user sessions and, in the process, one of the things that will allow for is the association of environment variable info with user login session info when required (otherwise it's just gotten from the host environment as usual.)

And of course it'll possibly allow for other per-user session stuff in the future, so it's something that really needed to be done. It'll probably be another couple days before I finish these changes, then I'll add the changes to the RIVA protocol (backwards compatible of course) to allow clients to send the variable info during logon, which will be stored with the user session info now.

[Dean Roddey]

I have my C++ RIVA client sending over environment variables and they are correctly showing up. I've got to spend some time just banging on everything to make sure I've not broken anything, but I think I'm done with these changes, so that's another bird off the camel's back.

[pseigler]

im anxious for this feature, also in the xml gateway. great stuff dean'o!

[Dean Roddey]

If you use the CML XML GW client wrapper, it will send the parameters over for you, by just grabbing them from the local host environment. If you are doing it yourself, there's just a small change to the get security token message to allow you to send over the values:


<!ELEMENT CQCGW:EnvVar (#PCDATA)>
<!ATTLIST CQCGW:EnvVar
CQCGW:VarNum CDATA #REQUIRED>
<!ELEMENT CQCGW:GetSecurityToken (CQCGW:EnvVar*)>
<!ATTLIST CQCGW:GetSecurityToken
CQCGW:ResponseData CDATA #REQUIRED>


So it can take zero or more EnvVar elements. The EnvVar elements have a VarNum attribute, which should be 1 to 9, i.e. you only have to send the ones that actually have values since you are indicating the number, and the value of the variable is the body text of the EnvVar element.

[Dean Roddey]

Dean I am getting the following error when I exit taRIVA (OTA) or iRIVA (WiFi), don't recall getting this before...

....

Same error for both clients. Also note the aborted message, this occurs with the taRIVA client but not at time of application exit. Since OTA, most likely it is a reconnect due to a lost handshake packet or something of the sort.

-Ben

This should be taken care of in the next drop...

[batwater]

This should be taken care of in the next drop...

The one you just posted?

Thanks
-Ben

[Dean Roddey]

Yeh..., the 3.4.11 one just posted.

[SamVimes2]

And I believe this entry explains the first error I listed:

- <SNMPObject>
<FieldName>HighTransVolt</FieldName>
<OID>.1.3.6.1.4.1.318.1.1.1.5.2.2.0</OID>
<CQCType>String</CQCType>
<Limits>Enum:127,130,133,136</Limits>
<Access>ReadWrite</Access>
</SNMPObject>

It looks like it is getting back a 134 which isn't in the enum.

JKish, I just got an S20 and I experienced the same issue, however I also had an additional field in error called "shutoffdelay":
<!-- Shutoff Delay -->
<!-- Delay to wait before shutoff. Mapped to Minutes-->
<SNMPObject>
<FieldName>ShutoffDelay</FieldName>
<OID>.1.3.6.1.4.1.318.1.1.1.5.2.10.0</OID>
<CQCType>String</CQCType>
<StringType>Card</StringType>
<XLAT>0,0,1.5,9000,3,18000,4.5,27000,6,36000,
7.5,45000,9,54000,10.5,63000</XLAT>
<Limits>Enum:0,1.5,3,4.5,6,7.5,9,10.5</Limits>
<Access>ReadWrite</Access>
</SNMPObject>

When I remove the limits and the translate, I see that the UPS is returning '2000' which isn't mapped to any value. Did you have/solve a problem with this field? Can I just enter a point in the xlat (.33,2000)?

Thanks for any advice!

[jkish]

JKish, I just got an S20 and I experienced the same issue, however I also had an additional field in error called "shutoffdelay":
<!-- Shutoff Delay -->
<!-- Delay to wait before shutoff. Mapped to Minutes-->
<SNMPObject>
<FieldName>ShutoffDelay</FieldName>
<OID>.1.3.6.1.4.1.318.1.1.1.5.2.10.0</OID>
<CQCType>String</CQCType>
<StringType>Card</StringType>
<XLAT>0,0,1.5,9000,3,18000,4.5,27000,6,36000,
7.5,45000,9,54000,10.5,63000</XLAT>
<Limits>Enum:0,1.5,3,4.5,6,7.5,9,10.5</Limits>
<Access>ReadWrite</Access>
</SNMPObject>

When I remove the limits and the translate, I see that the UPS is returning '2000' which isn't mapped to any value. Did you have/solve a problem with this field? Can I just enter a point in the xlat (.33,2000)?

Thanks for any advice!

Yes, I had that problem too.

I believe you can just enter that point in the xlat table, but I got around it temporarily by just changing the setting to one that was already in the table and haven't gone back to fix up the xml.

[wuench]

You can just add the value to the XLAT and Limits. The XLAT should pass the raw value through if it isn't in the XLAT table. And the limits are just a convenience for writing the field/validation.

[jrunde]

Would it be possible to add the Test button to Triggered Tab of Managed Events in the CQC Admin Interface? It is under the scheduled events, but would be nice to have under triggered as well.

[wuench]

And would it be possible to add the list of available windows in the Macro IDE to the menu like the Driver IDE has?

[Dean Roddey]

Would it be possible to add the Test button to Triggered Tab of Managed Events in the CQC Admin Interface? It is under the scheduled events, but would be nice to have under triggered as well.

Unfortunately it wouldn't work. THe triggered event depends often on incoming trigger info, which won't be there if you do it that way. The only way I've really though to do it would be to have it disable the event on the server, and then get you to make the trigger happen, so that it'll be triggered there on the machine where you are editing it and it can have an action trace and whatnot.

That's a little tricky because if something goes wrong on the client the event on the server could stay disabled. But that's about the best way I can think of doing it that would always work.

[Dean Roddey]

And would it be possible to add the list of available windows in the Macro IDE to the menu like the Driver IDE has?

I thought it already did. If not, it is supposed to.

[jrunde]

Unfortunately it wouldn't work. THe triggered event depends often on incoming trigger info, which won't be there if you do it that way. The only way I've really though to do it would be to have it disable the event on the server, and then get you to make the trigger happen, so that it'll be triggered there on the machine where you are editing it and it can have an action trace and whatnot.

That's a little tricky because if something goes wrong on the client the event on the server could stay disabled. But that's about the best way I can think of doing it that would always work.

No Worries, I don't know why I didn't think of it before, but I just copied the action over to scheduled events and tested it there.

[Dean Roddey]

Well, since I had to be in there anyway and was in for a big recompile, I put in the code to supposedly support the pausing/resuming of drivers. I'll actually test it out tomorrow and get it working along with some other things I've been banging on. I know a lot of folks have been wanting something like this for a while.

[wuench]

Well, since I had to be in there anyway and was in for a big recompile, I put in the code to supposedly support the pausing/resuming of drivers. I'll actually test it out tomorrow and get it working along with some other things I've been banging on. I know a lot of folks have been wanting something like this for a while.

So how does this work from a driver perspective? Does it shut it down basically (FreeCommResource, etc)?

[Dean Roddey]

Yeh, it's stopped and resources freed, but it's not unloaded. When it's resumed, it's just like a reconfigure but without changing anything. And actually a reconfigure would also wake it up from a pause, with the option to change settings in the process. In terms of accessing the driver, it would be the same for any other driver state prior to connected state.

[znelbok]

I would like to add a request if I may.

I am finding it hard to troubleshoot scheduled events and triggered events. It takes a lot of effort to add log messages in to work out where someting is going wrong, especially when a field write is the problem, because unless the driver verbopsity is set to high, you dont catch the offending write.

I would like to ask for an option in a field write to log the write to the log server so that it can easily be tracked.

This could also extend to the commands from widgets as well, but there is the trace window for that currently.

Mick

[Dean Roddey]

Yeh, really it would be nice if the action trace could be available for testing out those. For scheduled events it wouldn't be too hard to do that. Well, for triggered events it wouldnt' be too hard either, it's just harder to actually test triggered events in such a way that they would always work correctly due to the fact that they may reference incoming event trigger data.

[znelbok]

The action trace is fine if you are in front of the machine, but when you have an intermittent fault, you need to be able to log so that it can be retrieved after the fact. The action trace is great for initial setting up and testing, but not for long term monitoring of issues.

Mick

[Dean Roddey]

Ok, OK. The action trace is really just based on a pluggable callback system. So a version of that pluggable interface could be created that just logs the output of the trace. I'd have to think about how to really go about that. You wouldn't want to log all of that to the log server probably.

[Dean Roddey]

So, we now have a filterable new driver selection dialog. As with the IR model selection dialog you can filter by device category or manufacturer name. So that should make it easier to find device drivers as the list grows.

[Dean Roddey]

I got the host admin dialog updated to support the new pause/resume stuff and that seems to be working now. So I'm inching towards the next beta here. And I've also updated the PNG support to get the transparency color info in there for palette based images for the RIVA client guys.

[beelzerob]

I'm on 3.4.4, and I noticed some issues lately when I bring the CQC main server back up. Once I couldn't access anything CQC ("Waiting for CQC...") and logging into the main server, I found the cqc service had not started. I changed it to automatic and started it, and it was ok.

Last night we lost power and when it came back up (it was an orderly shutdown thanks to APC) I had *partial* CQC capability. The IV would come up, and it would load an interface, but none of the fields were populated, and the radar web page wouldn't come up. I checked the service, and it said its state was "Stopping", and I couldn't stop, start, or restart it. I had to reboot the master server, and when it came up, everything was fine.

Any ideas? I'll update to 3.4.11, I hadn't realized I'd fallen so far behind.

[Dean Roddey]

If you have that kind of thing happen, it's quite possibly the socket related things that were fixed in 3.4.6. So I'd definitely recommend moving up to 3.4.8 at least. You don't have to do the betas if you don't want to at this point. The problem was that sometimes a socket would seem open but really be, so once a connection was lost it couldn't get reconnected again because the code using it thought it was already open.

[Dean Roddey]

OK, I just did the work to change the TTS system so that I render to a file and queue up the file on my own thread for spooling out as a WAV file. I've got to go eat some supper. When I come back I'll see if I just wasted all my time, by checking whether it works as a service now. It's a fair PITA because it had to be done down at the virtual kernel platform driver level, where not a lot of functionality is available.

[Dean Roddey]

Well the files get created, but the simple level playing of a WAV goes nowhere. So I'm going to have to get fancier I think. I'll probably move the existing TTS stuff back to how it was (for use from foreground apps), and just provide an new method for the outside world to call in and cause text output to be written to some file that they want. Then I'll have to use my DirectShow engine to play the audio, which should work since it currently works for music playback.

That'll actually be kind of nicer since then I can do all of that queing and playing up at the CQC level where I have lots of tools.

What I may do is just re-do the TTS driver in C++ and make it the only way to do TTS from the background, so the System::XXX commands won't work but the TTS driver will. And then I can update it to let you select an audio output to use and all that, which will be required. That might be the only sane way to do it, and it won't be a huge burden for folks to change the TTS they are doing from the background over to do it via some TTS driver instance.

[Dean Roddey]

OK, I have created a new Speech II driver that is a C++ driver. This one works much like an audio player driver, in that you have to select an audio output for it to use. It writes the text out to a file which it queues up and then spools them out via the DirectShow audio engine, and then deletes them.

It's working currently in Vista without being logged in as a regular user, so that's a pretty good sign that it's going to work on Win7. I'll do a little more testing then do a production build and install it on my little Win7 machine and see how it does there. But I think it works now.

So regular TTS still works via the System::SayText if you want to just speak it locally from an action on a template or something. But, for background TTS you'll have to load this driver and do it through that. So scheduled/triggered events need to work through this driver. And of course any stuff you would have used the existing TTS driver for (which is still there for backwards compatibility) you can do with this one and it should work under Win7, such as spitting out speech through your multi-zone audio system or whatever.

So, once again the triumph of the human spirit over the tyranny of the machine.

[Dean Roddey]

And I guess another advantage to this way is that you also now have volume and mute control over the TTS output done in the background.

[jkish]

OK, I have created a new Speech II driver that is a C++ driver. This one works much like an audio player driver, in that you have to select an audio output for it to use. It writes the text out to a file which it queues up and then spools them out via the DirectShow audio engine, and then deletes them.

It's working currently in Vista without being logged in as a regular user, so that's a pretty good sign that it's going to work on Win7. I'll do a little more testing then do a production build and install it on my little Win7 machine and see how it does there. But I think it works now.

So regular TTS still works via the System::SayText if you want to just speak it locally from an action on a template or something. But, for background TTS you'll have to load this driver and do it through that. So scheduled/triggered events need to work through this driver. And of course any stuff you would have used the existing TTS driver for (which is still there for backwards compatibility) you can do with this one and it should work under Win7, such as spitting out speech through your multi-zone audio system or whatever.

So, once again the triumph of the human spirit over the tyranny of the machine.

Is there any way to know when the speaking is finished?

That is important so you will know when to switch source inputs.

[Dean Roddey]

Is there any way to know when the speaking is finished?

That is important so you will know when to switch source inputs.

As with the other speech driver there is a SpeechActive field that is true whever speech is still going on and false when there isn't any. So you can use that to block until speech completes.

[LesAuber]

To further reduce machine tyranny how about getting CQC to install so that Win 7 doesn't ask if it's ok every time I open interface template viewer without turning off the user annoyance center. This is running as an admin.

There is no longer a don't ask again check box and running streams didn't eradicate it. I seen that someone posted a solution earlier but it was rather over my head. I don't know if it's the level of access CQC is looking for or what as other programs don't get this treatment.

[Dean Roddey]

Yeh, that's on the list to deal with.

[Dean Roddey]

OK, it works on Windows 7 as well, so it looks like I can dance on the grave of that problem finally.

[anogee]

OK, I have created a new Speech II driver that is a C++ driver. This one works much like an audio player driver, in that you have to select an audio output for it to use. It writes the text out to a file which it queues up and then spools them out via the DirectShow audio engine, and then deletes them.

It's working currently in Vista without being logged in as a regular user, so that's a pretty good sign that it's going to work on Win7. I'll do a little more testing then do a production build and install it on my little Win7 machine and see how it does there. But I think it works now.


Yeah!!!!! :shock: :-) :-D ;-)


As with the other speech driver there is a SpeechActive field that is true whever speech is still going on and false when there isn't any. So you can use that to block until speech completes.

O.K. I want to put all this together, but I still think I'm missing a bit. Help me out.

I have a driver that can control my AP800 and switch the 8 zones of speakers in my house. When I speak in an action, I need to somehow contain not only what to speak, but also where to speak it.

So any ideas? Maybe set the text and locations in some variable.

The an action would trigger when the variable had something to speak. I would somehow extract the data that tells where to speak, then if nothing else was speaking I'd switch the speakers, and speak.

I guess it will work, but the name Rube Goldberg comes to mind.

You said it was constructed with a text file queue, which is great, but is it possible to have a text message in the queue cause a trigger so that I can switch the speakers before it actually speaks the message in the queue?

[Dean Roddey]

I assume that the triggered event or scheduled event that wants to speak something would set up the switcher to where you want to speak, write to the SayText field of the new driver, then do a WaitFieldValue type command to wait for the SpeechActive field to go false indicating that speech is completed. Then it would put the speakers back how they were before.

It will actually set the SpeechActive field true as soon as you write something to SayText, so by the time you return from the field write, the field should be set. The driver will start speaking the text and then clear the field when it's done. So your WaitFieldValue command will return and you can put things back.

I guess your concern is if multiple things happen at once and you want to serialize them and as each one comes up, switch the speakers as each one is ready? That would be pretty tough to support in a reliable way I think.

Well, you could do your own intermediate driver that you send the text to, along with switching info. Then it would spool them out to the speech driver in turn, using the SpeechActive field to know when to send the next one out, and switching speakers before each one or something.

I guess it would be possible to support something like a SayText2 which took the text to say and some other value. Then, when you install the driver it would ask for a CML macro that it would invoke before it spoke each line of text, passing this other value to the macro and that could do any setup you wanted to do. Something like that.

[anogee]

Maybe something like this. I could just create a global variable that I would set to contain the combination of the speakers to speak. I would set this variable in the action every time before I spoke.

Now you say you put the text to speak in a file, then you speak it. The helpful "feature" request would be a way to externally control when it does and doesn't speak. Text lines to speak would still go to the file, but if I could suspend speaking that would be great. So when I switched the speakers I would turn off speaking, once I got confirmation that the speakers are switched, I'd turn it back on, and so forth. Maybe even some signal when a line to speak is in the buffer, and a way to speak just the next line. That would do 99.5% of what I and others could use. It doesn't fix the multiple items speaking at once problem, but that is OK.

This might be real helpful to others as well. Lets say you leave the house and shut off speaking, then when you return you could hear all the messages you missed while gone.

It doesn't need to be complicated at all.

Thanks.

[LesAuber]

OK, it works on Windows 7 as well, so it looks like I can dance on the grave of that problem finally.

Talk about tempting fate :D

[Dean Roddey]

I've made what I think at the required changes to be able to get rid of the UAC stuff on the client/GUI programs. I'll see tomorrow if it actually works. I will probably just not try to be clever and just toss any existing data, and start over fresh under ProgramData. It's just stuff like current window positions and such.

Luckily, in a previous attempt I'd already done a lot of work to really consolidate down control over where such files go to single place, but still it's a bit tricky since the server programs still have to deal with things under CQCData, and only the client apps go to ProgramData, but much of the code that was affected is shared by both.

And, in my development environment even the client apps still have to go to CQCData since the data has to stay with the version of the program that created it and I have to support multiple simultaneous versions of the same system. The SYSTEMID value would otherwise keep separate the ProgramData stuff of multiple systems in a production environment, since it's C:\ProgramData\CQC\[sysid]\etc.... So each system has its own unique system id for some time now (to avoid broadcast events being seen by other systems) and that same id is used to create unique per system storage.

[Dean Roddey]

Oops, the installer for 3.4.12 isn't going to work for folks on XP (or WHS versions based on the pre-Vista code base), because I stupidly checked for the ProgramData environment variable, which doesn't exist pre-Vista I don't think. This was done as a preliminary move towards getting rid of the UAC (the rest of which I coded yesterday.)

Oh well, I'll get it another way in the .13 version, just hold out for that. You can also get it as one of the 'special paths' via an API call, instead of depending on it being in the environment. So I've changed the installer and the other place where that path is gotten to do it that way.

[George M]

Dean,
I haven't DL a beta for a while. Now I cannot find where they are located. Can you point me to the files?

[klindy]

Dean,
I haven't DL a beta for a while. Now I cannot find where they are located. Can you point me to the files?

They're all in this thread....

http://www.charmedquark.com/vb_forum/showthread.php?t=9523

[George M]

Thanks
I was looking at the bottom of the thread instead of the top.

[Dean Roddey]

OK, so I had an idea today on the whole driver standardization thing. I think it's a good idea, but I'm just typing it out to make myself say it out loud and have to get my thoughts in order, and maybe some of you might see an issue with it, I dunno....

So, the big issue with standardization is that the fields have to be the same for any driver of a particular type. If you don't have that, you lose the ability to swap out Sparculator A for Sparculator B and have it work exactly the same. And if we can't do that, then the whole thing is a waste of time. The two ultimate, fundamental purposes of all of this work are:

1. To allow for equipment swap out (which is the inverse of saying the abiltiy to write logic that will work for any device of the same type.)
2. To allow for smart tools that can generate solutions generically.

But of course the problem with the fields all having to be the same is that they cannot really be descriptive. This is something that is an issue of course with some devices already, such as the Elk or Omni where instead of Output01 you might want to have a field named OpenKitchDoor or something like that. And sometimes even though the field name is fine, the values it can be set to also have to be generic else they are useless for the purposes above, such as the surround modes a HT receiver, or the security status of a security zone.

These two needs are really at odds with each other, and I've been thinking about how to deal with it. The reason it's not done for some of the devices that could use it now is that it requires that any driver that supports such a thing have a client side configuration interface. This is a boatload of work and just isn't practical. Of course you could do a simple text file that the driver loads, and some drivers do, but that's ad hoc and easy to make mistakes and such.

One option, once we move to a scenario where fields are standardized for a given type of device, is to allow for that sort of field name mapping, but have the configuration thereof be totally generic. Since every device of a given type has to have fields that meet exact criteria, it becomes possible to provide a generic name mapping interface.

It also becomes possible to have system configuration tools that work in terms of the actual underlying generic names, and store those names internally in the configuration for later use if you make changes, but then spit out a solution that uses the mapped names.

So, a receiver might have a field named AudioSurMode (and that's fine to keep that name as is) but the enumerated values of that field might be things like "DVD Movie", "DVD Music", "CD Music", "Blu-Ray Movie", and so forth. So completely generic values. But the mapping interface would allow you to map those to the actual available real modes supported by the receiver. If you later swap out that receiver for another, all you have to do is tweak this mapping to get the same results.

The gotcha of course is that now creating a new driver architecture 2.0 type of driver gets more complex. The driver will have to store various mappings that it supports in the manifest file, or some side by side type of mapping file that goes with the manifest file, which can be used by the driver itself or by a configuration tool. And when someone writes to that AudioSurMode field, the driver will generally do a sort of double lookup, instead of the single level lookup it will typically do now.

I.e. drivers already do this sort of mapping, in that they provide a human reasonable set of audio surround mode settings, which the map back and forth to the actual values sent to the device. Now, they'd probably do a mapping from the user provided value, to an internal value (that has all of the possible values) and from that to a device specific value. In some cases they could skep the intermediate mapping but often it would be way more convenient to do the two steps.

The same sort of thing would apply to field names. If DigIn_001 on your digital I/O box really represents garage door open/close state, you can map it to GarargeDoorState or something like that. If you later change out to another device, you can just map the appropriate field in that device to have the same name and all of your logic stays the same. Of course you could just use the original DigIn_001 field as well and all drivers would initially load with a one to one field name mapping (and some reasonable default mappings for the enumerated value type of fields discussed above.)


So, I'm ramblign now, but hopefully that made some sense. To summarize the benefits are that you get both meaningful names for the fields of devices that have non-specific use fields (like the Elk/Omni) and you get the ability to assign the generic values of enumerated fields, which cannot serve the purpose of re-deployment if they aren't completely independent of the device itself, in such as way as to get the results you want while still maintaining the ability to swap out devices. And any smart configuration utiltities can both store generic field names/values on disk, while spitting out mapped names/values to the generated solutions, so that it can both survive changes to the mappings without failing, and still spit out the mapped names.

The down side is that of course driver writing becomes more complex, and there's more to understand before you can do one. This doesn't mean that all drivers have to do this. Only those that claim 2.0 driver architecture compliance have to do this. Drivers can still be written the current way, they just won't provide these advantages and won't be available via the magic configuration tools, and possibly some other things like a future schemes type of system for the interface designer. All of this new magic functionality coming up will only work with drivers that are complaint with whatever requirements end up being part of this new driver architecture.

[Dean Roddey]

Oh, and a couple more late breaking thoughts...

Because what is mappable is effectively defined by the device class definitions, actually the base driver class could do the first level mapping for you, so that the driver would only ever have to deal in terms of it's generic interface, which would make things simpler, though it would mean still that if they log any errors or messages that they'd have to look up the mapped name generally to put into those messages. But, still, because of the well defined nature of the device classes and the mapping system, some of the burden could be taken off of the individual drivers and provided by the common driver base class.

And of course that's why there could be a generic driver mapping interface, because it could understand these rules and by just looking at the device class definition and the fields provided by the driver it would know what could be mapped and what couldn't be.

[LesAuber]

Isn't mapping like this what is basically being done with XLAT just taken outside the driver?

Unless I'm missing it completely this sounds workable providing it can handle exceptions. On my Casablanca when selecting input I need to specify both input and source. Becoming less an issue with HDMI but still needs accounted for.

[Dean Roddey]

Isn't mapping like this what is basically being done with XLAT just taken outside the driver?

In this case, it's that being moved inside the driver. But not to convert the values for display purposes. It's serving two purposes. One is to create meaningful names for those fields that are generic. The other is to allow for generic values in enumerated fields, which are mapped to actual values inside the driver.

Unless I'm missing it completely this sounds workable providing it can handle exceptions. On my Casablanca when selecting input I need to specify both input and source. Becoming less an issue with HDMI but still needs accounted for.

In some cases, these things will not be dealable with automatically. The 'device classes' that define the standard functionality of various types of equipment have to be pretty generic, otherwise they are useless. In a case like that, you might have to just accept that if you swapped in another piece of equipment that you'd have to make some changes. Though, in some cases, the driver can hide these things internally.

[Dean Roddey]

So I'm testing out the removal of UAC from the client apps stuff. It seems to be working. But one thing I thought about, which probably isn't a problem, but I figured I should mention it, is that clients and servers (on the same machine) no longer share a MacroFileRoot directory. So they cannot both see a file that they might want to share. Probably no one is depending on this, but if so it won't work anymore if so. Clients can't create files in the Program Files area or that would require administrative rights.

It also means that, for a full back up of the system, you would have to back up this stuff in the common app data directory. However, the stuff stored there is really disposable stuff, like last window positions and that kind of thing. So it wouldn't be any great problem if it got hosed.

[Dean Roddey]

Just a couple of issues came up and I think I've fixed those. I'll do some more testing tomorrow then put up another beta. This will get rid of the UAC and also fix the issue that .12 had on XP based systems.

[Fonceur]

Regarding the driver 2.0, the extra file for configuration sounds good... But I'm not so sure on the generic drivers themselves... Will you constantly add new "generic fields" as they get discovered, if you missed them in the original release? Would you be able to get some kind of "generic field array" to handle say a receiver with 4 output, the next with 8, and so on?

is that clients and servers (on the same machine) no longer share a MacroFileRoot directory. So they cannot both see a file that they might want to share. Probably no one is depending on this, but if so it won't work anymore if so.
Off hand, it sounds like it might break the SageTV drivers that do use macros, and possibly a few of jrlewis drivers...

EDIT: I take that back, it doesn't seem like the Sage drivers use it and I'm not sure that the stuff from jrlewis that was using it is actually public... ;)

[Dean Roddey]

Regarding the driver 2.0, the extra file for configuration sounds good... But I'm not so sure on the generic drivers themselves... Will you constantly add new "generic fields" as they get discovered, if you missed them in the original release? Would you be able to get some kind of "generic field array" to handle say a receiver with 4 output, the next with 8, and so on?

Since it is an inheritance hierarchy, it's always possible to derive a new, more extended version of a device class without breaking any existing drivers. That is to be avoided where possible to prevent complexity, but it can be done.

The device classes will define not just fields, but back door queries as well. So, for things like multi-zone audio and the like, queries we have to be provided by the driver to ask what the maximum and current numbers of various things are. And other information of that sort that is required for use by design tools and any sort of mapping system.

But of course all that adds complexity and it's hard to say if this mapping scheme would collapse under its own weight or what.


Off hand, it sounds like it might break the SageTV drivers that do use macros, and possibly a few of jrlewis drivers...

EDIT: I take that back, it doesn't seem like the Sage drivers use it and I'm not sure that the stuff from jrlewis that was using it is actually public... ;)

It's not macros, but data files accessed by macros. And of course it's probably not very wise or practical to do this anyway, since the client may not be on the same machine and you couldn't synchronize access anyway. Typically the client will only update such files by way of the server driver. So I don't think it'll be a problem.

[beelzerob]

Dean, with the new website, where is the "driver development guide"? It's the only thing I'm aware of that has info on the layout of the .manifest file.

[Dean Roddey]

Dean, with the new website, where is the "driver development guide"? It's the only thing I'm aware of that has info on the layout of the .manifest file.

Dang, Bubba, another one I missed. I think I'm going to spend tomorrow on a documentation update. I've got a pretty long list of things that need to be dealt with. You can still get to it in the meantime from the old web site.

http://www.charmedquark.com/Web2/OldWebSite/

[beelzerob]

Ya, I forgot how to get to the old one, I figured it was still there.

[beelzerob]

I'm having an issue, all of the sudden....

It began when my wife informed me that it was *not* still 27 degrees outside, which is what the touchpad said it was. It was actually more like 40. I verified with a thermometer. So, I went and looked at the Datanab driver. I didn't see any values anywhere changing, which they usually do up and down. So, I tried setting the verbose to Medium for the Datanab driver, and I got the message that it couldn't be set. This usually means the driver is off in la-la land (though I've been using this driver for some time, it's hard to believe there's an infinite loop in it I've not noticed before). So, I tried cycling via the shell log. I get the usual notice that not all services could be stopped in the allotted time (but it usually comes backs up after that). This time, no device drivers show up in the admin panel for that PC (it's my CQC master). So, I remote log into that PC and cycle the CQC App service itself. It stops, then starts...and I still have no device drivers listed for that PC (there should be almost a dozen).

Before I try rebooting the PC, is there anything else I should look for?

I did notice a day or so ago that it told me windows had updated and forced a reboot...but I'd think EVERYONE would be complaining if that had broken something.

The other host (the kitchen PC) still responds just fine and has its one driver still loaded (TTS). The Admin client still comes up, so CQC itself does not appear to be locked up.

[Dean Roddey]

Looks like some driver locked up hard. That's about the only thing that could 'splain something like that. Use the task manager to kill CQC on the affected machine. It should get startd back up immediately by the shell. If the drivers come back, then that means that CQC couldn't be stopped and was still there, but half dead due to being hosed up. Check the logs anyway and see if anything suspicious was being logged.

[beelzerob]

Well, I got task manager up, and didn't know which cqc process to kill. I supposed it was CQCAppShell. I killed that, and it didn't come back up. So then I tried CQCServer, and I *couldn't* kill that. *shrug* I rebooted the machine and everything appears to have come back up.

Looking in the log, nothing stands out, thought there is a somewhat cryptic entry of "Could not find message" for CQLogicSrv, App Status, Main Thread.

There's a lot of red messages:

"Connect operationed failed. Tried to connected to: (cqc main server IP)" from CQCClient, Timeout, TVarDriverCWndPollThread_Thread0

Could not contact the CIDLib Name Server (at (cqcmain server iP)) from CQCIntfView, Not Found, Main Thread


I think those red entries are from after I noticed the issue.

[Dean Roddey]

If you couldn't kill CQCServer, then something particularly bad happened, and it may have been related to the upgrades or something, or it wasn't finished messing around with the system when CQC came up or something. Keep an eye on it and see what happened.

And it was CQCServer you wanted to kill, not the app shell. CQCServer runs the drivers.

[kayemsi]

For the generic driver mappings, I wonder how this would affect the Centralite driver. It has the ability to read a config file to get the fieldnames the CQC user wants to use for the various load, sceanes and buttons (switches), but the driver can (if no config file is present) query the device for the names that were assigned in the device itself which are whatever the centralite user setup such as "Garage Light" (the centralite defaults them to "Light #01", "Button #21") which the driver converts to compliant fieldnames by changing spaces to underscores, removing the #, etc.

Would this cause the driver to be difficult to be made compliant? Would it cause issues with existing installations during the upgrade process, if the driver was made compliant?

Just curious.

[Dean Roddey]

I assume it would require that you just abandon the file and move that info over to the standard mapping scheme. Writing a one time conversion for all of the existing ad hoc schemes would be pretty tough.

[znelbok]

Simple little request Dean

In the Edit Action window, can you make its default width twice as wide as it is now. Every time I open it I have to widen it and nothing fits int he width you have given it.

Mick

[Dean Roddey]

Simple little request Dean

In the Edit Action window, can you make its default width twice as wide as it is now. Every time I open it I have to widen it and nothing fits int he width you have given it.

Mick

Actually what it really should be doing is just remembering the previous position which would solve the problem better. It's been on the list a while but just lack o' time to get around to dealing with it. I'll get it done here soon.

[beelzerob]

Dean, I thought we could run accessor functions on enumerations directly. So, something like:

MyEnumeration.TheChosenEnumeration.GetName()

would return the String of whatever the name is for TheChosenEnumeration. Accessing this directly instead of having to create a MyEnumeration object first.

I try doing this and it says: "Class MyEnumeration.TheChosenEnumeration does not exist"

[Dean Roddey]

Dean, I thought we could run accessor functions on enumerations directly. So, something like:

MyEnumeration.TheChosenEnumeration.GetName()

would return the String of whatever the name is for TheChosenEnumeration. Accessing this directly instead of having to create a MyEnumeration object first.

I try doing this and it says: "Class MyEnumeration.TheChosenEnumeration does not exist"

I don't think that's supported, that I remember. Pretty much everything has to be an actual object to make method calls on them. You can get to constants of a class via the class name, but that's not a method call, it's just accessing a publically visible, constant member of the class.

[beelzerob]

What are the public members of enumeration? How do I access the Name of an enumerations without creating a variable of that type first?

Also, it happened again Dean. I tried using the Shell log to cycle the master server. CQC Server never came back up for it. I went onto the master server and cycled the CQC App Shell...nothing. I then found the CQC Server process and tried repeated to kill it...nothing. I finally stopped the CQC App Shell altogether, and CQCServer stayed on as a process. I rebooted and everything is ok again.

[Dean Roddey]

What are the public members of enumeration? How do I access the Name of an enumerations without creating a variable of that type first?

Also, it happened again Dean. I tried using the Shell log to cycle the master server. CQC Server never came back up for it. I went onto the master server and cycled the CQC App Shell...nothing. I then found the CQC Server process and tried repeated to kill it...nothing. I finally stopped the CQC App Shell altogether, and CQCServer stayed on as a process. I rebooted and everything is ok again.

If you can't kill it via the task list, then there's something pretty fundamentally wrong. You were having a similar problem before, right? Either you've got some sort of fatal loop in a driver, or some communications hardware issue or something that's locking it up at a level that the task list can't kill it.

On the enum thing, you have to create a local or member of the enumeration and set the value in order to get the name for that value. If you want to get all the values, just enumerate through the enumeration values, getting the name for each one as you go.

The only directly accessible public members of a class (as apposed to objects of the class) are the constants. You can access the constants via an object as well. But they are the only things accessible via the class name. Well, you can obviously SET an enumerated object to a specific value of the enumeration of course. So you can do:

m_MyEnum := MyEnumType.Value1;

That's obviously necessary in order to be able refer to the values of an enumerated type. But you can't call methods on the Value1 because it's not really a created object. I don't think you can call methods on the constants of a type either. In the same was as with Value1, you can reference them as source values, but you can make them the target of any calls. In theory it would be possible to call Const methods on the constants of a class, but currently it's not supported as far as I remember.

[beelzerob]

Ok, that all makes sense.

I haven't added or changed a driver in quite a while, so I'm not sure what it could be. Of course, because *some* things seem to still work (drivers still return values, even when the Datanab was locked up), so who knows how long that was going on.

I could check and see if cycling the master server via the shell log makes it happen again. It could be that a rogue driver was already locked up when I did that, or it could be that it triggers the effect.

[beelzerob]

And ya, post #132 of this thread I described the issue I was having with a CQC Server that didn't want to die.

[Dean Roddey]

So, I'm now to the point where I have to do the Marantz, LG TV, and NeoTV drivers, and I want to make them the first of the drivers that are compliant with the new driver architecture. This means of course that there has to be a new driver architecture to be complaint to, so I have to finally commit to one of the various schemes I've been considering.

It's just incredibly complex to try to come up with something that will have a chance at being flexible enough but also controlled enough. Once you really start thinking through what will be required, it's pretty mind boggling. If you look at something like Z-Wave, even with their VERY simple types of device classifications (they work at the level of a single light switch, a single motion detector, etc...) they can't be completely consistent, even when those devices are specifically made to be Z-Wave devices. When you are talking about the really complex and varied devices CQC has to deal with, which aren't even remotely designed to be consistent, it can drive you crazy.

The previously discussed ability to map the names of fields to other names is obviously one possible big part of the solution. I've been going around and around on this, and though it will add its own sort of complexity, I can't see a way out of it. And I can't see a way also out of providing the means to do the same for the values of many enumerations. Once you start thinking through the mechanics of what it would take to be able to swap out device A for device B and not break anything, I don't think it's possible to avoid this.

If this is the case, then it does mean that I can go ahead and write these drivers based on a device class specification that deals purely in generic field and enumerated value names, since the mapping scheme support can be added later (though folks who use them now will have to write logic in terms of the generic stuff and change that later when the mapping scheme is available.)

I guess that automatically generated solutions can work purely in terms of the generic names. It doesn't care if the fields have understandable names per se. However, it still raises an issue for things like enumerated values. Let's say you have an A/V receiver, and the device class spec for a processor device (of which an A/V receiver would be one) says that the enumerated limit for the Input field has the values Input01, Input02, Input03, etc... at the generic driver level.

The user would have to say what input that CQC should select for listening to/watching a paritcular source device. But it's almost guaranteed that Input01 would not be useful for the same type of source device on another receiver. So you couldn't just swap one out for another and expect the existing generated (or hand written) logic to work as is. It would basically require (not just allow for) a user provided mapping of these types of fields to names that have meaning for them, so that they could just modify that mapping for a new device later.

I can't see any way that I could come up with a set of generic input naming schemes that would be translatable. I.e. I could say that the limits for such Input selection fields have be in the form DVD01, DVD02, BD01, Phono03, etc... And then the driver documents how it has mapped physical receiver inputs to these names, and as long as you plugged the source devices into the inputs given the same name on the new receiver's driver it would work. But I'm not really sure that would work, since many processors allow the inputs to be configured for different things, so no driver could now what generic names are appropriate.

So I think that we just have to assume that some enumerated field values have to be mappable, and have to be mapped by the user in order to gain the benefits of device swapping and/or logic redeployment. That complicates things obviously since that has to be done for all such fields before even automatically generated solutions can be generated.

And of course similar issues apply to field names for those devices that have variable numbers of generically configurable control points, such as sensors, analog and digital I/O, etc... I don't think that any generic naming scheme would work for those in a way that would allow for swapping out devices.

So, in some ways, the complexity of just knowing what you need to map and making sure you've done so before you start building logic could get tricky. Yes, it does provide the means to swap out devices if you get it right, but a lot of the time, maybe most of the time, such a swap isn't ever required, and if it is it's not that hard to deal with it in the current scheme of things.

There's no way that knowledge can be built into CQC, since it's just too complex to understand ahead of time for any give type of device. I just worry that it we have to expect a user, just to even use a supposedly quick and simple configuration and generation based system, to understand the issues of mapping lots of field names and enumerated values before the system can even be generated, that maybe that will just kind of null out the benefits that this driver standardization scheme is supposed to provide.

I guess with the configure and generate scheme that it could work in terms of all the generic field and enumeration values, and the configuration tool works purely in terms of just having you set up the equipment to a given configuration for a given activity that's being configured, and the tool just senses what selections you've made and remembers those and plays them back later, and then you just have to go back through that process if you change any equipment, and regenerate the solution.

But that doesn't help with hand tooled solutions where you really want to just be able to replace one compliant device of type X with another and not change anything. But I just don't see how it can happen without doing pontentially a considerable amount of manual effort to map generic names of things to semantically meaningful names of things. And of course you may never realize you failed to do some mapping you should have until it's time to swap out a device.

Not that it's all bad. It's really mainly a problem with things like receiver inputs, and other devices like automation panels for the analog/digital inputs, etc... For other stuff it will work well enough. The power, mute, volume, etc... of each zone of a receiver, for instance, would not be a problem without any mapping. Just attach the same speakers to the same zones in the new device and you should be good.

I guess that the device class info could mark specific fields as requiring (or strongly recommending) mapping and the driver install wizard could insure that you are given the chance to do so during driver installation (and of course later you could change it after the fact), just to make sure that you know that certain things really need to have mappings done if you want to achieve portability.

So, anyway, I'm just kind of rambling out loud to make myself think it out. It's just insanely complex once you get into it.

[George M]

Yea! Finally a Marantz driver!!!

[beelzerob]

Well, it happened again. I *knew* it wasn't actually 30 degrees outside (actually more like 10). It seems to be the Datanab driver, or at least it is most affected. Once I realize it hasn't been updating values recently, I can try and change the verbose of the driver and that fails.

So I rebooted the cqc server, and when it came up I set the verbose to high. It's spamming and spewing the log, but hopefully I'll get a final glimpse of what it was trying to do.

Is an infinite loop really the only thing that could be happening? I'll look back and see if I've changed the datanab driver recently, but I don't think I have...hmm...*except* I recently changed from the IP version of the driver to the serial version. Hmmmm...that's interesting.

[Fonceur]

I hope you were planing to make those new drivers in CML so people can use them as a sort of template, and not hide them as pre-compiled C++ ones... ;)

[Dean Roddey]

I hope you were planing to make those new drivers in CML so people can use them as a sort of template, and not hide them as pre-compiled C++ ones... ;)

Oh, they aren't any different than existing drivers really. It's just that there will be standards to follow, and those standards will be based on a set of 'device classes' that will be well defined and documented. And the tools will be able to tell you if your driver meets the class specifications it claims to implement. For devices that really fall outside of that device class system, and some will, there won't even be that difference.

The mapping scheme may not even be visible to them, since it can probably be done by the base driver class on their behalf, in which case they will not even know these things exist. Maybe in some cases, if they are going to reference the field name in an error message they may want to be sure to use the mapped name, for easier interpretation of the message, or a few little things like that.

[Dean Roddey]

Yea! Finally a Marantz driver!!!

I just posted a first cut in the beta drivers section if you want to try it out.

[wuench]

If this is the case, then it does mean that I can go ahead and write these drivers based on a device class specification that deals purely in generic field and enumerated value names, since the mapping scheme support can be added later (though folks who use them now will have to write logic in terms of the generic stuff and change that later when the mapping scheme is available.)
...

I think it would be good to give the driver a shot at doing the mappings and let the user override them. We recently discovered that the Denons have secret commands that allow you to discover the friendly names the user has put in.

So maybe keep the Source1..2..3 names. Allow the driver to optionally deliver mapping info, and maybe via a prompt ask "This driver can map your sources for you. Do you want to use this driver's mappings, they will overwrite any existing mappings". And still allow the user to go in via an interface an map them manually.

[Dean Roddey]

I've been thinking about this more and I think that maybe the way to go is not to do a mapping *above* the driver, but within the driver. As with any scheme, this has both pros and cons.

With the mapping above the driver, the driver provides generic field names and generic enumerated field values and that's all it knows about. The mapping system allows a new set of names to be layered on top of that. This has the following pros and cons:

Cons

1. Way more complex, there are two different names for lots of things and keeping up with which one is the right one at any given time will significantly increase the complexity of the system and the tools.
2. A good bit more overhead because lots of field operations will end up having to be mapped one way other the other.
3. Make *redeployment* of logic actually no better than now, because the names you mapped stuff to would have to be mapped the same way on the new system the logic goes to.
4. Doesn't deal with the fact that there are going to be more choices inside the driver that need to be mapped sometimes than inside (see discussion below.)

Pros

1. Allows for the use of meaningful names instead of generic names at the user level.
2. Makes swapping out one device for another within the same system pretty easy (as apposed to redeployment of logic to another system.)


Mapping the stuff inside the driver would mean that the generic field and enumerated value names are what get used, but that the driver can allow you to control a bit what those things link to within the driver (again see discussion below.)

Cons

1. No mapping of fields to user specific names
2. A bit more complexity in the driver

Pros

1. Far less complexity throughout the system, i.e. trades off a little complexity in the driver for far less overall.
2. Allows for better mapping of internal information
3. Makes logic redeployment to another system AND device swapping within the same system easy.



Mapping Above

You map the field name DigIn001 to MyGarageDoor, or you map Source01 to DTVBox in the mapping above. That's fine, and it allows for nice user friendly names. But it also means that if you write logic based on that, it's no more portable than logic is now, because all of the field names are customized to your system. The person receiving the logic would have to figure out all your mappings and do the same, and what if he used logic from multiple people who had different mappings? So the whole redeployment thing gets whacked, and that's one of the key reasons for doing this, maybe the key reason for pros.

Also, yeh, you can map Source01 to DTV box. But what about things like audio modes on an A/V receiver. These cannot be exposed as is. They could be exposed as Mode1, Mode2, etc... and remapped using the same scheme to things like Stereo Music, 5.1. Movie, etc... But the thing is, what you really want to do here is control what either Mode1 or Stereo Music maps to on the device. These devices will have way more modes than can actually be exposed generically. So you want to be able to control that Mode2 or 5.1. Movie actually maps to the device's "DD 5.1 Enhanced" or whatever it is.

That can't be done through mapping above the driver. It can only be mapped within the driver by the driver presenting all the possible values the device can support, and allowing you to map the the generic names to the specific modes you want to support.

If you do it this way, then yes you have to write your logic in terms of generic field names (in some cases, such as digital I/O where there are lots of them and that kidn of thing) and in terms of generic source names, audio mode names, etc... And yeh, that's kind of a bummer. But it means that you get complete redeployment capability in terms of the logic, and all you have to do is provide some internal driver mapping to make the logic do what you want it to do exactly.

This could apply to even things like an Elk or Omni where you have a big list of, say, lighting points called Unit001, Unit002, the internal mapping can actually make those mapp to any actual unique number. So the logic is written in terms of Unit001, Unit002, but those might get mapped to Unit087 and Unit088 in a given system.

So, there still a need to have some understanding of the mappings that were used in some cases when you want to redeploy logic, but it's a lot easier than the above the driver mapping where you also might have to do extensive search and replace to get the field and enumerated values remapped to your local mappings. In this inside the driver mode, the mapping is limited completely to the driver, and nothing outside the driver is affected.


Ultimately, it seems to me that the inside the driver mapping is the only one that makes sense. For the professional, it allows for the creation of a generic set of logic, and the documentation of the mappings thereof. Given that, you can take that logic and deploy it on other hardware, then modify the mappings in the drivers and that's it. You don't have to touch the actual logic. Of course I could simplify this by providing a tool to extract all the mappings and dump them out to a formatted file, HTML or CSC or whatever, with space to fill in comments of your own. And it would also be possible to have something like the field browser dialog be able to show you the actual mapping for any given field. So, for instance, when you click the little helper button to select a value for an enumerated field it could show you the generic names and the actual values beside it in parens and that kind of thing.

I really think that this is the way it needs to go. It's the only way to really concentrate the mapping scheme into a single place. It does add some complexity for the drivers, but many drivers will have almost none of these concerns, or very few. Mostly some of them will have one or two enumerated fields that need to be remappable. Some of the enumerated fields won't need remapping at all since the generic values really are just generic names for consistently supportable actual values used by the devices. For instance I think that for a security zone, you could have Ready, Not Ready, and Violated and that would be workable for all devices, so it doesn't need to be mappable.

The driver would indicate when it sets up and registers the field that it's a mappable field, and would have have to provide upon request the full list of values the field can be mapped to, so that the mapping interface provided by the Admin Intf could generically figure out which fields are mappable and to what.

Anyhoo, that's what my creaking brain has been churning out in the last day or so as I really have been thinking hard about this. It really needs to be right befor I commit else it'll be a huge pain to change it later.

[wuench]

What if you look at it like this. You need an interface to connect action references to field names and values. Not necessarily a new driver model system. The driver model system would simplify things further.

So the interface could be something like:

1.) a list of action references on the left
2.) a list of driver fields on the right
3.) You simply need to connect one with the other (of the proper type).
4.) For the ENUM values you could just popup a list when a connection is made (of via clicking an existing connection) to select from the possibilities.

Now layer on top of a few things to simplify this.

1.) The interface proactively identifies missing references in some way. Some sort of highlight/search/errors to tell us where the issues are.

2.) A way to reduce/simplify the driver list - this is where your new driver model system comes in. Drivers need to provide consistent fields and values where possible. But would be nice if they can provide additional fields and values if they want.

3.) A way to reduce/simplify the action reference list - You could provide alias names to the references. So in the IE when creating an interface we can create these aliases for similar type references. And/Or maybe the system can provide some common ones. Again it would be nice if the list could still show un-aliased references where they exist.

Just some general things to think about, but it seems this type of approach would make things simpler not just for new drivers/templates but even with today's setups. Maybe some additional feature could be added to see actual action code so you know the context of the action reference, or more details about what an alias actual represents, etc. Anyway just brainstorming here...

[Dean Roddey]

But the new driver model is really required to both syntactical and semantic consistency. It's not a new model per se, it's a formalization of the model that exists. By defining both the syntax of the drivers (field names, enum values, things like percents for all volumes/levels, etc...) you would get the ability to syntactically redeploy logic, but it wouldn't help since things still would work. By strictly defining the field names and what they mean and how the driver should react to them, and any mapping scheme, it allows for semantic consistency so that not only are there no syntax problems when you swap out one device for another or use someone else's media player screen or HVAC screen, but the commands actually do the same things.

And also the much greater assistance the design tools can provide when they can know exactly what a given field means, not just what it's syntactical requirements are (which it already knows now.)

[Dean Roddey]

Has anyone had issues trying to auto-start programs since we've gotten rid of the UAC stuff?

[Post]

a lot of wuench's comments sound like the setup of eventghost.
ie. add plugin, drag action to result etc.

[Dean Roddey]

a lot of wuench's comments sound like the setup of eventghost.
ie. add plugin, drag action to result etc.

I certainly am not against making actions easier to configure and such, but that's a very different subject from creating a system where devices of the same type can be swapped at will and logic can be redeployed without changes, which is what I'm really dealing with here.

And, as I've thought about the above more, I don't think that even the internal mapping scheme inside the driver will totally do it either, though it helps a lot. Any scheme in which user driven mappings can occur utimately will prevent redeployment of logic to another system as is. It will allow swapping out of hardware within the same system quite well I think, but it won't deal with redeployment.

The problem is that, if we allow, say, Source01 on the A/V Receiver device class's SourceInput field to be mapped to the 'DVD' input within the driver (so when you select Source01 the driver will tell the receiver to select its DVD input), then that leaves us with syntactical portability but not semantic portability. If I now give you a template that I created based on this mapping, but you have already mapped Source01 to Satellite on your receiver driver and written code that assumes such a mapping, then you are now stuck.

You cannot use that template as is because when you press the DVD button on my template, it's going to select the DTV input on your receiver. Is that something that ultimately would just have to be accepted? I dunno. I can't see any way around it. We can't enforce a known set of inputs because they wouldn't map to any single device, ever really. We could never foresee the types of inputs a receiver might have. I guess we could define common ones and provide a set of Aux01, Aux02 type generic sources for anything else, not likely to be a problem because they aren't often used.

But, even there, the driver can't just present the whole list, no matter how few actual inputs the receiver has. The bulk of them would not be legal for the device and it's kind of silly to present a bunch of not legal options to select from. But if it doesn't present the whole list, then we won't even have generic syntax since my template could refer to a source that your driver doesn't even provide as an option.

So I'm starting to kind of despair of really coming up with a really good solution here that's going to allow for real syntactical and semantic transparency. I think we have to just go with the generic names, with internal mapping, and sometimes you'll just have to make changes when you take logic to a new system or use someone else's provided logic.

[Mark Stega]

How about this as a possibility:

For 'swappable' driver classes have a fixed set of fields and allowable values that must be implemented, other fields and values can be made available, but the fixed set is required. If a field can’t be mapped directly it is up to the driver writer to provide manifest prompts to create the map (For example, if a receiver has source 1-5 you have to prompt for DVD1 and the answer might be Source 1, for DVD2 the answer might be None, etc.).

So taking a swat at an AV receiver we have just a few fields

MainZone:

Power – On/Standby
Mute – On/Off
Volume – 0 to 100
Source – DVD1-3, BluRay1-3, STB1-3, iPod1-3, External 7.1 1-3
Audio – Direct, Stereo, Dolby Enhanced

Secondary Zone:

Same as primary

I maintain that as an integrator that these are likely the fields that I care about in 99% of my installations and if I can freely move between receivers that support these features I probably don’t need to change my logic. If a customer insists that they must have “Cathedral” or “Stadium” or some other wacky surround mode I can add that as a special case since the driver does do its native support as well. But that won’t be portable which is OK because it is an exception.

For players (DVD, BR, STB) the commands are pretty standard (transport, menu, arrows, numbers, enter, OK, red/blue/green/yellow etc.) and shouldn’t pose a problem.

So instead of “boiling the ocean” this might be a practical way to get most of the benefits without a ton of work.

We could “consensus build” the required fields and values as each class of devices was implemented. In my example above I may have missed a really common set of inputs or surround mode but feedback from the community could correct that before implementation.

[Dean Roddey]

That's basically what I have for the 'processor' device class, modulo the enum value choices. That's a reasonable idea and it's one I've gone to and back from a few times. Part of the reason I backed away was that it doesn't deal with the 'reuse without changes' issue. But, given that it looks like, in these limited cases like this, nothing is ever going to do that and some modifications will be required, then it may be as good as any.

However, one gotcha is it inevitably means that the field provides choices that are not valid for almost every device. So you can say these are the possible forms of field names. You can use as many or as few as the device has available but they have to have names in these forms.

Either way it's a bit problematic. Either the driver offers values that it knows aren't valid, or you have inconsistent sets of selections on different devices. Certainly having the fixed set would make the internal mapping scheme easier.

[Dean Roddey]

OK, I'm working towards another drop here. There are some big changes in this one, the main one being a complete reworking of the polling engine. This has been taking a good number of days to ultimately get done, but I think it'll be well worth it. This is a core chunk of code that is behind the IV (and therefore the RIVA system) and the XML GW and a couple other things. It's been around quite a while in it's current form, since it's quite complex and seemed to be working well enough not to want to rock the boat.

But, finally I've had to give it a face lift and have improved it hugely. It should be much more efficient of network access, faster to get data, and certainly quicker when dealing with multiple CQCServers, and should almost never hold up the code that uses it anymore, whereas before in some cases things could get sluggish if there were network slowdowns and such. It is now much more asynchronous and should decouple the getting of field data from the engine itself from the (now background) activity of the engine getting data from the servers. And there were some optimizations that originally I thought I couldn't get away with, but upon further examination I can do.

So (I think) you should see smoother and quicker operations of the IV, with faster updating particularly if you have multiple servers, and it should be quicker to get the data, and to get up and running.


Another potentially big thing, though a small code change is that the ORB now looks to see if the system it is on is in a domain or not. If so, it registers server interfaces with the full TCP/IP name (what it has been doing now for some time.) If in a workgroup, it makes the call that gets the basic node name, which should not (I don't think) include any TCP/IP domain suffix.

So all of the problems that occurred when routers incorrectly include your ISP's domain suffix in the computer name reported by system calls for the local node name should in theory no longer exist. If you are in a domain, your own network suffix should be used, which is correct. If you are not in a domain, there shouldn't be any included in the basic node name so you won't be affected if at the TCP/IP level the ISP suffix is getting added.

So, in theory, you should be able to get rid of any hosts file hacks you've done to prevent this problem. Though, if you have servers that have fixed IP addresses, there's still nothing wrong with using the hosts file for more efficiency if you want to. But you shouldn't have to anymore to avoid this problem. Of course it could be that MS has changed this lower level call to also return the whole TCP/IP name these days, but I don't think that's the case. If anyone who was previously having the ISP suffix name issue wants to try this and verify after this next drop, that would be useful.


I still need to beat on the polling engine some more. It's taken a good bit longer than I'd hoped, but it's one of those things that's way too asychronous and multi-threaded to debug in any traditional way. You really have to think your way through it, and it has to be right. But it's starting to look good now.

[znelbok]

Please dont forget to add/remove that SSE thing that affected the vPads not being able to install CQC. I am waiting on the next drop to get it going again.

Mick

[Dean Roddey]

Please dont forget to add/remove that SSE thing that affected the vPads not being able to install CQC. I am waiting on the next drop to get it going again.

Mick

Yeh, I did that also.

[Dean Roddey]

Everything seems ok. Baring discovering something else, I'll get a new drop up tomorrow.

[znelbok]

Dean

Now that the next drop is out, would I be able to install the IV only on the vPad with the previous version running on every other node?

I am not really keen on doing an upgrade of the entire system.

Mick

[Dean Roddey]

Dean

Now that the next drop is out, would I be able to install the IV only on the vPad with the previous version running on every other node?

I am not really keen on doing an upgrade of the entire system.

Mick

Unfortunately, no. In order to avoid the issues that have occurred in the past when people haven't upgraded all their systems, it now checks that it's running the same version as the master server and will refuse to start up if not. I wouldn't install this version on a commercial system yet anyway. Not that it's likely to have problems, but it contains substantial changes that have not gotten beaten on by many people yet.

[znelbok]

The vPad being out of action is not going down very well........

[Dean Roddey]

The vPad being out of action is not going down very well........

Give the current drop a couple days to see if anyone has any trouble, then go ahead and move forward with it. Just be sure you can go back if you need to. There's always a certain amount of these types of risks when using beta versions.

I guess I can always take my best shot at a build of a version that should be what I think was .13, without the SSE stuff, if you would prefer that. If it's just running the IV standalone it should be reasonably safe.

[Dean Roddey]

If you want to give it a try, here's a build of a backup from that day (that .13 was built.) So, it probably is the correct stuff. Worst case you aren't in any worse a position than you are now if it doesn't work.

3.4.13 No SSE (http://www.charmedquark.com/Web2/Downloads/Installers/Beta/CQC_3_4_13_NoSSE.Zip)

[znelbok]

Will this work with 3.4.11 (IV only)? Could not go to 12 as it would not install on WHS and 13 was not out.

Also, some notes on experiences
Driver re-configuration does not appear to be working as well as it should
Ethernet based drivers appear to not be using the new IP address. They seem to use the original address.
The file tag browser does not keep the new folder location after a restart. It went back to the previous folder location.
Its an excellent feature that I would not like to lose, but at them moment it cant be trusted to make changes to a driver instance.

[Dean Roddey]

Will this work with 3.4.11 (IV only)? Could not go to 12 as it would not install on WHS and 13 was not out.

Oh, no, for the same reason. I thought you were on .13. I'm not sure if I have a backup I can reasonably safely associate with .11 or not. It might be best to just wait and move forward.

Driver re-configuration does not appear to be working as well as it should. Ethernet based drivers appear to not be using the new IP address. They seem to use the original address.

That was a problem at one time but shouldn't be now. Which specific driver? It might be an issue in the driver itself, not correctly updating.

The file tag browser does not keep the new folder location after a restart. It went back to the previous folder location.

Hmmm... That definitely should not be the case, but I'll look at it. I've had no problems with reconfiguration, so any issues are hopefully just issues in some individual drivers that did things that turned out not to be friendly to reconfiguration (since they never knew such things could ever happen when they were written.)

[Dean Roddey]

Speaking of which, is anyone using .14? Is it working well?

[DaveB]

Using it and working great so far.

I had one issue that I actually had to restart everything, but found it to be a driver setting issue.

[batwater]

Speaking of which, is anyone using .14? Is it working well?

I upgraded this morning, no new issues and nothing is showing up in the logs thus far. Also upgrade the system to IE9, damn near as fast as Chrome now, no anomalies thus far. Don't have any templates with embedded browsing at this time so don't know if that functions.

-Ben

[Dean Roddey]

The file tag browser does not keep the new folder location after a restart. It went back to the previous folder location.

I just tried this and it worked fine for me. Can you give this another try and see if it still doesn't work? Oh wait, you said after a restart, let me try that...

[Dean Roddey]

It worked after a restart as well. So, if it didn't work for you, I'd would have to assume there's an issue getting the configuration stored to the configuration server, since that seems to be the only way it wouldn't have worked. Can you give it another try and see if you still have this issue?

[znelbok]

Yep, did it again.

The test system didn't display the issue, but the installed system did. The installed system was restored from the test system as per the recomended proceedure.
Driver version 0.1

Changed the directory from \\server\My Music to \\server\music, restarted the service, and the driver still points to \\server\my music.

Both shares exist on the server as well, one has nothing, the other contains all the music.

Refresh the library after changin path and no cover art appears, so the path has been accepted. After a restart, the cover art appears and the original path is being used.

Use playlists was not checked

V3.4.13

Mick

[Dean Roddey]

That would almost have to mean that the configuration is not getting stored. Can you add/remove drivers on that machine and that works and they stick after a restart? And no error shows up in the logs when you do the reconfigure?

[znelbok]

That driver was removed and re-added when I had the problem originally to get the new location stored. The test I just perfomed was on that driver.

So No, remove and add does not make the changes stick

I will check the logs soon. Not at the console for a while

[Bauer83]

Having a major issue with .14, and I am really struggling to find out what is causing the issue to occur but here is where I have it isolated to at the moment.

When I connect with the iPad Riva App and move forward from my home screen, my whole server hangs and loses it's network connection completely. However, if I use the Remote Viewer on my server I know that I can't get it too freeze up. This is the same if I just use the normal interface viewer on my laptop.

Any ideas? The log appears to show nothing.

[Dean Roddey]

What do you mean by your whole server locks up? You mean the RIVA server or the entire CQC system or something like that? When you say the same for the regular IV, you mean the same it works fine or the same it freaks out?

[Bauer83]

What do you mean by your whole server locks up? You mean the RIVA server or the entire CQC system or something like that? When you say the same for the regular IV, you mean the same it works fine or the same it freaks out?

As in, it seems to crash the network from what I can see. I lose any RDP session I have into the server, I can no longer connect to the server in any way.

By using the IV, it means if I don't use the RIVA iPad app and just browse my templates with the normal IV prior to causing the crash, everything works fine.

[Dean Roddey]

As in, it seems to crash the network from what I can see. I lose any RDP session I have into the server, I can no longer connect to the server in any way.

By using the IV, it means if I don't use the RIVA iPad app and just browse my templates with the normal IV prior to causing the crash, everything works fine.

You mean that everything works fine even if you use the iPad app after that, or that everything works fine with the IV but it still croaks with the iPad app?

Can you try connecting with the standard RIVA client as a sanity check?

[Bauer83]

May have solved my own problem. I installed a Gigabit NIC at the same time that I upgraded CQC, and going back to the onboard LAN has solved the problem (outside of not getting Gigabit speeds).

[Bauer83]

Dean,

Is there anyway the gesture actions could have got broken in .14? My templates have not changed, and the gesture actions no longer work in the iPad RIVA app. I checked to ensure that the hot keys were still set.

[Dean Roddey]

Dean,

Is there anyway the gesture actions could have got broken in .14? My templates have not changed, and the gesture actions no longer work in the iPad RIVA app. I checked to ensure that the hot keys were still set.

That would be a question for the iPad guys, since CQC doesn't even know that gestures exist.

[Bauer83]

That would be a question for the iPad guys, since CQC doesn't even know that gestures exist.

I will put this question in the iPad app thread. However, the reason I put it here, was it worked fine on .13, so something that has changed over this version "appears" to be the breaking point on my system.

[Dean Roddey]

I will put this question in the iPad app thread. However, the reason I put it here, was it worked fine on .13, so something that has changed over this version "appears" to be the breaking point on my system.

It seems kind of unlikely since there were no changes to the RIVA system at all for .14. And no one else has complained about it yet, though you could be the first person on .14 who uses them I guess.

[batwater]

I'm getting the error below when I shut down my taRIVA client, not sure if it's due to changes in CQC 3.1.14 or taRIVA .99, but it's there now...

03/20 10:32:21-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr3
{
CIDSock, CIDSock_StreamSocket.cpp.692, Failed/Not All Data Read, Error: 5014/0/0
Could not read or write all requested bytes
}
03/20 10:33:08-ncc1701-d, CQCServer, CIDOrbServerListener
{
CIDOrb, CIDOrb_ClientConnMgr.cpp.853, Status/App Status
The client high water mark has increased to 3
}
03/20 10:33:17-ncc1701-d, CQCServer, CIDOrbServerListener
{
CIDOrb, CIDOrb_ClientConnMgr.cpp.853, Status/App Status
The client high water mark has increased to 4
}
03/20 10:48:01-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr4
{
CIDSock, CIDSock_StreamSocket.cpp.692, Failed/Not All Data Read, Error: 5014/0/0
Could not read or write all requested bytes
}
03/20 10:48:30-Kitchen, CQCIntfView, MainThread
{
CQCKit, CQCIntfView_ThisFacility.cpp.359, Status/App Status
CQCIntfView is shutting down
}
03/20 10:50:05-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr12
{
CIDSock, CIDSock_StreamSocket.cpp.692, Failed/Not All Data Read, Error: 5014/0/0
Could not read or write all requested bytes
}

[Dean Roddey]

Maybe it's not waiting for the final acknowledgement of shutdown from the server?

[Dean Roddey]

So, in 3.4.15 I change it so that write only fields are treated like 'write always' fields automatically. That just seems like it is how it should be, but I guess I should get some opinions on that. It clearly makes sense that read/write fields need to be marked write always if that's the type of behavior you want (otherwise the driver will not be called for a write of a value that matches the current field value, avoiding unneeded activity.)

I guess it's possible that some people were depending in some way on the fact that a write only field (not marked write always) would act the same? It doesn't seem likely, and the only real complaints over time have been when such write only fields were not marked write always and so they failed to send out values repeatedly as they were intended. So I think it's the correct thing do, but I could of course undo that change if it could cause problems.

[DaveW42]

Hi Dean. Could .14 have broken category listings in the media browser? I can still see my albums and play them, but I can no longer browse them by category (that area currently appears blank on the screen).

Thanks,
Dave

[Dean Roddey]

Hi Dean. Could .14 have broken category listings in the media browser? I can still see my albums and play them, but I can no longer browse them by category (that area currently appears blank on the screen).

Thanks,
Dave

I haven't seen that myself. Do you mean the media category browser, or the new list based browser?

[DaveW42]

I believe it is the media category browser (i.e., the browser that shows genres such as rock, pop, classical, etc.). I am using Embedded File Tags as the media repository driver.

Thanks for your help!

Dave

[Dean Roddey]

I believe it is the media category browser (i.e., the browser that shows genres such as rock, pop, classical, etc.). I am using Embedded File Tags as the media repository driver.

Thanks for your help!

Dave

I've had no problems with that, and no one else has reported that either so far. Can you bring it up in the editor and make sure the settings look correct? Are you sending it any commands OnLoad or OnPreload or anything to set it up?

Oh, and I guess check up stream. If you go the field browser, is the file tag repo driver connected and does the title count look reasonable?

[DaveW42]

Thanks Dean! I checked the editor as you suggested and saw that the media category browser was using a different repository than the rest of my music collection. That older repository was associated with an older directory of files that was redundant. I had deleted the redundant directory a few days ago (around the same time I installed .14), which resulted in the media category browser not finding any information (hence my original post).

Interestingly enough, the fact that the media category browser was linked to a different repository never really caused any big problems in the past (it was like that for probably 5 or 6 months). I was still able to use the browser to filter by genre, even though it was linking to the wrong place.

Thanks again!

Dave

[Dean Roddey]

You sure you weren't setting it somewhere before in an onload command or some other place? The command might have been overriding the incorrect setting in the static configuration.

[Dean Roddey]

So I've started going through drivers and adding support for the new 'semantic field type' setting and also supporting the new standard event triggers. This will be an ongoing process but I have to start somewhere. The initial attack will be to get this stuff in place in some key drivers, in order to start working on some new assisted design tools.

[znelbok]

Is this going to break existing setups?

[Dean Roddey]

Is this going to break existing setups?

No, it's all just new stuff.

[wuench]

Did you say there was a doc out there that described this mad scheme of yours? :-) I might take a crack at adding the fields to the XBMC driver for fun in my free time...

[Dean Roddey]

Did you say there was a doc out there that described this mad scheme of yours? :-) I might take a crack at adding the fields to the XBMC driver for fun in my free time...

Not yet. Well, there are a few layers involved.

1. Semantic field types. This just marks fields as having some sort of semantic meaning, light switch, current temp, volume control, etc... This is something that any driver will be able to do. It will be used to generate user interface content mostly, since it will allow the intf. designer to allow you to create widgets for these types, which means it knows then what the widget will actually do, not just what it should look like.

2. Standard event triggers. There are standard event triggers now for zone status changes, lighting load off/on changes, and motion sensor changes. These are sent automatically by drivers that implement them, so no configuration is required, and since they standardized, it will allow for more resonable exchange of triggered events.

3. Device classes. This is the highest level but it's something we won't immediately expose, because it's the hardest to define and we need to have some time to try it out ourselves to try to get them right. Once we expose this and people start using it, making changes will be brutal.

And, whereas the above stuff doesn't really require any breaking changes, this will. It will either require a completely new driver for the device, or for the driver to provide two modes, one maintaining the old field names and characteristics, and one that implements the device class specific fields.

It's kind of unfortunate, since it'll mean still more new drivers will be written by people not to the new scheme. But until the new scheme is fully solidified, it wouldn't be possible for them to use it.


So anyway, the semantic field type stuff and standard event triggers we will document for everyone to use as part of the 4.0 release, and both existing drivers and any new ones written to the device class scheme will be able to use them.

[Dean Roddey]

Anyone try the 'TTS via the IV' stuff yet?

[zaccari]

Anyone try the 'TTS via the IV' stuff yet?
I'll try to play with it tonight. It was in .15, right?

Russ...

[Dean Roddey]

I'll try to play with it tonight. It was in .15, right?

Russ...

Yeh, the latest beta version, which is .15.

[Dean Roddey]

You can tell it's spring in the US. Everyone disappears for the weekends now :-)

[DaveB]

Yea - Lots of yardwork to do! I think that all the neighbors threw there branches in my yard!

[znelbok]

I just upgraded to .15 and the file tag browser is generating errors
04/04 19:46:22-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13

04/04 19:53:02-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_DriverBase.cpp.2804, Status/App Status
Driver 'UberMP3' is beginning initialization
}

04/04 19:53:02-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_ThisFacility.cpp.308, Failed/Data Format, Error: 5900/0/0
Boolean values must be True/False or 1/0
}

04/04 19:53:02-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_DriverBase.cpp.3285, Failed/Initialization
An exception occured during driver initialization. Check the logs
}

04/04 19:53:02-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_DriverBase.cpp.2877, Status/App Status
Driver UberMP3 returned failure status on initialization
}

04/04 19:53:12-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_DriverBase.cpp.2804, Status/App Status
Driver 'UberMP3' is beginning initialization
}

04/04 19:53:12-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_ThisFacility.cpp.308, Failed/Data Format, Error: 5900/0/0
Boolean values must be True/False or 1/0
}

04/04 19:53:12-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_DriverBase.cpp.3285, Failed/Initialization
An exception occured during driver initialization. Check the logs
}

04/04 19:53:12-zeus.calderwood.net, CQCServer, CQCDrv_UberMP3_Thread13
{
CQCKit, CQCKit_DriverBase.cpp.2877, Status/App Status
Driver UberMP3 returned failure status on initialization
}


Made the system very unstable as well. It halted there for a while.

Mick

[Dean Roddey]

The only place I could see how that could happen in that driver is that there is a prompt for whether to use playlists or not, and that prompt having an invalid value in it somehow. This may have been something to do with your issue with reconfiguration or something before, I dunno. Try doing a reconfigure on it and see if that makes it happy.

[DaveB]

Dean - I am on .16 and my system has developed some time out errors with Squeezebox that I did not previously have. See below. Server always auto-recovers from the error and continues on with a gap in the playback of sometimes several minutes. Everything is on the same machine. I am trying to figure out is this is a driver issue due to the latest changes. I am using SB Beta version 3.62.

04/03 22:06:34-GIGA, CQCIntfView, CQCRunActionThread_Thread0
{
CIDOrb, CIDOrb_ClientBase.cpp.792, Failed/Timeout, Error: 1008/0/0
The server at 192.168.15.12:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy
}
04/03 22:07:50-GIGA, CQCIntfView, MainThread
{
CIDLib, CIDLib_Thread.cpp.2003, Failed/Timeout, Error: 2470/13/0
Timed out waiting for thread CQCRunActionThread_Thread0 to sync
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CIDMacroEng, CIDMacroEng_MethodImpl.cpp.950, Status/App Status
An unknown exception was thrown from method MEng.System.Runtime.StreamSocket.WriteBuffer
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.114, Status/App Status
An unknown exception occured during macro execution
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.152, Status/App Status
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.SendMsg([InOut] MEng.System.Runtime.StreamSocket Socket,[In] MEng.String ToSend) Returns MEng.Void
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.SendCommand([InOut] MEng.System.Runtime.StreamSocket Socket,[In] MEng.String Command,[In] MEng.String Params) Returns MEng.Boolean
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.GetServerVersion([Out] MEng.String Version) Returns MEng.Boolean
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Drive rImpl.Connect() Returns MEng.System.CQC.Runtime.CQCDriverBase.CommResults

}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CIDMacroEng, CIDMacroEng_MethodImpl.cpp.950, Status/App Status
An unknown exception was thrown from method MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.SendMsg
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.114, Status/App Status
An unknown exception occured during macro execution
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.152, Status/App Status
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.SendCommand([InOut] MEng.System.Runtime.StreamSocket Socket,[In] MEng.String Command,[In] MEng.String Params) Returns MEng.Boolean
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.GetServerVersion([Out] MEng.String Version) Returns MEng.Boolean
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Drive rImpl.Connect() Returns MEng.System.CQC.Runtime.CQCDriverBase.CommResults

}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CIDMacroEng, CIDMacroEng_MethodImpl.cpp.950, Status/App Status
An unknown exception was thrown from method MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.SendCommand
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.114, Status/App Status
An unknown exception occured during macro execution
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.152, Status/App Status
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.GetServerVersion([Out] MEng.String Version) Returns MEng.Boolean
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Drive rImpl.Connect() Returns MEng.System.CQC.Runtime.CQCDriverBase.CommResults

}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CIDMacroEng, CIDMacroEng_MethodImpl.cpp.950, Status/App Status
An unknown exception was thrown from method MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Proto Lib.GetServerVersion
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.114, Status/App Status
An unknown exception occured during macro execution
}
04/03 22:07:58-GIGA, CQCServer, CQCDrv_Audio1_Thread6
{
CQCKit, CQCKit_MEngErrHandler.cpp.152, Status/App Status
MEng.User.CQC.Drivers.Logitech.SqueezeCenter.Drive rImpl.Connect() Returns MEng.System.CQC.Runtime.CQCDriverBase.CommResults

}
04/04 11:46:48-GIGA, CQCClient, MainThread
{
CQCKit, CQCClient_ThisFacility.cpp.213, Status/App Status
CQCClient is starting up. Version=3.4.16
}

[Dean Roddey]

Dean - I am on .16 and my system has developed some time out errors with Squeezebox that I did not previously have. See below. Server always auto-recovers from the error and continues on with a gap in the playback of sometimes several minutes. Everything is on the same machine. I am trying to figure out is this is a driver issue due to the latest changes. I am using SB Beta version 3.62.

Can you look in the Logs directory on the system where the driver is running and see if there are any ErrorInf files from CQCServer? If so, send them to me. If not, we can force them to happen if you can still replicate the problem.

[znelbok]

The only place I could see how that could happen in that driver is that there is a prompt for whether to use playlists or not, and that prompt having an invalid value in it somehow. This may have been something to do with your issue with reconfiguration or something before, I dunno. Try doing a reconfigure on it and see if that makes it happy.

I removed the driver and re-added it and it stop creating errors. We need to have some way of dumping triggers out so that when this happens we dont have to spend hours setting them up again.

Also, the IV driver wont connect now. Have also removed and re-added it but wont connect. What do I need to do to have it connect (used to have a port number in the shortcut)

Have I said I hate upgrades.

Mick

[DaveB]

Can you look in the Logs directory on the system where the driver is running and see if there are any ErrorInf files from CQCServer? If so, send them to me. If not, we can force them to happen if you can still replicate the problem.

There are none and I think that I can replicate the problem any time. Let me know how to force the logs when you have a chance.

[Dean Roddey]

I removed the driver and re-added it and it stop creating errors. We need to have some way of dumping triggers out so that when this happens we dont have to spend hours setting them up again.

Something obviously went awry back when you had that problem with the reconfig I think. Not sure what it was, and probably too late now to figure it out. But keep an eye on it.

Also, the IV driver wont connect now. Have also removed and re-added it but wont connect. What do I need to do to have it connect (used to have a port number in the shortcut)

Put it into verbose mode and see what it's complaining about. Always the first step. The IV control protocol was changed to support the TTS via the IV, so if you somehow managed to get mixed versions or something like that, it could be an issue for sure. Is this still a single machine configuration? I did load it and test it after making those changes and it seemed happy for me. I only tested the TTS parts of it, but still it had to connect to do that.

There should be a port number on the command line certainly in the start menu. Are you sure you didn't add that manually? If so, then it would make sense that it would go away because it's supposed to be added via the installer when you enable the control interface during an install/upgrade. If you do it there, then it won't go away anymore, or it shouldn't anyway.

[Dean Roddey]

There are none and I think that I can replicate the problem any time. Let me know how to force the logs when you have a chance.

Open the CQC Command Prompt and do this:

CIDLogAdmin settracethresh /CQC/CQCServers/CoreAdmins/XXX Failed

where XXX is the name of the host on on which the driver is running. I think I have that right. Let me know if it complains. If it doesn't, then it should have set it. Make the problem occur and check the for an errorinf file. If you don't see one, let me know. If you do, then do the same command again, but the value should be ProcFatal instead of Failed, to put it back to the default.

[znelbok]

Something obviously went awry back when you had that problem with the reconfig I think. Not sure what it was, and probably too late now to figure it out. But keep an eye on it. This particular driver was never reconfigured - that was on another system

Put it into verbose mode and see what it's complaining about. Always the first step. The IV control protocol was changed to support the TTS via the IV, so if you somehow managed to get mixed versions or something like that, it could be an issue for sure. Is this still a single machine configuration? I did load it and test it after making those changes and it seemed happy for me. I only tested the TTS parts of it, but still it had to connect to do that.
In verbose mode it just says, Trying to conenct. There is no useful information at all pushed to the log server for that driver (first thing I checked). If it had reported anything other than trying to connect, I would have posted it earlier.

There should be a port number on the command line certainly in the start menu. Are you sure you didn't add that manually? If so, then it would make sense that it would go away because it's supposed to be added via the installer when you enable the control interface during an install/upgrade. If you do it there, then it won't go away anymore, or it shouldn't anyway.
This system was built when the port number had to be manually added to the shortcut command, so yes the port number is there. It has never been a problem up until now, so something has definately changed.
I have launced the IV from both the shortcut in startup and from the new shrtcut created by the installer in Charmed Quark on the start menu, with no joy from either.
I will re-run the installer on this machine and make sure the box is checked as I only ran an upgrade.
This is on a seperate machine to the MS, its a PC running a touch screen and I use the keyboard shortcuts for control over the IV (amongst other things)

On a side note, it may be beneficial to have as part of the install a window for setting up the IV, such as run full screen, kiosk mode etc, so that the shortcut does not have to be manually altered to get these options working.
Also, security in running the IV could be upped a bit instead of using plain text in the environment variables - maybe store it encrypted in the app itself. As part of the setup above, prompt for an account to be used for the IV.

Mick

[DaveB]

Open the CQC Command Prompt and do this:

CIDLogAdmin settracethresh /CQC/CQCServers/CoreAdmins/XXX Failed

where XXX is the name of the host on on which the driver is running. I think I have that right. Let me know if it complains. If it doesn't, then it should have set it. Make the problem occur and check the for an errorinf file. If you don't see one, let me know. If you do, then do the same command again, but the value should be ProcFatal instead of Failed, to put it back to the default.

Dean - I attempted server name { GIGA } and IP Address of the server and both failed. See below;


C:\Program Files\CQC\Bin>CIDLogAdmin settracethresh /CQC/CQCServers/CoreAdmins/G
IGA Failed
An exception occured:
04/04 20:53:39-GIGA, CIDLogAdmin, MainThread
{
CIDOrbUC, CIDOrbUC_ThisFacility.cpp.187, Failed/Not Found, Error: 6002/0/0
The Core Server Admin interface at binding '/CQC/CQCServers/CoreAdmins/GIGA'
could not be contacted
}

C:\Program Files\CQC\Bin>CIDLogAdmin settracethresh /CQC/CQCServers/CoreAdmins/1
92.168.15.12 Failed
An exception occured:
04/04 20:54:36-GIGA, CIDLogAdmin, MainThread
{
CIDOrbUC, CIDOrbUC_ThisFacility.cpp.187, Failed/Not Found, Error: 6002/0/0
The Core Server Admin interface at binding '/CQC/CQCServers/CoreAdmins/192.1
68.15.12' could not be contacted
}

C:\Program Files\CQC\Bin>

[Dean Roddey]

Run this command:

CIDNSAdmin Dump

Look through the nested scopes, starting at CQC, then CQCServer, then CoreAdmins. One of the entries will be for that machine and will indicate in the binding name what you should use for the XXX part. It may include a domain suffix or something.

[DaveB]

Run this command:

CIDNSAdmin Dump

Look through the nested scopes, starting at CQC, then CQCServer, then CoreAdmins. One of the entries will be for that machine and will indicate in the binding name what you should use for the XXX part. It may include a domain suffix or something.

Unless I am missing the obvious, the server name is GIGA. You agree?


C:\Program Files\CQC\Bin>CIDNSAdmin Dump
Scope=Root '$Root$'
{
Scope=CIDLib 'CIDLib Scope'
{
Scope=CIDLogSrv 'CIDLib Log Server Scope'
{
Binding=CoreAdmin 'Log Server Core Admin Object'
Binding=LogObj 'CIDLib Log Server Logger Object'
}
Scope=CIDNameSrv 'CIDLib Name Server Scope'
{
Binding=CoreAdmin 'CIDLib Name Server Core Admin Object'
}
Scope=CfgSrv ''
{
Scope=GIGA ''
{
Binding=CoreAdmin 'Cfg Server Core Admin Object'
Binding=RepoObj 'CIDLib Config Respository Object'
}
}
}
Scope=CQC ''
{
Scope=CQCAppShell ''
{
Binding=GIGA 'Could not find message'
}
Scope=CQCDataServer ''
{
Binding=CoreAdmin 'CQC Data Server Core Admin Object'
Binding=GlobActServerObj 'CQC Global Action Server Object'
Binding=IRServerObj 'CQC IR Device Model Repository Server Object'
Binding=InstServerObj 'CQC Installation Server Object'
Binding=IntfServerObj 'CQC Interface Server Object'
Binding=MacroServerObj 'CQC Macro Server Object'
Binding=SecurityServerObj 'CQC Security Server Object'
}
Scope=CQCEventSrv ''
{
Binding=CoreAdmin 'Scheduled Event Server Core Admin Object'
Binding=EventServerObj 'Scheduled Event Server Protocol'
}
Scope=CQCGWServer ''
{
Scope=CoreAdmins ''
{
Binding=GIGA 'CQC Gateway Server Core Admin Object'
}
}
Scope=CQCRemVServer ''
{
Scope=CoreAdmins ''
{
Binding=GIGA 'CQC Remote Viewer Server Core Admin Object'
}
}
Scope=CQCServer ''
{
Scope=Admins ''
{
Binding=GIGA 'CQC Admin interface on Host GIGA'
}
Scope=CoreAdmins ''
{
Binding=GIGA 'CQC Server Core Admin Object'
}
Scope=Drivers ''
{
Binding=Audio1 'GIGA'
Binding=CallerID 'GIGA'
Binding=Horoscopes 'GIGA'
Binding=Host_Mon 'GIGA'
Binding=IVTimers 'GIGA'
Binding=IrrigationScheduler 'GIGA'
Binding=Logic 'GIGA'
Binding=Media1 'GIGA'
Binding=NWSAlert 'GIGA'
Binding=Player1 'GIGA'
Binding=RSSReader 'GIGA'
Binding=Run_Timer 'GIGA'
Binding=Security 'GIGA'
Binding=Speech 'GIGA'
Binding=Text_Pager 'GIGA'
Binding=Timer1 'GIGA'
Binding=Variables 'GIGA'
Binding=Weather 'GIGA'
Binding=Weather2 'GIGA'
Binding=XMChannelInfo 'GIGA'
Binding=iTunes1 'GIGA'
}
}
Scope=CQCWebServer ''
{
Scope=CoreAdmins ''
{
Binding=GIGA 'CQC Web Server Core Admin Object'
}
}
Scope=CQSLRepo ''
{
Scope=Media1 ''
{
Binding=MgrIntf 'CQSLRepo mgmt interface for Media1'
}
}
Scope=LogicServer ''
{
Binding=CoreAdmin 'CQC Logic Server Core Admin Object'
Binding=LogServerObj 'CQC Logic Server'
}
Scope=MSCfg ''
{
Binding=CfgRepoObj 'Alt CIDLib Config Respository Object'
}
}
}
C:\Program Files\CQC\Bin>

[Dean Roddey]

Oh, it's CQCServer, not CQCServers, as per the set of nested scopes. That was a typo on my part, so it's

/CQC/CQCServer/CoresAdmins/GIGA

Sorry about that.

[DaveB]

It worked. Now I just need to make it fail. Once it does, I will post some information.

Thanks for the assist.

[DaveW42]

I've had no problems with that, and no one else has reported that either so far. Can you bring it up in the editor and make sure the settings look correct? Are you sending it any commands OnLoad or OnPreload or anything to set it up?

Oh, and I guess check up stream. If you go the field browser, is the file tag repo driver connected and does the title count look reasonable?


Dean,

I have been swamped and so it has taken me awhile to get back to you regarding your question (sorry). I checked and there weren't any commands in OnLoad or OnPreload.

Unfortunately I am still having problems accessing my music library (still on .14). I can see the categories/genres now, and all my album art appears, but none of the music actually plays when I queue up an album. As soon as I select an album, I can see the tracks get added to the playlist count, and then the count slowly cycles down to zero (i.e., it tries each file, fails, and then moves to the next one until it has tried all items on the list). Since znelbok has also now posted an issue with the media tag repository, I wonder if something perhaps went wrong with this repository type in the recent beta releases. If I try a different program (e.g., J River), I can access all of those files and play them.

I should note that things were working fine at first, but then I needed to reboot the machine. When CQC loaded after the reboot it didn't load any of the albums when I called up the media browser. I checked the driver associated with the media browser, and it referenced an old media repository (the same one that my category browser had mistakenly referred to). I updated the repository reference and told it to reload, and that got me to the current state. I am definitely a newbie at this (I am sure I have improper references to CQC lingo in this post), but I am now wondering if one of the contributing issues might be that the update to .14 somehow swapped which repository was being referenced by the media browser (and perhaps the media category browser also). It is possible that I made the mistake once with a referenced repository (i.e., for the category browser), but I seriously doubt that I would have made that mistake twice ... if that were the case I would never have seen any of the new albums that I added recently (recall from my previous post that I recently deleted an old directory of music files which the outdated repository was tied to). In recent months I only added music files to my primary directory (I did not add them to both places), so if my repository reference was wrong I would never have been able to view those albums (and I was previously able to view them and play them back).

By the way, I do like the addition you have made to allow the user to see a categorized view of the device drivers (i.e., you can now see which drivers are media repository drivers, for example). I think this will help new users to understand which options are available.

Thanks,
Dave

[Dean Roddey]

Dean,

I have been swamped and so it has taken me awhile to get back to you regarding your question (sorry). I checked and there weren't any commands in OnLoad or OnPreload. Dave

If the files are loading but not playing, then that's most likely an issue with accessing network files from the background. This is something that can change based on security updates to Windows over time. It tries to access the file, can't because it's not allowed to due to security settings, and moves to the next one.

If you haven't done so already, create a new administrative account, call it CQCUser or some such thing, and set up the CQC service to log in using that account. Then restart the machine and see if that makes it happy.

[Dean Roddey]

So we've been thinking about the next steps forward, and I think that what's going to happen is:

1. I'll do a prefab small system, based on the simulator drivers that shipped with the product. It'll be an installation option. Since it'll use the simulators, it'll work out of the box without any configuration required (other than the automatic installation of the drivers and maybe some triggered/scheduled events.) I'll probably improve those simulator drivers a bit (not the one used in the videos but the ones that simulate specific types of devices) to make the resulting system more realistic.

It'll come with some documentation and maybe a video, showing how it all works, both as a how to guide and to familiarize people with it who want to take it and move it forward to use their own hardware.

2. I'll get the 'Theme' system back into the interface designer, but better than it used to be. There'll be a New -> Theme -> menu in the designer's popup menu, and you'll be able to pick things like light switch, dimmer, volume control, etc... and it'll use the new semantic field type to present you with the fields that makes sense for such a thing, and then generate the appropriate widget for the type you've chosen, applying a themed look to it. There'll probably only be a couple themes at first (one of which will be for the system from #1.)


Those will both be quite useful improvements, and will also set the stage for some more things beyond that. The theme thing will be implemented in a support library that can later be used for automatic generation of solutions based on configuration, not just in the designer itself, for instance.

[znelbok]

Checked another install that I upgraded and it had problems with the file tag browser as well - same errors as before

"Boolean values must be True/Flase or 1/0"

Unloading and re-loading fixed the issue, but it should not come to that

Mick

[Dean Roddey]

Checked another install that I upgraded and it had problems with the file tag browser as well - same errors as before

"Boolean values must be True/Flase or 1/0"

Unloading and re-loading fixed the issue, but it should not come to that

Mick

OK, I'll check it. Maybe something got hosed somehow. There was a new prompt added for whether you want to use playlists or not. And there was a change to fault in a default value for any new prompts during a reconfigure. But this is an upgrade. I wonder if I forgot to change the name of the new prompt or something, so that it has the name of a previous one that I copied. That could maybe explain it. Anyway, I'll look. I checked that driver is correctly checking for the prompt to be present before trying to covert the value to a boolean, so it's not just a simple failure to check for a newly added prompt that might not be there in an already installed driver.

What version do you know you can whack it when you upgrade from? I can try that particular version.

[znelbok]

I upgraded from 3.3.23 and the other install was 3.4.11

Mick

[Dean Roddey]

On a side note, it may be beneficial to have as part of the install a window for setting up the IV, such as run full screen, kiosk mode etc, so that the shortcut does not have to be manually altered to get these options working.

I've added code for the installer to look for a previous instance of the IV start menu entry and to see if any of the optional parms are set. If so, it'll remember them and put them back on the new one.

Also, security in running the IV could be upped a bit instead of using plain text in the environment variables - maybe store it encrypted in the app itself. As part of the setup above, prompt for an account to be used for the IV.

Mick

It really shouldn't matter. You should really only use Limited type accounts in that sort of kiosk style client. Even if they look up the username and password, they can't get to anything they didn't already have access to by it's being used in the environment. Limited users can only open the IV and access the template set in the user account. They can't access anything else.

[znelbok]

It really shouldn't matter. You should really only use Limited type accounts in that sort of kiosk style client. Even if they look up the username and password, they can't get to anything they didn't already have access to by it's being used in the environment. Limited users can only open the IV and access the template set in the user account. They can't access anything else.
That's assuming that people set up the IV to run in limited - I am sure there are many that have them running as admin.

What if there is a node that is IV and other (such as I do here). If I set the environment variable then the admin password is available in plain text. There is no option for logging over an existing user with higher privileges should it be needed.

I still believe regardless of user level that having the password as plain text is insecure

[Dean Roddey]

That's assuming that people set up the IV to run in limited - I am sure there are many that have them running as admin.

Not much we can do if they do that kind of thing. Even if the password was hidden, they could open any templates from that client and do anything that any available template allowed them to do. So it really wouldn't be safe to do that even if the username/password wasn't exposed.

What if there is a node that is IV and other (such as I do here). If I set the environment variable then the admin password is available in plain text. There is no option for logging over an existing user with higher privileges should it be needed.

If you set up a limited user in the environment, and you then try to run a program that cannot be run by a limited user, all of them other than the IV (or the RIVA client which is the same thing basicaly), then it should prompt you for a log in, so you can provide the required administrative (or higher level) account.

I still believe regardless of user level that having the password as plain text is insecure

I don't think it's much of an issue in this case. The reason being that the only thing that can be done with the limited user account is what you are already allowing anyone to do when you have an open kiosk style client. They can already walk up to that kiosk and do anything that the template allows them to do.

If they got the user name/password, all they'd be able to do is run the same template from somewhere else in the network, which they don't even need to do since it's already running on the openly available kiosk client.

That's really why the 'Limited' level of user was provided, since this is a common thing.

[Dean Roddey]

OK, I've tested out the IV optional parameters retention stuff and corrected the faulting in of new driver prompts as well, so both of those issues should be taken care of.

[znelbok]

Dean

Ever since I upgraded to 3.4.15, my Riva server has gone to crap.

The iPhone takes ages to (re)connect or comes back with lost connection, the droid most often does not connect, but if it does it takes up to a munite

The logs are not showing anything. Some times they have maybe one error message, but often nothing at all.

How do I start trouble shooting this. It was great before I upgraded, the iPhone connected quickly and did what it should have done without fuss.

Mick

[Dean Roddey]

What version of the iPhone client are you using? We've been making adjustments and you may need the latest version to work completely happily with recent beta versions.

If there is an error, what is the error info?

As always, use the standard RIVA client from a wired client to as a sanity check. If it works fine from there, then that kind of points to certain things. If it has problems as well, then it kind of points to other things.

If you are using any sort of hosts file lookup scheme on the RIVA client, be sure and check it of course. One thing that changed is the use of simple Netbios level names for non-domain based systems, whereas before the TCP/IP name was used. This hopefulyl avoids the common problem of routers putting the ISP's suffix on host names when not in a local domain. But if you set up a manual DNS lookup on any clients it might have affected that perhaps.

[potts.mike]

It works fine for me although I'm not on the latest beta.

[DaveW42]

If the files are loading but not playing, then that's most likely an issue with accessing network files from the background. This is something that can change based on security updates to Windows over time. It tries to access the file, can't because it's not allowed to due to security settings, and moves to the next one.

If you haven't done so already, create a new administrative account, call it CQCUser or some such thing, and set up the CQC service to log in using that account. Then restart the machine and see if that makes it happy.

Thanks, Dean! I can now playback most of the music in my collection, and the specific files that I can't play are the ones I wasn't able to play previously (e.g., some mp3 files I purchased from Amazon). For those nonworking files, how do you recommend I go about troubleshooting them? Is this a codec issue? Thanks again for all your help.

Dave

[Dean Roddey]

Thanks, Dean! I can now playback most of the music in my collection, and the specific files that I can't play are the ones I wasn't able to play previously (e.g., some mp3 files I purchased from Amazon). For those nonworking files, how do you recommend I go about troubleshooting them? Is this a codec issue? Thanks again for all your help.

Dave

I don't know what would be the issue with those. It might be a codec thing certainly, but it's always a little dangerous to start messing with the codecs unless you are sure you know what you are doing. You can make it worse and have a hard time getting it back to where it was.

Do they play directly in a player ok?

[Dean Roddey]

Dean

Ever since I upgraded to 3.4.15, my Riva server has gone to crap.

The iPhone takes ages to (re)connect or comes back with lost connection, the droid most often does not connect, but if it does it takes up to a munite

The logs are not showing anything. Some times they have maybe one error message, but often nothing at all.

How do I start trouble shooting this. It was great before I upgraded, the iPhone connected quickly and did what it should have done without fuss.

Mick

Did you ever figure anything out on this one?

[znelbok]

I wont get to this until at least Sunday now. I am on Holidays next week so I can devote some time to looking at it. I have a spare PC that I can load the riva client on for testing (may even get to that tonight as its my only night at home through the week), so I will report back then

As far as I know I am on the latest IoS Riva client and the latest Android Riva Clinet.
Mick

[DaveW42]

I don't know what would be the issue with those. It might be a codec thing certainly, but it's always a little dangerous to start messing with the codecs unless you are sure you know what you are doing. You can make it worse and have a hard time getting it back to where it was.

Do they play directly in a player ok?

Yes, the files do play back fine using both J River and Windows Media Player on the CQC server computer. Is this maybe a DirectShow issue? It is definitely odd ... for example, I have purchased maybe about 10 of those inexpensive '99 most essential classical music' samplers on Amazon, and I would say about 50% work and 50% do not.

Dave

[Dean Roddey]

Yes, the files do play back fine using both J River and Windows Media Player on the CQC server computer. Is this maybe a DirectShow issue? It is definitely odd ... for example, I have purchased maybe about 10 of those inexpensive '99 most essential classical music' samplers on Amazon, and I would say about 50% work and 50% do not.

Dave

CQC uses the default filter graph that DirectShow builds, whereas those other programs may be more adventurous. You can always download Graphedt.exe and see what the default graph is, then use it to poke into what another player has set up.

[znelbok]

What version of the iPhone client are you using? We've been making adjustments and you may need the latest version to work completely happily with recent beta versions.

If there is an error, what is the error info?

As always, use the standard RIVA client from a wired client to as a sanity check. If it works fine from there, then that kind of points to certain things. If it has problems as well, then it kind of points to other things.

If you are using any sort of hosts file lookup scheme on the RIVA client, be sure and check it of course. One thing that changed is the use of simple Netbios level names for non-domain based systems, whereas before the TCP/IP name was used. This hopefulyl avoids the common problem of routers putting the ISP's suffix on host names when not in a local domain. But if you set up a manual DNS lookup on any clients it might have affected that perhaps.

Got home tonight and could not connect. Found this in the logs (shortened version)

04/14 21:14:25-zeus.calderwood.net, CQCRemVSrv, CQCRemVSrvWThr14
{
CQCKit, CQCKit_FldInfoCache.cpp.615, Failed/Not Ready
Driver PowerCosting is registered but cannot be accessed. Check firewall on host zeus.calderwood.net
}

04/14 21:14:28-zeus.calderwood.net, CQCRemVSrv, CQCPollEngPollThread0zeus.calderwood.net
{
CIDOrb, CIDOrb_ClientBase.cpp.792, Failed/Timeout, Error: 1008/0/0
The server at 192.168.0.2:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy
}

04/14 21:14:28-atlas.calderwood.net, CQCIntfView, CQCPollEngPollThread0zeus.calderwood.net
{
CIDOrb, CIDOrb_ClientBase.cpp.792, Failed/Timeout, Error: 1008/0/0
The server at 192.168.0.2:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy
}

04/14 21:14:29-atlas.calderwood.net, CQCClient, TVarDriverCWndPollThread_Thread1
{
CIDOrb, CIDOrb_ClientBase.cpp.792, Failed/Timeout, Error: 1008/0/0
The server at 192.168.0.2:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy
}

04/14 21:14:29-atlas.calderwood.net, CQCClient, TVarDriverCWndPollThread_Thread3
{
CIDOrb, CIDOrb_ClientBase.cpp.792, Failed/Timeout, Error: 1008/0/0
The server at 192.168.0.2:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy
}

04/14 21:14:29-atlas.calderwood.net, CQCClient, TIRClientWndPollThread_Thread0
{
CIDOrb, CIDOrb_ClientBase.cpp.792, Failed/Timeout, Error: 1008/0/0
The server at 192.168.0.2:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy
}


Restarted the service and its all gone downhill from there. I cant even get a driver to connect or show now on the main IV (not a Riva client, but a real client).

Ran CQCNettest and nothing abnormal showed up unfortunately (output attached) so I dont know why I keep getting the "did not reply".
The system has been 90% OK apart from the Riva stuff so I don't know if I should blame it or not. There is something funky going on though.

Maybe I should remove CQC and start again. If I back it up and then re-install it will all the triggers be kept? I probably have about two hours of documenting how its set up before I can attempt a rebuild of CQC (not the server - that's a full weekend job plus more)

Mick

[Dean Roddey]

What machine is at the .02 address? It looks like, as the logs are complaining about, that the Admin Interface cannot get to it. The usual reason for that, when it can register itself with the master server, but no one else can get to it, is that the firewall on that machine is not allowing anyone to see it. Or, there is a name to address issue, so that they cannot get to it via the address it's advertising itself as. If you have used an hosts file entries, check them and try removing them.

Also of course make sure that everyone is on the same CQC version.

And start from basics and move outwards. Does the master work in terms of anything that is running locally there? You can access the logs, and can you access the various hosts with drivers running from the host admin dialog?

[znelbok]

What machine is at the .02 address? It looks like, as the logs are complaining about, that the Admin Interface cannot get to it. The usual reason for that, when it can register itself with the master server, but no one else can get to it, is that the firewall on that machine is not allowing anyone to see it. Or, there is a name to address issue, so that they cannot get to it via the address it's advertising itself as. If you have used an hosts file entries, check them and try removing them.

Also of course make sure that everyone is on the same CQC version.

And start from basics and move outwards. Does the master work in terms of anything that is running locally there? You can access the logs, and can you access the various hosts with drivers running from the host admin dialog?

.02 is the master server, so the master server cant find iteself. It is the DC for my network so there is no firewall running on this machine. This machine is very static because it sits in the background so nothing has changed wrt naming, hosts files etc, only the upgrade in CQC has created this issue

I have worked outwards. The master server just does not work well as you can see from the logs. Usually can access the logs, but not the drivers from teh admin. Once the MS settles down after a few restarts (and a bit of luck) the clients start to work (except the Riva clients, they still are problematic and seem to be the cause of the issues).

Mick

[DaveW42]

CQC uses the default filter graph that DirectShow builds, whereas those other programs may be more adventurous. You can always download Graphedt.exe and see what the default graph is, then use it to poke into what another player has set up.

Thanks, Dean. I will give it a shot. For the sake of posterity, I will note that from what I can see Graphedt.exe is found in the Windows Driver Kit (Version 7.1.0) from Microsoft's website (620MB file). I am downloading this file now.

Thanks,
Dave

[Dean Roddey]

Thanks, Dean. I will give it a shot. For the sake of posterity, I will note that from what I can see Graphedt.exe is found in the Windows Driver Kit (Version 7.1.0) from Microsoft's website (620MB file). I am downloading this file now.

Thanks,
Dave

You can typically find just the executable out there where people have pulled it out of the kit and uploaded it, but of course you need to be careful since it might just be a virus infected version waiting to trap you.

[Dean Roddey]

.02 is the master server, so the master server cant find iteself. It is the DC for my network so there is no firewall running on this machine. This machine is very static because it sits in the background so nothing has changed wrt naming, hosts files etc, only the upgrade in CQC has created this issue

If you run CQCNetTest on the master server, what happens?

It may well be that someting in the upgrade caused it, but I've learned to be cautious since it's been said so many times that nothing changed, but it turned out something had. So I just want to figure out what's going on, because starting to suspect too broadly the changes that have been made. There have been some related to trying to use NetBios names on non-domain based systems. So I'm wondering if perhaps if it's that. The net test will help with that.

Also get a name server dump for me from the MS. Open a CQC Command Prompt and do:

CIDNSAdmin > NS.Txt

and post that NS.Txt file. There's nothing dangerous in there to post. Let's see what host name the drivers are registering themselves as running on.

[znelbok]

The file I attached before is the output of the CQCNettest. ALl looks good as far as I can tell.

Will run the name server dump later when I am in front of the server

Mick

[Dean Roddey]

The file I attached before is the output of the CQCNettest. ALl looks good as far as I can tell.

Will run the name server dump later when I am in front of the server

Mick

It didn't seem to have any problems connecting to any of the servers or anything. You aren't running the Admin Intf from a short cut copied to the desktop or anything are you? That can sometimes bite people because the format has changed or something and their copy is now out of date.

[znelbok]

No I run it from the shortcut in the start menu. The system is happy at the moment, but the Riva clients are still slow to connect. That could change at any time though.

The CIDNSAdmin commnd want some extra info to run

Usage:
NSAdmin cmd [cmdopts* /NSAddr=xx /Format=xx
Cmd = Dump | Show | Make

Options depend on the command

[Dean Roddey]

Oh, sorry, it's the Dump command. Go ahead and do it but it doesn't seem likely that it's going to show any problems. CQCNetTest is showing that all the servers are correctly registering themselves with their full DNS names. So my change related to that stuf is obviously working and seeing that you are in a domain and using the full TCP/IP name.

Do you have a DHCP server running on your Windows domain server and also have one enabled on your router? Could this be the source of your issues that you are sometimes getting one and sometimes getting another?