I knew that would be the case. The issue was getting the logging such that we could see what it was timing out on. It's the SD message, which is the current input mode. It's waiting up to 4 seconds for a response. The device cannot possibly be taking that long to reply, so presumably it's just related to the number of messages being spat out during the initial connect. I'll put in more "pause'n eat messages" breaks during the startup.
Success!!, Driver is now online. Did some testing and it comes up quickly. Thanks Much.
Have you had enough of the Denon for the week/month? Not a high priority as I now can at least turn it on/off.
When I press a command button to set the Audio mode and set the source the driver goes offline.
When I just switch the source it is fine. Looks like the SetAudioMode is timing out. (MS)
04/14 23:13:55-CQC-PC, CQCServer, CQCDrv_Denon2112Thread27
{
   CQCGenDrvS, MEng.System.CQC.Drivers.Denon.Universal.AVRec.Models.AVR2112.DriverImpl.1006, Status/App Status
   Failed to get response to MS
}
04/14 23:13:55-CQC-PC, CQCServer, CQCDrv_Denon2112Thread27
{
   CQCKit, MEng.System.CQC.Drivers.Denon.Universal.AVRec.DriverBase.1801, Status/App Status
   StrFldCh: Timed out waiting for a message
}
04/14 23:13:55-CQC-PC, CQCServer, CQCDrv_Denon2112Thread27
{
   CQCKit, CQCDriver_DriverBase.cpp.7250, Status/Lost Connection
   Driver 'Denon2112' has lost connection to it's device
}
04/14 23:13:55-CQC-PC, CQCServer, CQCDrv_Denon2112Thread27
{
   CQCKit, CQCDriver_DriverBase.cpp.3502, Status/App Status
   Driver 'Denon2112' is trying to connect to its device
}
04/14 23:13:55-CQC-PC, CQCServer, CIDOrbSrvWorkThread_4
{
   CQCKit, CQCDriver_DriverBase.cpp.4469, Failed/Not Ready, Error: 906/0/0
   Driver 'Denon2112' is not currently connected to its device
     <CQCServer> CIDOrb_ThisFacility.cpp - 536
     <CQCRemVSrv> CQCKit_CQCSrvAdminClientProxy.cpp - 1945
     <CQCRemVSrv> CQCAct_StdCmdTargets.cpp - 267
}
04/14 23:13:55-CQC-PC, CQCRemVSrv, CQCRunActionThread101
{
   CQCAct, CQCAct_StdCmdTargets.cpp.274, Failed/App Status
   Failed to write to field Denon2112.SWTCH#Z1~Source
   CD
}
04/14 23:13:57-CQC-PC, CQCServer, CQCDrv_Denon2112Thread27
{
   CQCKit, CQCDriver_DriverBase.cpp.3544, Status/App Status
   Driver 'Denon2112' has connected to its device
}
_______________
Denon 3808ci, 2112ci ,Sonos, NoVo Grand Concerto, Z-Wave(Lights,Locks), Hue, SmartThings,
iPads,Tivo,Hikvision,Elk-M1,TED5000,Somfy RTS blinds+ZRTSI, Amazon Echos+Dots, Polk XRT12,
Honeywell Wi-Fi 9000, Caleo Wi-Fi Thermostats, Rainmachine
It's because the Denon isn't responding. It's such a pathetic protocol. In various scenarios it just doesn't respond. The driver assumes that something went wrong and recycles. I keep changing more and commands to just be 'send and pray' because it's impossible to guess whether it's going to respond in any given situation. That sucks because you have no way of knowing if it worked or not, and if it works it may not have completed by the time the field write returns.
In the above scenario, was perhaps the device already in that mode?
Just tested again. Seems to be that two commands are done back to back. Still happens when mode is different and actually being change. Have disabled that line in the template for now.
_______________
Denon 3808ci, 2112ci ,Sonos, NoVo Grand Concerto, Z-Wave(Lights,Locks), Hue, SmartThings,
iPads,Tivo,Hikvision,Elk-M1,TED5000,Somfy RTS blinds+ZRTSI, Amazon Echos+Dots, Polk XRT12,
Honeywell Wi-Fi 9000, Caleo Wi-Fi Thermostats, Rainmachine
(04-15-2017, 08:51 AM)Dean Roddey Wrote: If you put a pause between them does it work? Use System:: Pause() I think it is, and pause for a couple seconds between the commands.
Can you open it back up for me to try some things?
ok it is opened back up again. inserting a Pause didn't seem to work. seems to be something about the SetAudioMode. looks like half the time the SetAudioMode does not work from a command button. Seems to work every time from the driver screen.  Must be a timing thing or hard to tell if you push multiple times.
_______________
Denon 3808ci, 2112ci ,Sonos, NoVo Grand Concerto, Z-Wave(Lights,Locks), Hue, SmartThings,
iPads,Tivo,Hikvision,Elk-M1,TED5000,Somfy RTS blinds+ZRTSI, Amazon Echos+Dots, Polk XRT12,
Honeywell Wi-Fi 9000, Caleo Wi-Fi Thermostats, Rainmachine
Here's another one to try. I wasn't actually enforcing the minimum inter-message interval, which is actually quite high. Well, I was but the default was not high enough. I set the default to something likely to be reasonable, and the per-models can override it if they need more, or know they can handle less.
Of course it's still possible that they just won't respond sometimes. For instance, if it thinks that a given audio mode is meaningless for the current source, maybe it just won't respond. That's utterly stupid, but it may happen. So you may still see it cycle. If so, let me know, and I'll dump down the driver even more.
(04-15-2017, 12:00 PM)Dean Roddey Wrote: Here's another one to try. I wasn't actually enforcing the minimum inter-message interval, which is actually quite high. Well, I was but the default was not high enough. I set the default to something likely to be reasonable, and the per-models can override it if they need more, or know they can handle less.
Of course it's still possible that they just won't respond sometimes. For instance, if it thinks that a given audio mode is meaningless for the current source, maybe it just won't respond. That's utterly stupid, but it may happen. So you may still see it cycle. If so, let me know, and I'll dump down the driver even more.
Much better as it changes the SetAudioMode correctly. (see below and note disabled pause). As you had indicated looks like the driver goes off line if you are changing the SetAudioMode mode to the current mode and then comes back online.  If you are setting it to a new mode it does not go offline. I can live with this if needed because it seems to work and it only causes the Riva client buttons to disappear for 3 seconds while driver is cycling.
The issue is that audio modes are not symmetrical. Normally you have the same set of values that you write vs the values that you get back. So you have a single field for read/write. Unless you mark the field otherwise, CQC will ignore writes of the same value as the field's current value. But with the crazy lists of modes (very different written vs. read back) we have two separate fields, so it's not easy to know if we are trying to write the same value as is already set. The value you write has no relationship to the value we have read as the current audio mode.
I could wait for a short period of time for a response and, if it comes in great, if it doesn't don't assume that the connection has been lost. If it really has, the next active ping that the driver does should catch it and knock the driver off line.
ause