Dominic,

I've been trying to discuss this with various Denon team's. The USA team gave the most reponse, but even they didn't reply about the hidden commands.

Did you read the last line in the previous post? I've just edited it.

Hi sWORDS

That's exactly how I caught most of them....

Not as organized as you didn't put them in a file. If you need something specific I can look it up in the source code. Just used them as needed when coding.....

And yes happy to collaborate.......maybe we can maintain a file on this forum

BTW

There is a TXOFF command that comes up......I suspect this tries to stop tranmission to the socket so you can't see these extra commands .....but on power up.....the command doesn't stick ....so you get to see the other commands.......maybe there's a TXON to restart transmission......just guessing though........

Cheers

Dominic

Does look good... The NET/USB looks very similar to the one I made?

Have you found it be stable over TCP/IP? My 4306 would regularly just hang which was one of the reasons I stopped with the TCP/IP..

Hi Techni

Yes it is stable in NET/USB.
Reponse overall is very good.

FYI. There was a firmware upgrade last year that fixed a specific issue with streaming data locking up after 2 hours. Never listened to music for that long so never experienced it first hand. 

Cheers

Dominic 

Dominic, do you have a Denon DVD/CD/BD player aswell?
My latest working unprotected libraries and project are in your mailbox, please note that the next (currently working on) version will be different. The parsing will be moved to .Parse under the command object (where .GetStatus and .Status are), and I'm thinking of an OnChange item so users can put there own functions in. Also there is a lot more in the code then in the GUI.

Hilko

Here are a few more:

Display Dim Control - Not documented for my 4810CI

SSDIM ? - Query Dimmer
SSDIM OFF
SSDIM DAR
SSDIM DIM
SSDIM BRI


On a Zone rename
Event Rx[NEW_TEXT] is fired where 'x' is 1 for Main zone, 2 for Zone 2, ... , 4 for Zone4

This module looks awesome. Count me in as an owner of a 4310CI receiver and 3800BDCI Bluray player that would be very interested in having it (and willing to pay for it). Love to be a beta tester as well!

Thanks for all of your efforts guys.

Patrick

Yes, I'm certainly interested myself having 2psc Denon 4308 and one TSU9600 and one TSU9400 and 2 RFX9600.
Willing to beta test if it's of interest.

Regards/Harry

When and were can a get this eyecandy :-)?
Fantastic job Dominator

As someone who writes complex scripts and knows that Denon feature sets differ from model to model (I'm on my 3rd version of a Denon TCP script), I suppose this script will have lots of support. I would not expect that this module to be published freely but I could be surprised.

I certainly don't mind paying for the module.

/Harry

I would also be interested in the module. Not sure if you know command3808 and whether this would help?

Dominic,

FYI, on my 4810-CI, I just tested with Gladiator on DVD in DTS ES and I get 331 when using DTS ES which is a 6.1 source. I ALSO get 331 on a 5.1 source so it looks like we have same bug on that model as well.

When there is no inputing being fed to receiver, I get 200.

Do you know if there is a way to get the receiver to report this status without having to query?

Command 3808 has less commands then we do already.

I have been working these last few days to "scale-back" and make EscientPronto perform better such that I can utilize both TCP-based control of my Denon and EscientPronto in the same activity.

Several things have come to light that those developing modules, particularly a denon module, may find of use or want to debate/discuss.

1) More objects mean slower code operation

Whenever a callback is made to your code from the system (scheduleAfter, onSocketData, etc), the Javascript garbage collection is invoked and it does make performance a bit sluggish.

In short, the more objects you have, the more sluggish the performance. Note that functions are also objects.

After talking with Belgium, this is by design as garbage collection must be invoked. In the current "Spidermonkey", there is only a single-generation garbage collection where in the newer "TraceMonkey", there is multi-generation GC. So, if TraceMonkey were in use, things would be better but there would still be some slowdown.

2) Do you really need to monitor the most obscure messages from Denon ALL THE TIME?

All the bells and whistles are nice but...

While developing a Denon module, one has to consider all the information available from the Denon. In short, you get an event/response for lots of things that you may not be interested in. For each event/response, you must look at a minimum of 2-3 characters to see if you want to process it. This takes time and if you are interested in processing "everything", your message processor code can get very large and can be very slow. Regular expressions may help but issuing xxx.test() on 200 regular expressions to find a match on the 201st one is just plain slow. So, while we would like to process everything under the sun, it almost warrants developing several message parsers that can be invoked depending upon the things one might be interested in.

For example, having a processor for all the SS*** (System Setup) messages other than maybe SSDIM does not make sense in your normal operating code as user will not likely be in setup that much. The same goes for Surround Parameter messages (PS*). Normally, one would only be interested in maybe Surround Back settings and maybe a few more.


Just food for thought...