Mythtv errors/lockups with VDPAU and 340 or 390 drivers.

I’m not a developer, but I was directed here from the Geforce forums. The next time this happens, I will attempt to run the to attach for debugging:

I’ve been using mythtv on an Arch 64-bit linux OS for a number of years and I initially had a Geforce 210 running the 304.xx drivers and never had this problem. However, if I tried to use the 340.xx drivers, when playing back video with hardware video acceleration enabled, I would randomly have the video freeze and mythfrontend would log the following error:
E Decoder mythplayer.cpp:3503 (DecoderGetFrame) Player(1): Decoder timed out waiting for free video buffers.

Looking at the code for mythplayer.cpp, it appears that it checks for free buffers and if they are not available, it waits 1s and tries again. This repeats for 10 tries before it gives up and generates this error message. When this happens, mythfrontend appears to lockup and even if I close it and restart it or use some other video playback program, I get artifacting on the screen until I reboot. So I downgraded to the 304.xx drivers and the problem went away.

Since the 210 is such an old card, I decided to replace it with a GT 710 and upgrade to the current 390.67 drivers. Unfortunately I am experiencing the same issue with the GT 710 with 390.67 drivers as the 210 with 340.xx drivers. I have not tried the GT 710 with the 340.xx drivers yet, but I am not optimistic that it will resolve the issue since those drivers were a problem with the 210.

I know of a couple other users using the same OS with the same issues and google returns a couple other instances where this has occurred, but the only resolution I found was in one case where the card was overheating. I don’t think that is the case for me since the first card was repeatably a driver issue and the current card, while passively cooled, doesn’t exceed 65C.

Is there any better way to log what is happening to the gpu to cause this issue? It appears to be a change in the driver between 304 and 340, but there must be something that could be handled differently in the mythplayer.cpp code to recover from it.

This just happened this morning so I’ve created 3 log files.

  1. While the video playback was locked up

  2. After the frontend was killed.

  3. When I relaunched the frontend and tried to start playback again. Playback appeared to load one frame and lockup.

Out of desperation, I tried to install 304 drivers and they were not compatible with the card. I now have 340 installed and will see if there is any difference.

The error is this:

[ 5296.780424] nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000917e:0:0

which is similar to this
though in that case, it works with a GK 208 and doesn’t with a GK208B.
What kind of hardware accel is mythtv using, vdpau, vaapi or nvdec?

Ok, you’re obviously using vdpau as stated in the title.

Yes, I am using vdpau. The same symptoms have been around for over 2 years using the 340 drivers with the Geforce 210:
This would almost certainly be a different GPU than the GK208.

Also, the modeset error has been inconsistent. I’ve seen it in the kernel log sometimes when this happens but not every time. Let me know if I can provide any additional useful information.

FYI, using VDPAU acceleration with Kodi and its mythtv addon (pvr.mythtv) has never caused this problem. For me, it is related to VDPAU hardware acceleration with 340 or newer drivers with both Geforce 210 & GT 710. It never happened with Geforce 210 and the 304 drivers. However, this combination caused Kodi 18 to crash immediately on playback when I attempted to use hardware acceleration, which is why I decided to try the 710 in the first place. The Geforce 210 with 340 drivers worked with Kodi, but caused these lockups in mythtv. Let me know if my details are unclear and I will try to clarify.

edit: I presume this information is available in the log, but I thought it might be pertinent to add that I have both audio and video output over hdmi.

It might be relevant what kind of material (codecs) you’ve been using/playing.

The particular video this morning was watching live tv, using an HDHomerun tuning an over the air NBC station in the US. I believe it is 1080i MPEG-2. I have also seen it happen with a DVD MPEG-2 in 480 SD (also interlaced). It usually happens while watching recorded or live television, but I’m not certain if it’s always been interlaced or if it has ever happened with progressive scan.

generix, is there anything else I can answer to help resolve this?

Hi Knappster_1
did you try this Driver Version: 387.12 ?
and try to update your ffmpeg version …
For me everything works good .

forzajuve005, thanks for the response. This has persisted across several versions of nvidia driver and several versions of ffmpeg. The past 2 versions of ffmpeg I’ve tried are 3.2.2 and 3.4.2. I’m not sure whether I’ve tried driver 387.12, but since it dates back to the 340 drivers and still happens on the latest, I wouldn’t expect it to have been resolved anywhere in between.

The lockup happened again this morning with the 340 drivers and I don’t think it contains the nvidia-modeset idling errors. I will post the log this evening when I get home.

Here is the log from this morning. Any other useful information generix?
nvidia-bug-report.log.gz (71.4 KB)

A general info about VDPAU is that development is stalled. While not officially depreciated by nvidia, recent development has only happened on nvdec/nvenc. Since v4.0, MythTV supports that so my advise is to use that.
MythTV had previously problems with VDPAU and interlaced material so they disabled deinterlacing for h264/h265. Don’t know if that applies to your issue, whether you’re using deinterlacing or not.

The content I have logged issues about has indeed been interlaced, but it was MPEG-2 content rather than h264/h265. That’s not to say that this doesn’t happen with progressive video as well, I just don’t know.

Since the issue does not sound like it will be addressed by nvidia, are there any clues in my logs as to how things in mythtv are causing it? For instance, if the issue can be handled in mythtv, then maybe I can ask their developers to address it.

Regarding nvdec/nvenc, I presume you are referring to ffmpeg 4.0? I don’t think there is a release of mythtv that uses ffmpeg 4.0 yet and even so, I don’t know if it will support nvdec. I will investigate it further, but in the meantime, is there any other assistance that you can provide?

Yes, sorry, meant a version of mythtv which incorporates ffmpeg 4.0. But it’s like you said, currently there’s no release of that yet and mythtv is not able to use ffmpeg’s nvdec support anyway. Doesn’t look good either for a quick change:
One thing to do for you would be to check whether you’re using a deinterlacer and turn that off just to check if the issue has to do with interlaced material at all.
And maybe raise your voice on the mythtv mailing lists so they see the demand for nvdec, taking into account the crumbling state of vdpau. The errors in the logs just tell of a driver internal issue.

generix, thanks for delivering the bad news. The playback works fine most of the time, it just happens occasionally (a couple times a week maybe?), but when it happens it is a big PITA. Turning off deinterlacing is not an option because then the video is unwatchable (i.e., still interlaced). I could use software decoding, but I was hoping to avoid that, which is why I went with a video card brand that typically works well with linux. I don’t suppose that there is any way to determine if there is a model of nvidia card that would not have this driver issue, is there? I’ve experienced it with both the Geforce 210 and Geforce GT 710.

I am concerned that nvidia is going to be losing some momentum in the HTPC world because VDPAU is at its end of life by the sound of things and neither mythtv nor kodi appear to be eager to adopt nvdec. Is there anything else that we can do, or is it best for me to start looking for alternative solutions?

If not turning off deinterlacing, you could use a different interlacer to see if you get better results.
Pity is, there’s little to no development in players regarding MPEG2 and interlaced material, most devs are focusing on h264/h265 now. So even players like mpv which was first to adopt nvenc only supports that but not MPEG2, afaik. So far, only ffmpeg (near to) fully implements it.