On my PVR (Foxtel), I sometimes want to use the Up/Down functions in repeating mode (to scroll through a list), but sometimes in non-repeating mode (to move to the next item on a list).

The obvious way to do this is to use a repeating code, pressing it only quickly if one wants to move up/down by one item only. This is how the PVR's own remote does things. The problem with this is that a quick press too often results in a double jump and this happens whatever durations are set for the code.

To rectify this, I used a non-repeating code within a prontoscript loop, effectively inserting a delay between the first invocation and subsequent invocations. For example:

c=0;
onHoldInterval = 50;
delay=3;
onHold = function()
{
if(c==0 || c>delay) {CF.widget("Down").executeActions();}
}
c++
};

Functionally, this works as intended. The problem with it, however, is that the repeating functionality is very jumpy/irregular and this compares unfavourably with the use of the repeating code (where the repeating functionality is very smooth).

Clearly, there are variables to play with here (in the database: the duration of the code and the general delay between codes; and in the prontoscript: the onHoldInterval and the 'delay' variable) but I can't find any combination which results in smooth repeating functionality.

It seems to me that there are two possible conclusions: either a) I have not found the right combination of variables yet or b) any prontoscript solution will always result in jumpy repeating.

Any thoughts?

Guy Palmer,

Do you have any other timers running? You could be experiencing a "beat" between timers.

In my experience the timers are somewhat erratic because the user timers are too far down on the priority list. A 50ms loop is a little tight. Also, response to user timers will be blocked while IR is being sent.

A really ugly detail is that response to button and key press is blocked while IR is being sent. There will be an acknowledge tone, but the key press will be thrown away.

I've been defining a special page accessable from the Home page via PageUp or PageDown that allows adjusting my own timers. For example, if I need to work out a delay between PowerOn and giving an Input command, this can require a number of download iterations. I start with a global default and adjust as needed. On the next download iteration, I'll update the default. Sometimes this takes a while to work out. In selected cases I'll have a user mess with this so that we can find the minimum timing based on "real world" conditions. After a few days experience, I'll hard code the result of our trials.

You raise some interesting issues, Buzz.

Yes, I do have some other timers running.

Yes, I have some temporary buttons to change the two prontoscript variables and test the results (changing the onHoldInterval doesn't seem to make much difference). One issue is that I can't do the same for the two database variables (duration and general delay) and, more generally, do not really understand these two variables. More specifically:

1. What is the 'default' duration and can I change this?

2. Does the 'general delay' affect the time between any two IR codes or only particular ones (e.g. in a channel macro)? What should its value typically be?

When "default" is chosen, 2 repetitions of the IR code will be sent out. This is determined based on analysis of the IR code, and cannot be changed manually.


This only affects channel macros (which are expanded to action lists containing IR send actions and delays, when downloading to the control panel)

Note: when an IR code is the sole action in an action list of a button not having a button script or an onPress callback, keeping that button pressed will result in "send-while-pressed", but still, at least 2 repetitions will be sent out.

Thanks, Sogliphy, very helpful.


Why 2 rather than the obvious number (i.e. 1)? If I manually set the duration, does this result in just a single repetition being sent?

I guess mainly because this is how action lists have always been interpreted in Pronto configurations, and changing this might break existing action lists.

Ok, thanks. I'll have a play and see if I get anywhere.

Guy,

This is a known limitation of the executeActions and was discussed thoroughly here a few years back. i.e. there is no way to send just the repeating part.

You might try and break the code apart into 2 functions and have your script send the larger one-shot part with the first executeActions() and the smaller repeating part with the subsequent calls to executeActions.

For information on how to segregate one-shot and repeating code data, see Barry Gordon's Pronto Hex IR Format document in the User Documentation subsection of the Classic Pronto Files section.

Which aspect precisely? Are you saying that the jumpiness when using a prontoscript loop is inevitable unless I separate the two bits of the code?

Yes, that is EXACTLY what I am saying.

Here is the original thread from a few years back entitled executeActions().

Found with a search of executeactions repeat ir

[Link: remotecentral.com]

Thanks, Lyndel.

Your memory for old threads is amazing :)