Dave or any other script expert, can you take a look at this script and see if it will do what I want it to do? My script name is RebootDVR1 and I plan to schedule it to run in the middle of the night a few times a week. What I want to do is to check to see if the DVR is recording. If not, send the reboot command immediately. If it is recording, wait an hour then call the script again. After 5 attempts if the DVR is still recording, end the reboot attempts and just wait until the next scheduled reboot time.

One of the questions that I had was if it was possible to put a pause into the script. Before I read the isrecording variable I would like to send the command that refreshes this variable. So ideally, I would want to refresh the variable, wait 1 minute to make sure the variable has been refreshed then read it to see whether to reboot now or wait later.

If RebootAttempts < 6 then 'Set a timer to call the script in another hour since the DVR is currently recording a program MLServeCmd.MLTimer|SetTimer~1~NoRepeat~1~hours~MLScript|RebootDVR1~on Else MLServer.SetVariable "directv_1_RebootAttempts", 0 End If End If

waits 1 minute after it is enabled (non repeating) and fires macro in step 3

Step 3:Check variable and use MLConditional to say

If (recording) then schedule a new check in 1 hourElse Reboot

Actually if you use this approach you won't even need MLScript will you?

I had thought about creating the refresh event as a separate step as you mentioned and it is true I probably don't need a script for this, but I want to try to start using them just because it is easier for me to see what is going on.

CinemarDave wrote:No I love script. You should use script whenever possible because of the power at your command. You just needed a delay that would stop MLServer. So I had a different idea.

OK. Then I should be able to take some of bigDvette's suggestions and work them into my script without putting a delay in my script. I can have the GetChannel event as a separate macro that runs a minute before the script then use the my script to determine if I should reboot at that time or not. I could even set a different timer to run the GetChannel event at 59 minutes if the DVR is recording and I need to wait another hour to check for reboot.

I guess the ideal situation is to determine why I can't use the polling feature from within MLDirecTVIP without running into the queuing issue that I have on my DVR's so I don't have to send the GetChannel commands prior to running the script.

Those commnads are queuing up because one or more DVRs are taking a long time to respond to the web request. When things get queued what is the next command in the queue? The plugin is waiting for the previous DVR to respond. Is it always the same DVR that it is waiting on?

CinemarDave wrote:Those commnads are queuing up because one or more DVRs are taking a long time to respond to the web request. When things get queued what is the next command in the queue? The plugin is waiting for the previous DVR to respond. Is it always the same DVR that it is waiting on?

I'll do some troubleshooting tonight. I am looking at the log now and it looks like it takes about 3 seconds on average for all 5 DVR's to issue and respond to the GetChannel command after it queues up. Is that typical? I don't see one taking any longer than the other. If I am trying to control DVR1, would it have to wait until the queue for DVR2 through DVR5 processes to respond to the remote key press sent to DVR1?

Here's the log with just the polling commands. I'll throw in the remote control commands tonight when I am in front of the TV.

thanks,Murray

You do not have the required permissions to view the files attached to this post.

Timings sound normal from the tests I have run on user systems. The processors in the boxes are not that powerful. With the current version all commands are put into the queue. If you were stuck in a polling interval your commands would be waiting at the end of the queue.

I just posted version 3.99.86 and you'll notice that there are now two command queues. A polling queue and a user command queue. Commands in the user command queue will always have higher priority than those in the polling queue. See if this works better for you.

CinemarDave wrote:Timings sound normal from the tests I have run on user systems. The processors in the boxes are not that powerful. With the current version all commands are put into the queue. If you were stuck in a polling interval your commands would be waiting at the end of the queue.

I just posted version 3.99.86 and you'll notice that there are now two command queues. A polling queue and a user command queue. Commands in the user command queue will always have higher priority than those in the polling queue. See if this works better for you.

Different polling and command queues sound like a great idea. I'll try it out tonight!

CinemarDave wrote:Timings sound normal from the tests I have run on user systems. The processors in the boxes are not that powerful. With the current version all commands are put into the queue. If you were stuck in a polling interval your commands would be waiting at the end of the queue.

I just posted version 3.99.86 and you'll notice that there are now two command queues. A polling queue and a user command queue. Commands in the user command queue will always have higher priority than those in the polling queue. See if this works better for you.

Dave, I tried the new version and saw similar problems. I attached 45 minutes of the log. Sometimes during the delays there were get channel requests being sent but other times there weren't. Also a few times there was a problem connecting to a DVR but not all the time. I tried it with my oldest DVR (DVR2) and my newest one (DVR5) with a faster processor and got similar delays. Most of the time (but not all) the queue buildup happened with 10 seconds before the top of the minute. Here is the data from the logs for part of the time that multiple key presses were queued up that resulted in delays.