If you don't see a dialogue box each time the script runs when you change false to true then you haven't done it right! Check it is not hidden behind the video. It should also stop the flipping,if it is the script causing it, as the script is paused until you OK the box. It is odd for sure!
-
AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.
A little help needed... enabling default RunEvent.vbs for SetDisplayFrequency.exe
- Thread starter mkanet
- Start date
Okay guys... I do get dialog boxes! I took the time to copy each dialog box step by step with a description of what happens; along with the respective log file. If this doesnt tell the story, nothing will. Thanks for all your time!
Click below
Log attached
Click below
Log attached
Did the screen switch rates only each time a YELLLOW or QUIT event happened or was it flashing like crazy all the time? Hopefully the former.
Also, it would still be really useful to have the log from as long a run as you can bear - several loops at least. At the moment I'm assuming the Sage player restarts playback when it spots the refresh rate change. If the gap between the QUIT and the next YELLOW is not too big I can think of a workaround. But the 6 seconds or so I saw in the last log would make it very ugly.
Also, it would still be really useful to have the log from as long a run as you can bear - several loops at least. At the moment I'm assuming the Sage player restarts playback when it spots the refresh rate change. If the gap between the QUIT and the next YELLOW is not too big I can think of a workaround. But the 6 seconds or so I saw in the last log would make it very ugly.
With the dialogs enabled, it was completely under control, each step shown in each dialog box. I even described exactly what happened with each dialog box; including what step in the script would change the screen refresh rate; and, when STOP, QUIT events would take place. Did you accidentally miss the picture in my previous message? I pressed OK to the dialog boxes and log enough times to where it repeated/looped the same sequence of events two times, then started for a third time. Once I realized it was doing the exact same steps going on a 3rd time, I just stopped the loop. I doubt you would see anything different in the 3rd, 4th, 5th, 6th cycle. Do you think something different would happen beyond a 3rd cycle?
When the debug dialogs are enabled, it obviously takes a lot longer than 6 seconds of video. That last log was close to a minute of pressing OK to each dialog box.
When the debug dialogs are enabled, it obviously takes a lot longer than 6 seconds of video. That last log was close to a minute of pressing OK to each dialog box.
OK. That's good. A little odd because it was not quite what we saw in the first log, but I'll ignore that. There is no way the script itself can loop, so it seems pretty clear that Sage is restarting the player on each refresh rate switch, which is not a wholly stupid thing to do. If they were clever they could probably do it with just a STOP and no QUIT, which would be great, but since no one would benefit but Reclock users who use scripts (maybe just you!) I don't imagine you will get much interest in changing things.
If, as you said earlier, the player process never shuts down I can only think of one workaround. That is to only switch rates on a QUIT after we are sure we are not restarting due to a previous change. This would work great if the next YELLOW after a QUIT was only a second or so later - we would only have to wait a second after a QUIT before returning to 59Hz. It would be uglier if it takes 6 seconds (as in that earlier log) - you would have to stay @24Hz for >6 secs after the player closes before switching back. But you describe the screen flicking back and forth as fast as the TV is capable, which suggests it is a shorter time and not ~6 secs, so it may work well. This is why I wanted another "free running" log covering a few loops - to really see how long it takes, maximum, to restart the player - the time from one QUIT to the following YELLOW.
But, never mind, as I'm intrigued by this now I'm going to put something together for you to try this afternoon. I'll start with resetting to 59Hz 6 secs after a QUIT (but only if the player does not restart in that time). If that works you can try reducing the delay until you start to see flipping again. Then you can decide whether that is good enough for you. I'm not sure there is much else to be done unless you can persuade Sage to let you run a command when the player really stops
If, as you said earlier, the player process never shuts down I can only think of one workaround. That is to only switch rates on a QUIT after we are sure we are not restarting due to a previous change. This would work great if the next YELLOW after a QUIT was only a second or so later - we would only have to wait a second after a QUIT before returning to 59Hz. It would be uglier if it takes 6 seconds (as in that earlier log) - you would have to stay @24Hz for >6 secs after the player closes before switching back. But you describe the screen flicking back and forth as fast as the TV is capable, which suggests it is a shorter time and not ~6 secs, so it may work well. This is why I wanted another "free running" log covering a few loops - to really see how long it takes, maximum, to restart the player - the time from one QUIT to the following YELLOW.
But, never mind, as I'm intrigued by this now I'm going to put something together for you to try this afternoon. I'll start with resetting to 59Hz 6 secs after a QUIT (but only if the player does not restart in that time). If that works you can try reducing the delay until you start to see flipping again. Then you can decide whether that is good enough for you. I'm not sure there is much else to be done unless you can persuade Sage to let you run a command when the player really stops
Last edited:
Jong, I very much appreciate all the time you have spent. I don't know if this matter, but, if I comment out:
' If eventName = "QUIT" Then
' newTimings = "59
It takes approximately 2-4 seconds before the refresh rate is changed by the script to the correct refresh rate.
You are right, SageTV does appear to rebuild the entire filtergraph after each refresh rate change; which would explain why the audio would abruptly stop with each refresh rate change. If I manually change the refresh rate without using reclock, I can continue to hear the audio perfectly without any interruptions.
It would be great to have a script that knows how to handle a player that completely rebuilds the filtergraph on refresh rate change.
Thanks again!
' If eventName = "QUIT" Then
' newTimings = "59
It takes approximately 2-4 seconds before the refresh rate is changed by the script to the correct refresh rate.
You are right, SageTV does appear to rebuild the entire filtergraph after each refresh rate change; which would explain why the audio would abruptly stop with each refresh rate change. If I manually change the refresh rate without using reclock, I can continue to hear the audio perfectly without any interruptions.
It would be great to have a script that knows how to handle a player that completely rebuilds the filtergraph on refresh rate change.
Thanks again!
Hi. This is the best I can think to do. Copy the attached to your Reclock folder and give it a go.
At the moment the script waits a massive 10 seconds after a QUIT before it resets the refresh rate to 60Hz. If the player restarts in that time it aborts the refresh rate change. This should work but it is pretty horrible changing rates so long after the video has stopped.
By editing sleep time in the "resetrefresh" script you can reduce the delay. You should reduce it until you start to see the refresh rate "flipping" again and then back off a bit until it stops. Then you need to decide if the delay is acceptable or not!
Good luck.
At the moment the script waits a massive 10 seconds after a QUIT before it resets the refresh rate to 60Hz. If the player restarts in that time it aborts the refresh rate change. This should work but it is pretty horrible changing rates so long after the video has stopped.
By editing sleep time in the "resetrefresh" script you can reduce the delay. You should reduce it until you start to see the refresh rate "flipping" again and then back off a bit until it stops. Then you need to decide if the delay is acceptable or not!
Good luck.
Last edited:
Wow John, this is really nice of you. I can't wait to try it tonight when I get home. Thanks a million! I'll let you know how it works.
Hi. This is the best I can think to do. Copy the attached to your Reclock folder and give it a go.
At the moment the script waits a massive 10 seconds after a QUIT before it resets the refresh rate to 60Hz. If the player restarts in that time it aborts the refresh rate change. This should work but it is pretty horrible changing rates so long after the video has stopped.
By editing the sleep time in the "resetrefresh" script you can reduce the delay. You should reduce it until you start to see the refresh rate "flipping" again and then back off a bit until it stops. Then you need to decide if the delay is acceptable or not!
Good luck.
It might also be worth checking that no extra processes are there only during video playback. "Process Explorer" should make this really obvious as they light up green when they start and go red as they close.
Even if the player itself always runs, if there is any process helper during playback that remains while the player restarts we could check for that and change the refresh rate as soon as it goes. If it disappears, it might only do so for a much briefer time than it takes for playback to restart and we could handle that too.
Of course no need to bother if the current scripts are acceptable!
Even if the player itself always runs, if there is any process helper during playback that remains while the player restarts we could check for that and change the refresh rate as soon as it goes. If it disappears, it might only do so for a much briefer time than it takes for playback to restart and we could handle that too.
Of course no need to bother if the current scripts are acceptable!
Last edited:
Thanks, you need to redownload from the original post.
Yeah, that was on my mind a while back. Definitely dont have any other apps in memory that could interfere with sageTV/reclock/refresh rates/EVR, etc. I just redownloaded the updated scripts with "%ProgramFiles%
No, what I mean is that if Sage starts any kind of helper process when it starts video playback and which disappears afterwards we could use this as a cue to know when to switch back to 60Hz. Of course there may be no such process, in which case I think this is the best we can do. Hopefully it's good enough!
ohhhh... Yeah, with sageTV there are no external helper processes. I know that for sure.
Yeah, with sageTV there are no external helper processes. I know that for sure.
OCD? wazzat? never heard of it
Last edited:
Jong it works perfectly! I changed the delay to 3500. That is the minimum time I can use before it starts to flip out.
While I have your attention, I'm hoping you wouldn't mind helping me with one minor thing. It should be very straight forward. I just dont know VB that well to know what would work.
All I want to do is when yellow condition is met and:
if there is NTSC(2x) and video is 720p then newTimings = "60"
if there is NTSC(2x) and video is 1080p then newTimings = "59"
Please see:
http://forum.slysoft.com/showthread.php?p=330108#post330108
While I have your attention, I'm hoping you wouldn't mind helping me with one minor thing. It should be very straight forward. I just dont know VB that well to know what would work.
All I want to do is when yellow condition is met and:
if there is NTSC(2x) and video is 720p then newTimings = "60"
if there is NTSC(2x) and video is 1080p then newTimings = "59"
Please see:
http://forum.slysoft.com/showthread.php?p=330108#post330108