Call for tester for 1.4.0 features and fixes (2 Viewers)
- Thread starter Scythe42
- Start date
- Status
- March 4, 2008
- 2,114
- 1,176
- Home Country
-
Netherlands
my results for the window detective test. [DOUBLEPOST=1355868018][/DOUBLEPOST][smartass mode]
RDP, VNC, TeamViewer viewing is not possible, as we are in real D3D-Fullscreen mode. Borderless screen sized window mode will be added later.
[/smartass mode]
Ghehe.. just a copy past from Scythe himself from the OP.
Reading that line back: "Borderless-screen-sized-window-mode" ... thats a hell of a scrabble word.
RDP, VNC, TeamViewer viewing is not possible, as we are in real D3D-Fullscreen mode. Borderless screen sized window mode will be added later.
[/smartass mode]
Ghehe.. just a copy past from Scythe himself from the OP.
Reading that line back: "Borderless-screen-sized-window-mode" ... thats a hell of a scrabble word.
Last edited:
If you have decent internet connection, teamviewer should work without problems, atleast personally ive used it alot and always worked.
But dunno would it be that much help afterall..
Edit:
Ahh ok Didnt know that one..
But dunno would it be that much help afterall..
Edit:
Ahh ok
Didnt know that one..
Last edited:
- Thread starter
- #74
Full-Screen Windows work over RDP/VNC/TeamViewer etc. But a real full screen app doesn't. And that's what we are currently working on.
Guys, here is a quick test based on the last build. I added a minimize/restore cycle with a delay of three seconds in between for the guys that are receiving multiple WM_DISPLAYCHANGE messages. Meaning, you still saw a black screen after turning tv/receiver back on.
Just replace the .exe and test if this works better for you.
Leaving MP in the tray is no problem. It's the automatic come back from the tray stuff that's tricky.
Just want to know if this large delay helps, meaning it is a simple timing issue in some setups.
I'll decided to add a couple of advanced options later in the config tool.
Checked all the message logs as well. The other messages from windows itself don't help at all.
So please try the exe and let me know if the delay is helping you guys.
No logs needed if it doesn't work. I already know what messages your system receives.
Just let me know if there is any change, better or worse.
Next build will be with configuration option, so you can tweak the behaviour based on your HDMI chain.
PS: Yes, there is a perfect solution: proper D3D device reset. But as we still have Managed DirectX in the mp code base it's a pain to include that. Better to invest time to replace Managed DirectX completely.
Edit: Build removed - was tested
Guys, here is a quick test based on the last build. I added a minimize/restore cycle with a delay of three seconds in between for the guys that are receiving multiple WM_DISPLAYCHANGE messages. Meaning, you still saw a black screen after turning tv/receiver back on.
Just replace the .exe and test if this works better for you.
Leaving MP in the tray is no problem. It's the automatic come back from the tray stuff that's tricky.
Just want to know if this large delay helps, meaning it is a simple timing issue in some setups.
I'll decided to add a couple of advanced options later in the config tool.
- Try to restore automatically -> Yes/No (default yes)
- Force restore after x seconds -> time in seconds (default 0, means off)
- HDMI Handshake delay in ms -> time in ms (default 0)
Checked all the message logs as well. The other messages from windows itself don't help at all.
So please try the exe and let me know if the delay is helping you guys.
No logs needed if it doesn't work. I already know what messages your system receives.
Just let me know if there is any change, better or worse.
Next build will be with configuration option, so you can tweak the behaviour based on your HDMI chain.
PS: Yes, there is a perfect solution: proper D3D device reset. But as we still have Managed DirectX in the mp code base it's a pain to include that. Better to invest time to replace Managed DirectX completely.
Edit: Build removed - was tested
Last edited:
- July 8, 2006
- 879
- 259
- Home Country
-
Germany
Hello,
I have read this thread and have head some thoughts about the "multiple WM_DISPLAYCHANGE" issue. Perhabs my thoughts are rubbish. In this case don't hesitate and blame me ;-)
I'm not a programmer anymore and I don't understand so much about the windows API.
But after reading this thread my first thougt was: Could different hardware setups lead to the behaviour that the message is there once or twice?
For example one or two displays? NVIDIA or ATI or INTEL GPU, ...
If the a root cause for this behaviour is found it might be possible to know when it is nessary to wait for the second WM_DISPLAYCHANGE.
I have read this thread and have head some thoughts about the "multiple WM_DISPLAYCHANGE" issue. Perhabs my thoughts are rubbish. In this case don't hesitate and blame me ;-)
I'm not a programmer anymore and I don't understand so much about the windows API.
But after reading this thread my first thougt was: Could different hardware setups lead to the behaviour that the message is there once or twice?
For example one or two displays? NVIDIA or ATI or INTEL GPU, ...
If the a root cause for this behaviour is found it might be possible to know when it is nessary to wait for the second WM_DISPLAYCHANGE.
With my custom build based on your branch (not latest, but from yesterday) i cannot watch recorded TV. Starts and immediately stops. Logs attached. I don't have this with my custom build based on master. Also Live TV is not a problem, only recorded.
Last edited:
- March 4, 2008
- 2,114
- 1,176
- Home Country
-
Netherlands
tested the delay version from GUI.
repeated the off/on cycle 6-8 times.
first 2 resulted in normal returning MP GUI.
after that is was alternating between full black screen with mouse, or desktop with MP trayed. All instances were 100% ok on the screen resolution though. I was able to get MP back on top in normal working order..
Next test
repeated the off/on cycle 6-8 times.
first 2 resulted in normal returning MP GUI.
after that is was alternating between full black screen with mouse, or desktop with MP trayed. All instances were 100% ok on the screen resolution though. I was able to get MP back on top in normal working order..
Next test
Last edited:
I've never managed to get video, whether full-screen or windowed, to work properly over RDP, even Youtube in a browser.
I did find if I disabled dwm/Aero and used a particular setting in MPC-HC (can't remember exactly which, VMR7 maybe) I could get it to play reasonably in a window, as long as I didn't try to make the window too big, so it seems that Windows has a problem piping video over a network, even though I tested on a Gigabit network which should have enough bandwidth. Even then I think I had trouble with audio/video sync.
Perhaps you're just looking at getting the MP GUI working over RDP, not video though. I've been meaning to try Splashtop which I understand can even stream games to another device, so I guess it should be possible.
- March 4, 2008
- 2,114
- 1,176
- Home Country
-
Netherlands
I guess for a couple of reasons it isnt desireable to work over rdp/vnc/teamviewer etc anyways.
1 - Its too immature for debugging purpose. False negatives/positives etc. It might work but then again, the bug might be gone.
2 - People need to give complete controle of their pc away.
3 - Scythe doesnt have to do the testing himself, but leave that to the community while he whips up new idea's.
4 - Scythe cant turn off/on a receiver/tv set remotely. If he could, he would truly be a god.
Not to be negative, I see it could have a numer of possitives as well.
1 - If a dev controls a pc him/herself, direct controle and direct input/feedback of the system. Faster debugging / fixing cycle.
2 - No language barrier through writing stuff in this forum.
Maybe this is a realy good idea, just not in this issue, to be worked out.
Regards
1 - Its too immature for debugging purpose. False negatives/positives etc. It might work but then again, the bug might be gone.
2 - People need to give complete controle of their pc away.
3 - Scythe doesnt have to do the testing himself, but leave that to the community while he whips up new idea's.
4 - Scythe cant turn off/on a receiver/tv set remotely. If he could, he would truly be a god.
Not to be negative, I see it could have a numer of possitives as well.
1 - If a dev controls a pc him/herself, direct controle and direct input/feedback of the system. Faster debugging / fixing cycle.
2 - No language barrier through writing stuff in this forum.
Maybe this is a realy good idea, just not in this issue, to be worked out.
Regards
Last edited:
- Thread starter
- #80
Main problem would be in this case turning on/off all the stuff and actually seeing/listening what is displayed. I have enough bandwidth (I'm on a 100Mbit/s line, 10Mbit/s up). But most stuff need to reproduced anyway. In this case it is really dependent on the whole HDMI chain. This is were remote supports ends.
Yeah, can be done over TeamViewer with Voice Chat as well. But I have now collected enough stuff and tested out various approaches. So I can go coding for a new solution, that then can be tested again.
To properly test with remote I would need a WebCam on which I can see what's happening as well. Also we would need to setup an IR blaster from which I can send IR commands. If you have two USB-UIRTs no biggie. One receives at the HTCP in general and I use the other to send commands (can be connected to the same machine).
But for general support I always use TeamViewer. Best remote management tool for all OSes. And with the recent update finally usable on IOS (wasn't before).
But as said, I now collected enough stuff. We just test some more builds util we find a solution that works for all (maybe require some config options).
As the WM_DISPLAYCHANGE is properly send on all machines, but the WM_GETMINMAXINFO doesn't come up everywhere as it should and I didn't find another good hook from the message logs I build something new on WM_DISPLAYCHANGE alone.
PS: New build will be available some time after christmas. Family time next week.
Yeah, can be done over TeamViewer with Voice Chat as well. But I have now collected enough stuff and tested out various approaches. So I can go coding for a new solution, that then can be tested again.
To properly test with remote I would need a WebCam on which I can see what's happening as well. Also we would need to setup an IR blaster from which I can send IR commands. If you have two USB-UIRTs no biggie. One receives at the HTCP in general and I use the other to send commands (can be connected to the same machine).
But for general support I always use TeamViewer. Best remote management tool for all OSes. And with the recent update finally usable on IOS (wasn't before).
But as said, I now collected enough stuff. We just test some more builds util we find a solution that works for all (maybe require some config options).
As the WM_DISPLAYCHANGE is properly send on all machines, but the WM_GETMINMAXINFO doesn't come up everywhere as it should and I didn't find another good hook from the message logs I build something new on WM_DISPLAYCHANGE alone.
PS: New build will be available some time after christmas. Family time next week.
Last edited:
- Status