With macros containing a command to ramp down and then ramp up the volume control (to mimic a preset volume control), with other commands also contained in the macros, my 5200 locks up and reboots near the end of the macro.

Removing the volume down/up part of the macros solves the rebooting, (or removing several other commands will also solve the problem).

There seems to be some limit as to how long a macro runs and issues ir commands before the 5200 is placed into a reboot cycle.

Is there some way to correct this without having to remove commands?? I already read the previous posts on the subject, as well as the listed tips and tricks.

Would appreciate any feedback on this.

Best Regards,
Harris

This just seems to be a Pronto firmware bug. I have the same problem with "play fast forward" for my VCR. If I hold the button for too long the Pronto reboots. I have noticed the same problem a couple of times if I hold the "scan up" or "scan down" buttons for my sat receiver. It looks like some sort of buffer overrun problem, like the Pronto is putting IR codes in a buffer faster than they can be transmitted.

i've noticed the same thing with the TSU6000. The TSU6000 is solved by updating the firmware, but i updated the firmware on the TSU2000 and it didn't take care of the problem (this was about 6-7 weeks ago). if there is a new firmware, thats what i would suggest. i tried talking to phillips about the problem, but they couldn't tell me anything.

There is a program, PEUpStack, that solves some buffer over run problems with TouchScreenSetup and loading certain files like Daniels Galaxy Game. It's used to patch the software and is available here: [Link: ox.compsoc.net]. I have no idea whether it would solve you guys problem or not. Since your problems are on the remote and not the software - maybe not, but it's worth a try.

Jim L

Thanks for the responses. At least I am not alone in this... :-)

Hopefully the programmers at Marantz (and Phillips) will be aware of the problem AND be correcting it in a firmware update....

Best Regards,
Harris

Hi Jim, I think that the PEUpstack is to prevent software crashes, but to double check this, I emailed Leo. If I hear back, I will post the results,

Best Regards,
Harris

Jim, PEUpstack is to stop ProntoEdit crashing, not a Pronto itself.

The maximum number of actions is 255. This includes actions from aliases and nested aliases. Though I'm not sure if that is Harris's problem.

The 'holding down a button causing a reboot' problem has been reported before. It can happen if the IR code is very long. Cleaning up the code can help (assuming it is dirty).

Peter, thanks for the clarification re the stack program.

Re the rebooting: The number of actions in the problem macros is typically 25 PLUS two "macros" (one for the ramp down/ramp up volume setting, and another for multiple room parameters such as ir settings for speaker distance, height, etc). These two "macros" have a total of about 40 ir commands, and this with the 25 commands in the master macro, equals about 65 steps.

Taking out either the room setting "macro" OR the volume "macro" eliminates the problem, so I am certain it is a problem with running too many commands within a macro. Obviously alot less than 255, but nonetheless, alot more than the typical user would have.

Another possibility is that if the "long" ir code can also be several codes within one "macro" as in the case of the volume "macro" I describe above. Perhaps this would be the killer, as far as rebooting is concerned...

Just some thoughts,

Best Regards,
Harris

Peter,

Thanks, I kinda figured that would be the result, it was just a shot in the dark since someone mentioned buffer over flow.

Jim L

Jim and Peter, just heard back from Leo, and our suspicions are indeed correct; the program is for the computer, not the remote....

I solved my problem by taking one of the volume macros out at this point...

If it is any help, prior to rebooting, a PARTIAL screen is shown (ie only around 70% of the icons) on one of the final panels prior to lockup. This would suggest some type of buffer overload on the remote itself...well short of 255 commands in a macro.

Best Regards,
Harris