VDPAU Error: DISPLAY PRE-EMPTED

[Dragorep]

I don't think that went quite to plan....
This machine is an AMD 2400 with 2 G RAM, so I didn't try the multiprocessor option.
See attachment for details...

[uau]

From that output it looks like the failing step is the init script trying to run 'git submodule update --init' in the ffmpeg directory. The "shift: 634: can't shift that many" message comes from git; probably the shell script implementing 'git submodule' tries to do something completely nonsensical. As far as I can tell that's a bug in your git version (1.5.6.3 is relatively old). You could try manually running 'git submodule init; git submodule update' in the ffmpeg directory; if it creates a ffmpeg/libswscale directory populated with files then things should probably work. Other than that I can't help as I don't know what git bug you're encountering. You should probably try to get a fixed (newer) git version from somewhere.

[jyavenard]

Originally Posted by AaronP

Does the display recover after that? I believe the driver can indicate that the display was preempted for pretty much any reason whenever it wants, and the application is supposed to recreate the VDPAU objects. If MythTV simply reports it as an error and exits, then it needs to be fixed.

That said, are the display preemptions accompanied by NVRM Xid messages in the syslog?

WithTV 0.21 with the VDPAU support patch, doesn't support recovering from a preemption error.

MythTV trunk (and 0.22 when it comes out) will support recovery but going back to software decoding rather than just exiting.

I won't be doing any more improvement on the VDPAU support for 0.21 as 0.22 is quite close to release.

[Dragorep]

Originally Posted by jyavenard

WithTV 0.21 with the VDPAU support patch, doesn't support recovering from a preemption error.

MythTV trunk (and 0.22 when it comes out) will support recovery but going back to software decoding rather than just exiting.

I note the comments about recovering from the errors, isn't the root issue that they occur at all?

As best I can tell that is an issue for the NVIDIA drivers to handle content without producing the errors?

The pre vdpau cards / drivers were stable for me.

Clarification from NVIDIA would be appreciated.

[hl_]

Display preemption also happens when you switch resolution or change to another VT. Which means it's not exactly an error condition usually. According to the API documentation, applications should recreate all VDPAU objects after preemption occurs, but that's not very easy sometimes.

It'd be great if the driver dealt with these events in a more transparent manner.

[Dragorep]

This seems to be some of the API information, FWIW:

ftp://download.nvidia.com/XFree86/vd...reemption.html

[Stephen Warren]

Originally Posted by Dragorep

Was that reply for the 9400, the 8500, or indeed for both?

Those XIDs were from the 9400 log.

The 8500 nvidia-bug-report doesn't show any XIDs.

Unfortunately, the 8500 Myth log doesn't include any VDPAU debugging information. Can you please set the following environment variable in the MythTV frontend (most likely, run the following command in the shell you use to launch MythTV):

export VDPAU_NVIDIA_DEBUG=3

and verify that the log shows some form of VDPAU error message and backtrace when the pre-emption occurs. This information may show where the problem is occurring.

Thanks.

[Dragorep]

OK have been monitoring, so far its not pre-empted, must know I watching for it now!!

Did get this error, which is not pre-emption and may be more for the mythtv guys, but I report it here as some of them are watching this thread too and it also should not happen.

The attachment occurred during an automatic transition from Live TV to recording a pre-set program on the same channel.

I'll front up with pre-emption info when obtained.

[Dragorep]

Got a crash overnight, debug information missing as terminal filled with too many subsequent messages....

2009-09-23 06:00:02.212 NVP: prebuffering pause
2009-09-23 06:00:02.222 NVP: prebuffering pause
2009-09-23 06:00:02.233 NVP: prebuffering pause
2009-09-23 06:00:02.243 NVP: prebuffering pause
2009-09-23 06:00:02.323 NVP: Prebuffer wait timed out 1243740 times.
2009-09-23 06:00:02.323 NVP, Error: Timed out waiting for prebuffering too long. Exiting..

Is there a way to write the debug information to a file?

Perhaps the attachment helps?

[Stephen Warren]

The VDPAU errors in comment #20 simply indicate that the overlay-based presentation queue could not be allocated. This probably isn't related to your issue.

Re: comment #21: VDPAU errors are printed to stdout and/or stderr. You should be able to redirect these to a file using:

command > logfile.txt 2>&1

where "command" is whatever you normally run.

[Dragorep]

Thank you Stephen

I'd first like to express my thanks for NVIDIA's continuing prompt attention in this thread, I guess it says NVIDIA is also concerned about this issue. As I am too, I thank you.

The error has predictably recurred, this time I got the data sought, as attached. I also attach the NVIDIA output file, but am not sure if you need more of these for the same machine?

Looking forward to hearing again.

[Stephen Warren]

Those logs show some kind of issue processing the video bitstream. There have been many improvements to this area of the driver since 180.60. Can you please try the latest 190.* driver from the FTP site? It may very well solve the issue.

If that doesn't help, I think we'll need to see a sample video file; see the VDPAU sticky for upload details. It'd also help if you could test MPlayer with VDPAU and the same file, and see if that has the same issue,

Thanks.