[mythtv-users] Re: widespread reports of (sort of) the
Dean Vanden Heuvel
deanv at cox.net
Tue Dec 7 02:54:25 UTC 2004
after trying many things, and following many leads, I stumbled across a
couple of posts on the dev board related to OpenGL vsync. Apparently,
there is some problem assuring that it is being used (if you so compile)
and there are compatibility problems with some versions of the Nvidia
drivers. According to the knowledge I have been able to gather, my
rather recent (611 and newer) Nvidia drivers SHOULD work with OpenGl
vsync, however, when I recompile after altering settings.pro to assure
not using OpenGL, my playback and live TV start and run each and every
time (at least so far...), so it appears that OpenGL is definitely
involved. There is also a post on the dev list talking about how to
patch some OpenGL vsync code in hopes of getting it to work. It has not
worked for me. Here is the post
Can anyone help me with how I would detect which vsync method is
actually being used? What debug info would show this? Any ideas on how
to get OpenGl vsync active?
nate s wrote:
>I'd just like to mention that I've been using the ~x86 branch of
>gentoo with no problems, son it's not necessairly a gentoo, ~x86
>On Tue, 30 Nov 2004 21:59:03 -0700, Dean Vanden Heuvel <deanv at cox.net> wrote:
>>I also am using Gentoo, and have tried (as I said above) may MANY
>>kernels. Currently I am using 2.6.9-gentoo-r4.
>>I just tried using "mythfrontend --verbose playback" and forced a
>>failure. Here is the error message:
>>2004-11-30 21:39:47.884 Estimated bitrate = 384000
>>2004-11-30 21:39:48.222 Position map filled from DB to: 27008
>>2004-11-30 21:39:48.228 SyncPositionMap prerecorded, from DB: 27009 entries
>>2004-11-30 21:39:48.229 detectInterlace(Ignore Scan, Interlaced Scan,
>>29.97, 480) ->Interlaced Scan
>>2004-11-30 21:39:48.229 Interlaced: Interlaced Scan video_height: 480
>>2004-11-30 21:39:48.231 Position map found
>>2004-11-30 21:39:48.234 Opening audio device 'analog'.
>>2004-11-30 21:39:48.244 Over/underscan. V: 0, H: 0, XOff: 0, YOff: 5
>>2004-11-30 21:39:48.298 switchToVid: Video size 720 x 480: Switched to
>>resolution 720 x 480 650mm x 366mm
>>2004-11-30 21:39:48.299 Using XV port 105
>>2004-11-30 21:39:48.303 Image size. dispxoff 0, dispyoff: 0, dispwoff:
>>720, disphoff: 479
>>2004-11-30 21:39:48.303 Image size. imgx 0, imgy: 0, imgw: 720, imgh: 480
>>2004-11-30 21:39:48.664 Changing from None to WatchingPreRecorded
>>2004-11-30 21:39:48.665 Using deinterlace method bobdeint
>>2004-11-30 21:39:48.666 Using realtime priority.
>>2004-11-30 21:39:48.766 nVidiaVideoSync: VBlank ioctl did not work,
>>unimplemented in this driver?
>>2004-11-30 21:39:48.769 DRMVideoSync: Could not open device
>>/dev/dri/card0, No such file or directory
>>perhaps someone will have some advice with this help...
>>Marc Tousignant wrote:
>>>>Firstly has this been brought up on the ivtv lists?
>>>>Well the difference is not necessarily that it is "doing something
>>>>different" the second time around.
>>>>More likely scenarios are:
>>>>1. that something either hasn't been closed down correctly after the
>>>>2. that some resource has been locked and not freed correctly after the
>>>>3. that something has been closed down "too properly" after the first
>>>>run and isn't getting reinitialised.
>>>>Next do you have any options for increasing the verbosity of the logging
>>>>in the ivtv driver?
>>>>Finally what happens if you unload and reload all of the ivtv drivers
>>>>after the first run?
>>>I was having this same problem with Gentoo.
>>>I completely reinstalled using x86 instead of ~x86 and the error is gone.
>>>~x86 was used only for certain programs like mythtv, video drivers,
>>>and a few other things.
>>>I am running the 2.6.9-rc2-love4 kernel with the new tuners pack
>>>applied. I have tuner # 47.
>>>I'm using the CVS version from this morning, do not have version # on
>>>hand, thou I was using one from Friday prior to this and the issue was
>>>not there either. This seems to have been caused by a program MythTV
>>>or the IVTV drivers rely on which is only available in the Gentoo ~x86
>>>With this new install I was having a problem with watching TV after a
>>>show finished recording. Was getting the can not connect to the
>>>capture device after 15 seconds game over message. I identified this
>>>as being caused by MythTV running the commercial flagging process.
>>>Once I stopped it from flagging commercials the 15 second error stopped.
>>>Now the only problem I am having is that if I try to do anything while
>>>a recording is in progress said recording bombs.
>>>If I am watching TV when the recording starts and choose to watch as
>>>it records it works fine.
>>>If I am 15 mins late and choose to start watching the recording in
>>>progress: I lets me watch, however, nothing is actually recorded after
>>>I start watching. Also, it says it is recording even thou it bombed
>>>and the backend has to be restarted to get it to realize that it is
>>>not recording anymore. This prohibits you from recording any other
>>>shows or watching live tv until the backend is restarted.
>>>It seems to be that if I look at the watch recordings page at all it
>>>Also if I am watching a previously recorded show at the time a
>>>recording starts: the new recording bombs within seconds.
>>>I'm leaning towards believing this is a HDD or file system issue. I am
>>>running reiserfs on all but my boot drive. Has anyone had bad
>>>experiences with this file system?
>>>One of the guides I read said use xfs thou another one said reiserfs
>>>would work just as well.
>>>I have used reiserfs for a long time without any issues prior to this.
>>>mythtv-users mailing list
>>>mythtv-users at mythtv.org
>>mythtv-users mailing list
>>mythtv-users at mythtv.org
>>mythtv-users mailing list
>>mythtv-users at mythtv.org
More information about the mythtv-users