kobayashi_maru

Good evening - I wanted to provide an update on my testing, particularly the Zone 3 issue and the intermittent connection problems affecting the main Marantz SR6011. 1. Zone 3 workaround — successful Following your suggestion, with the help of a friend and ChatGPT, I made a local change to cfg/server_config.yaml on the eisy. I removed only the zone3 command group under the denon_avr driver, leaving the shared Zone 3 definitions and the Onkyo Zone 3 definitions untouched. After validating the YAML and restarting AVRemote: The node server starts and connects successfully. The Marantz SR6011 main-zone node is created and reports online. No Zone 3 node is generated. The latest debug log contains no Z3, Z3?, or Z3MU commands. So that workaround appears to have successfully eliminated the unsupported Zone 3 activity. I'll be interested in your planned Zone 3 enable/disable checkbox when it's available. 2. Main-zone connection errors — still occurring I also tested with the following settings: Connect On Demand: False Short Poll: 15 seconds Long Poll: 70 seconds Unfortunately, the main-zone errors persist. In the later portion of the latest debug log, I found six occurrences of: OSError: [Errno 9] Bad file descriptor and one occurrence of: ConnectionRefusedError: [Errno 61] Connection refused The timing continues to suggest a possible interaction between concurrent polling threads. For example: 17:23:56.815 — Long poll begins. 17:23:57.295 — Short poll begins, while the long-poll operation is still active. 17:23:57.297 — The long-poll thread reports Bad file descriptor. At 17:30:57, another connection failure occurs as a short-poll operation starts while another poll is in progress. I realize this doesn't prove a threading issue, but it seems worth investigating. From the code ChatGPT inspected, the Denon driver uses a shared self.conn socket, and I haven't found any apparent synchronization protecting simultaneous access to it. One other observation: even with Connect On Demand set to False, the log continues showing repeated connection attempts before individual commands. Is that expected behavior? 3. Manual power-command test I also tested ON and OFF directly from the IoX Admin Console: ON at 17:18:30: AVRemote sent ZMON, and the receiver acknowledged with PWON approximately 0.3 seconds later. However, the subsequent state refresh was considerably delayed, and the console took roughly 20 seconds to reflect the change. OFF at 17:19:37: AVRemote sent ZMOFF, received PWSTANDBY approximately 0.35 seconds later, and the console updated promptly. This suggests that the receiver is responding quickly to the actual commands, but the subsequent status refresh and polling activity aren't always keeping up. For reference, I'm running the latest updates available as of November 4: AVRemote 2.0.18 PG3x 3.4.28 IoX 6.1.2 I've attached the latest full debug log. Hopefully the timestamps and overlapping polling activity will help pinpoint what's happening. Thanks again for your willingness to work on this. I'm happy to continue beta testing whenever you have something available. I appreciate your help! AVRemote_debug_2026-11-04_redacted_v2.log

Thanks, I appreciate your willingness to help me on this. I've left AVRemote turned off for now, and I'll leave the YAML editing to those who know what they're doing — Python isn't in my toolkit! For reference, my eisy|lite is running the current releases: PG3x 3.4.28 and IoX 6.1.2_10. I'd be happy to help test a beta version when you have one available. Ideally, it would provide a way to disable Zone 3 for the SR6011 and also address the intermittent ConnectionRefusedError and Bad file descriptor errors affecting the main zone. The receiver does respond successfully to many of the polling requests, so hopefully there's something that can be learned from testing. Let me know when you're ready for a willing tester. Thanks again!

Today, I tried an experiment in the AVRemote PG3x Nodes page: I deleted both Zone 2 and 3 by clicking the X in the Delete column. The debug log confirms both nodes were marked as removed. In the subsequent entries, the Zone 3 polling errors no longer appear, but intermittent errors continue for the main Marantz SR6011 node. The two continuing errors are: ConnectionRefusedError: [Errno 61] Connection refused — during self.conn.connect() while refreshing the main receiver's input source (e.g., 13:38:23). OSError: [Errno 9] Bad file descriptor — during self.conn.recv(self.BUF_SIZE).decode() while refreshing the main receiver's state (e.g., 13:39:23). Other main-zone polling requests continue to succeed between these errors; the receiver appeared fairly responsive in limited testing. Deleting the zone nodes appears to have eliminated the Zone 3-specific errors, but has not resolved the intermittent main-zone connection errors. I can provide the full debug log if it would be helpful. I'm also unsure whether manually deleting these nodes is a durable solution. The log suggests the Zone 3 deletion survived an AVRemote restart, but I haven't tested whether the deletions persist through an eisy reboot, plugin update, or rediscovery. Would you expect these nodes to remain deleted, or could AVRemote recreate them? Is there a more efficient way or configuration setting to make have AVRemote only talk to the main zone (I don't care about Zone 2 or 3)?

Thanks for the response. My receiver is configured as a 7.1.2 Atmos system, with all nine internal amplifier channels assigned to the Main Zone. I checked Marantz's documentation, which indicates that the SR6011 does not support Zone 3. Since the SR6011 supports the Main Zone and Zone 2, but not Zone 3, could you confirm which zone commands AVRemote is sending? Is it issuing Zone 3 commands as part of its normal initialization or status polling, even though the receiver doesn't support Zone 3?

Hi, I'm brand new to IoX and node servers, so please bear with me! I'm trying to get AVRemote working reliably with my Marantz SR6011, and would appreciate some guidance. My setup Controller: eisy / IoX 6.0.5 Polyglot PG3x: 3.4.18 Node server: AVRemote 2.0.18 (Free/Production) Receiver: Marantz SR6011 Receiver IP: 192.168.1.105 Connection: TCP port 23 Receiver's Network Control setting: Always On AVRemote's Connect On Demand setting: true What happens AVRemote initially showed the receiver as off even when it was on. Changing Connect On Demand from false to true and restarting AVRemote improved power-status reporting. It now correctly shows the receiver as on. Volume readings have sometimes appeared incorrect, but subsequently matched the receiver after I changed the volume at the receiver itself. Commands from IoX are unreliable. Set Volume and Input have not produced the expected changes at the receiver. Mute has worked intermittently. Responses and status updates can be slow. Relevant log errors The latest debug log contains: ConnectionRefusedError: [Errno 61] Connection refused This occurs when AVRemote attempts to connect to 192.168.1.105:23 to send a volume command. It also contains: OSError: [Errno 9] Bad file descriptor This occurs during recv() while AVRemote is polling receiver state, including Zone 3. The logs also show some successful communication—for example, AVRemote sends SI? and receives SISAT/CBL—so communication is not failing consistently. What I've tried Verified the receiver IP address and port 23 in AVRemote configuration. Confirmed Network Control is set to Always On. Changed Connect On Demand to true and restarted AVRemote. Restarted AVRemote and tested Power, Volume, Input, and Mute controls. Downloaded fresh debug and Polyglot log files. I have attached the latest debug log package. Could these errors indicate a connection-management or concurrent polling issue in AVRemote's Denon/Marantz driver? What would you recommend trying next? Thanks for your time and for maintaining AVRemote. I'm happy to follow step-by-step instructions, but I'm not experienced with command-line troubleshooting. AVRemote_10-24-2026_52456_PM.zip

Seems to be up and running now, at least here in Michigan.