How high is the general delay, not the poll delay.

General delay = 200

Try General delay = 300
Poll delay = 680

Using v1.41 IP control with my 4010UDCI watching a blu-ray disk. Testing related functions. Most buttons worked. The following don't appear to work:
cursor right, cursor down, eject, info button (not sure if code assigned), the power button will turn off the unit, but will not power it on.

No error messages.

Regarding not power on, you need to turn off power save in the player menu.

Good catch. With power save off, power on now works. How about the othe functions?

Thanks.

cursor right, cursor down, eject are unexplainable, the code path is the same as rs232. So if cursor up works, cursor down should to. Maybe a bug in the player firmware.

OK -this only improved marginally... I tried GD = 400 and PD = 600. Marginal improvement again... still, the error only appears when I've sent a command to the player or to another device like my lights or Projector....

Lee

Again this leeds me to believe that you're not getting the error when using the xcf alone, only when integrating it with other components. Maybe the extender helper object that will be in my next version will be a solution, but you'll need the source of the other components to be able to use it. Another solution might be the processor that will be available in q4. For now there is not much more I can do because I've got no idea what's going on. I can use 3 remotes at the same time without an error to 3 devices on the same extender by using the methods the Denonplayer does. Also I haven't had anyone else complain about any communication error with 1.41.

Could you make a picture of the error and mail it? Maybe I can build a debug version to atleast check what happened before the error. Disabling the error would be foolish, it needs to be fixed. Also delays of 400 and 600 are way to high to be able to communicate normally, and even worse when also using other devices at the same time.

The part that bothers me is that this only started to happen when we converted the code to a library versus the previous script versions. On the previous script versions, there was no error reported, no delays and all the same external devices were integrated. Essentially, it's exactly the same on my end with the exception of conversion to the library. As for the error, it just says "Communication timeout...."

That's easily tested - just change it back to a standard script (should take less than a minute).

Like I said, it works fine... I just loaded the older config.

Lee

Loading the older config doesn't help distinguish between "the problem is caused by it being a library" and "the problem is caused by something else that was changed", which is why I was suggesting converting the current config.

I don't see why "being a library" would be a problem - my understanding is that libraries and standard scripts are just slightly different ways of assigning the same code to an activity.

Lee,

the older version you're refering to will not give the error because it doesn't do any error handling. It also won't do a lot of things the current version will. Moving to a library has nothing to do with the problem. Disabling the error box also will not solve the error it will only not show it. It's much better to fix the error then to work arround it. However if you really would like it I'll add an option to disble errors in the next version.

But fixing the error is what we should concentrate on. Something is wrong and needs to be fixed or catched. But what I really need to know is if the error is because of your integration or not. If it is I can have a look at the conflicting module and modify it so it won't lock the extender.

I agree - I think fixing it is the best approach, but I'm concerned we're chasing ghosts... I'm not using any other modules, I'm only integrating a few other IR commands to the extender. Ironically, however, it doesn't JUST occur when I use other commands, it occurs when I use the skip command in your module, the reverse, etc., and consistantly happens during BR disk loads... I played a non BR disk in the player the other day and the problem didn't occur AT ALL, except when I ejected the disk. I think it's something in the BR player code that causes delayed or inconsistant response...