Version 180 of the nvidia drivers recently caused me to have terrible jittery framerates. It was most noticeable on the higher resolutions videos (1080i) but was also still noticeable on the lower resolution progressive scan streams as well (720p). Nvidia needs to stop breaking things :(.<br>
<br><div class="gmail_quote">On Sun, Jan 18, 2009 at 11:32 AM, Tom Dexter <span dir="ltr"><<a href="mailto:digitalaudiorock@gmail.com">digitalaudiorock@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Sun, Jan 18, 2009 at 1:45 AM, Yeechang Lee <<a href="mailto:ylee@pobox.com">ylee@pobox.com</a>> wrote:<br>
</div><div class="Ih2E3d">> Tom Dexter <<a href="mailto:digitalaudiorock@gmail.com">digitalaudiorock@gmail.com</a>> says:<br>
>> Has anyone experienced the freezes described here using the 180.22<br>
>> drivers:<br>
>><br>
>> <a href="http://www.nvnews.net/vbulletin/showthread.php?t=123912" target="_blank">http://www.nvnews.net/vbulletin/showthread.php?t=123912</a><br>
>><br>
>> Except for the fact that I get a black screen rather than the<br>
>> corrupted video described there, this is very much like what I'm<br>
>> running into with 177.82.<br>
><br>
> I use 173.14 and have seen the hangs (of the type you describe, with a<br>
> black screen) on my frontend . . .<br>
><br>
>> I neglected to mention in my original post that I'm using xv-blit<br>
>> output with opengl sync enabled.<br>
><br>
> . . . only when I enable OpenGL sync in mythfrontend (I also use<br>
> xv-blit, as most MythTV users do). Enabling it reliably causes a hang<br>
> within an hour or two. I can't figure out what triggers it, exactly,<br>
> but am pretty sure I've seen it outside playback (such as while<br>
> looking over a list of upcoming movies).<br>
><br>
> Disabling OpenGL sync is no hardship; as I've mentioned in a few<br>
> other messages over the past few years, RTC works just as well as<br>
> OpenGL does in my experience.<br>
><br>
<br>
</div>Wow...that's definitely the culprit. I enabled RTC in my kernel,<br>
disabled opengl timing in MythTV, and made sure it was in fact using<br>
RTC. After that I was even able to go to the 177.82 driver and was<br>
unable to cause the xscreensaver freeze. With that driver I tried<br>
enabling opengl timing again and it only took me two tries to get the<br>
paused video and xscreensaver to send the CPU into orbit.<br>
<br>
I certainly can't see any difference in picture quality using RTC. It<br>
could be my imagination, but if anything it almost seems to look<br>
better. What's more, it seems to have corrected a small issue I've<br>
had for a long time: The combination of bob x2 with 1080i ouput that<br>
I've always used had a minor issue with some shows (dramas mostly) on<br>
NBC...after the commercials, which are often different frame rates<br>
than the show, I'd get a momentary video speed up for a second. Using<br>
RTC it doesn't do that...amazing.<br>
<br>
II actually feel much better about using RTC anyway, as the less<br>
dependent I am on nVidia's proprietary crap the better. That's one of<br>
the reasons I don't use XvMC.<br>
<br>
1000 thanks for the suggestion. This has worked out just great all<br>
the way around.<br>
<br>
By the way...what's up with the Device Drivers -> Real Time Clock, vs.<br>
Device Drivers -> Character devices -> Enhanced Real Time Clock<br>
Support (the one that Myth apparently uses) in the kernel config?? I<br>
can't tell you how confused that had me.<br>
<font color="#888888"><br>
Tom<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
</div></div></blockquote></div><br>