Problem w/MVPWidth parameter

[wtg]

To correct a bit of overscan issue I'm having with gbpvr's menus on my PCH, I made some adjustments to the MVPOffsetX and MVPOffsetY settings, along with corresponding changes to the MVPHeight and MVPWidth. Changing the MVPWidth parameter to anything other than 1280 causes redraw problems though.

Since the MVPOffsetX set to 10 seemed to align gbpvr up with the left side of the screen, to make the same adjustment to the right side I figured I needed to take off 20 from the total width. However, I found that any change to the width resulted in the buttons redrawing improperly once I moved focus. It seems they redraw without the X offset taken into effect, or something like that anyway. The Guide is really strange getting skewed and then redrawing and correcting itself as you move around within it.

MVPHeight changes however seem to work fine.

[sub]

They cant be changed to any value. There are a couple of rules to be aware of. MVPWidth and MVPOffsetX can must be a multiple of four (0,4,8,16 etc). If MVPWidth cannot be greated as the maximum width. If MVPWidth + MVPOffsetX are greater than the maximum width, then MVPOffsetX is treated as zero.

[wtg]

They cant be changed to any value. There are a couple of rules to be aware of. MVPWidth and MVPOffsetX can must be a multiple of four (0,4,8,16 etc). If MVPWidth cannot be greated as the maximum width. If MVPWidth + MVPOffsetX are greater than the maximum width, then MVPOffsetX is treated as zero.

I wasn't sure if I'd used a factor of 4 before but I specifically did this time and it has the same problem. Here's my config.xml data:

Code:

<MAC-0006DC421F7B>
      <MVPClientType>PCH</MVPClientType>
      <MVPWidth>1264</MVPWidth>
      <MVPHeight>680</MVPHeight>
      <MVPOffsetX>8</MVPOffsetX>
      <MVPOffsetY>0</MVPOffsetY>
      <MVPSendIncrementalUpdates>true</MVPSendIncrementalUpdates>
      <MVPTranscodeTS>false</MVPTranscodeTS>
      <MVPTranscodeAVI>false</MVPTranscodeAVI>
      <MVPTranscodeWMV>false</MVPTranscodeWMV>
      <MVPTranscodeMKV>false</MVPTranscodeMKV>
    </MAC-0006DC421F7B>

Any value of MVPWidth besides 1280 results in the same problem. The screen looks fine at first, but as soon as I scroll, it redraws wrong. Attached is a (very poor) picture I took with my phone.

[mvallevand]

I would suggest putting it back to 1280 720 0 0 and using the MVPosition plugin and see what it recommends. I'd be interested in your findings.

There is a also a patched version of PVRx2.exe in this thread http://forums.nextpvr.com/showthread.php?t=35181 but it won't be compatible with the MVP.

Martin

[wtg]

Thanks for the tip Martin. Experimenting shows that an X and Y offset as well as changes to the height work fine. It's only the change to the width that cause an issue and so for the time being leaving the width at 1280 keeps it from screwing up. I still have a bit of an overscan problem but not so bad I can't use it. I might try the MVPosition plugin just for kicks though. I've been tempted to use it in the past but never bothered.

Re: the patch in the thread you linked, you seem to know more about it than was said in the thread. When you say it won't be compatible with the MVP, are you saying the logic to fix the problem won't be executed on the MVP, or that the MVP's won't work with it? I have a mixed environment currently and so the MVPs need to function.

[mvallevand]

Thanks for the tip Martin. Experimenting shows that an X and Y offset as well as changes to the height work fine. It's only the change to the width that cause an issue and so for the time being leaving the width at 1280 keeps it from screwing up. I still have a bit of an overscan problem but not so bad I can't use it. I might try the MVPosition plugin just for kicks though. I've been tempted to use it in the past but never bothered.

The issue with the total width (width + offset) is if you change it you also need the corresponding total width in the command line
--display widthxheigth It takes a lot of playing around to get right.

Re: the patch in the thread you linked, you seem to know more about it than was said in the thread. When you say it won't be compatible with the MVP, are you saying the logic to fix the problem won't be executed on the MVP, or that the MVP's won't work with it? I have a mixed environment currently and so the MVPs need to function.

I don't think it works on the MVP as I wrote here http://forums.nextpvr.com/showthread.php?t=35209

Since I read yesterday that sub's build isn't compatible with 1.2.9 I don't expect another patch either.

Martin

[wtg]

The issue with the total width (width + offset) is if you change it you also need the corresponding total width in the command line
--display widthxheigth It takes a lot of playing around to get right.

Makes sense. When coming up with the offset and calculating the width, I've been assuming I needed to come in on the right side by the same offset as the left (it seemed to overscan the left and right sides of the screen about the same) and so I've calc'd my width = 1280 - (2 x X-offset). So if I understand you correctly and based on the example I posted above, I would need to set my display width in startmeup to 1272. You're not suggesting this is the source of the button redraw problems though right, or are you?

Set with an x offset of 8 it seems to be offsetting correctly and drawing the screen fine with the width set to 1280 - it's just wider than I want it. And reducing the height works fine without a change in startmeup. It's just when I reduce the width that things get goofy.

I'll have to experiment some more this evening when I get home.

Thanks again for the help.
Tim

[tcmy95]

Tim

This maybe very very late but I was having some problems myself and I have now managed the overscan issue. Somesaid that the offset has to be a multiple of 4 so all I did was reduce the MPwidth by multilples of 4 even though is didn't add upto 1280 in total with the offset. I don't have any overscan issues now.

Ian