Opened 4 years ago

Closed 3 years ago

#11729 closed Bug Report - General (Upstream Bug)

video play double speed (too fast), audio plays normal speed, nouveau driver only

Reported by: Trevor Cordes <mythtv@…> Owned by:
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: 0.26
Severity: medium Keywords: video double speed audio normal
Cc: Ticket locked: no


I upgraded from Fedora 18 (nv driver) to 19 (nouveau driver, as 19 got rid of nv), and all myth viewing started having double-speed video, but the audio was still 100% ok (normal speed). 18 to 19 did not change the myth versions.

I tried every myth option, every decoder, every deinterlacer, and it stayed double speed. Even setting audio to NULL didn't help. Did it on live TV as well as recordings.

When I did an while-watching options->playback->playbackdata it would show the mpg was 29.97 fps and the playback FPS was 59.75 to 59.99!!

Testing with mythavtest -O LocalHostName?=abcdefg /data/Mythtv/Recordings/1888_20130708085900.mpg made no difference. It still played double-speed.

Testing with mplayer /data/Mythtv/Recordings/1888_20130708085900.mpg and the video was fine (not double-speed). Problem is in myth only.

I switch to the binary nvidia driver and the video was fine (not double-speed) without any other changes. So the problem appears to be unique to the nouveau driver.

The output from myth while double-speed shows nothing out of the ordinary.

xorg-x11-drv-nouveau-1.0.9-1.fc19.i686 mythtv-frontend-0.26.0-9.fc19.i686 kmod-nvidia-304xx-3.10.4-300.fc19.i686.PAE-304.88-2.fc19.i686 xorg-x11-drv-nvidia-304xx-304.88-12.fc19.i686

Attachments (4)

mythdebug.txt (514.9 KB) - added by anonymous 4 years ago.
output of "mythfrontend -v audio,playback --loglevel=debug"
test.patch (930 bytes) - added by jyavenard 4 years ago.
attempted fix
drm-nouveau-set-irq_enabled-manually.patch (1.4 KB) - added by Cédric Schieli <cschieli@…> 3 years ago.
Kernel patch
workaround.patch (445 bytes) - added by Cédric Schieli <cschieli@…> 3 years ago.
MythTV patch (interim workaround)

Download all attachments as: .zip

Change History (29)

comment:1 Changed 4 years ago by wagnerrp

xorg-x11-drv-nouveau-1.0.9-1.fc19.i686 mythtv-frontend-0.26.0-9.fc19.i686 kmod-nvidia-304xx-3.10.4-300.fc19.i686.PAE-304.88-2.fc19.i686 xorg-x11-drv-nvidia-304xx-304.88-12.fc19.i686

nVidia drivers replace the stock Xorg OpenGL library with their own. This has caused problems in the past when users have tried to use an ATI card with the nVidia drivers installed. Is it possible this is the cause of your behavior?

comment:2 Changed 4 years ago by Trevor Cordes <mythtv@…>

I don't think so because during the problem I had zero nvidia proprietary things installed (and never had). I only put the nvidia stuff in after I couldn't solve the problem with nouveau.

With the nvidia stuff in (and nouveau off) everything now works perfectly.

However, I prefer to use open source drivers where possible.


Changed 4 years ago by anonymous

output of "mythfrontend -v audio,playback --loglevel=debug"

Changed 4 years ago by jyavenard

attempted fix

comment:3 Changed 3 years ago by Trevor Cordes <mythtv@…>

Nope, the patch doesn't help at all. Sorry for the delay, but it took me a while to setup a build-capable box. I now can build & test much quicker. Any other ideas? Now I'm stuck in nouveau again because switching between nvidia/nouveau is quite a complex process :-)

comment:4 Changed 3 years ago by paul@…

I also just tried the patch on Gentoo, by dropping the file here:


The patch applied successfully, but it had no effect on this bug.

comment:5 Changed 3 years ago by Trevor Cordes <mythtv@…>

I'm starting to wonder why this is hitting very few people. If it was simply a matter of new nouveaus breaking myth playback, there should be hundreds of "me toos". Perhaps it only hits certain cards with certain modes.

My card is a quite old: NVIDIA Corporation G73 7600 GS? (rev a1)

Perhaps it only affects old cards? Comments from the others seeing this bug?

comment:6 Changed 3 years ago by stuartm

I'd bet that almost no-one is using Nouveau with MythTV. The proprietary driver works very well and supports hardware decoding via VDPAU, given that, what advantage does Nouveau offer apart from being an idealogical choice?

comment:7 Changed 3 years ago by Peter <peterpf_mitchell@…>

I discovered yesterday evening that I am also suffering this issue: Fedora 18 with 0.26 fixes. Graphics card is an ancient Nvidia GT6600. This is running with the Nouveau driver as obviously the GT6600 does not support VDPAU.

The machine used to be my combined frontend / backend but a few months ago I built a new dedicated i5 based frontend with a GT640 - also Fedora 18 based but using the NVidia propriety drivers and as a result I have not touched the frontend on the old machine for a while. It is now mainly used as the backend.

When I initially set up the old machine in its current configuration (approx 3 months ago) the frontend was working correctly using the Nouveau driver, however last night I discovered that video was now running fast with audio at the correct rate. The only changes that have happened to the backend is the installation of updates via yum update. I suspect that something has changed within the Nouveau driver that is causing the frontend to experience issues.

My new frontend with the propriety NVidia drivers continues to work correctly although it is not quite as up to date int terms of the installed packages.

Incidentally some time ago I did have the old GT6600 based machine running with Fedora 16 + Myth 0.25 and using the Nvidia driver however there was no benefit to me from using the NVidia driver and in fact I experienced stability issues that were resolved by reverting to Nouveau. For this reason when I upgraded to Fedora 18 + 0.26 I did not bother trying the Nvidia driver with that particular graphics card.

comment:8 Changed 3 years ago by paul@…

I use an integrated GeForce? 7050 PV. At the time I switched from nvidia to nouveau (a couple years ago), it had smoother video playback, and better text console compatibility.

comment:9 Changed 3 years ago by brendan@…

I have the same issue with a NVidia GeForce? 8600 GT card with the nouveau driver. I am running the lastest kernel (3.11.3).



comment:10 Changed 3 years ago by Trevor Cordes <mythtv@…>

So far it looks like everyone has a 4-digit older Nvidia card, and no one with a 3-digit newer card. So it looks like something in nouveau changed, at least with regards to older cards.

I opened a fedora bugzilla for this now:

comment:11 Changed 3 years ago by mythtv@…

VGA compatible controller: NVIDIA Corporation GF114 GTX 560 Ti? (rev a1)

with nouveau driver

comment:12 Changed 3 years ago by sherif.onion@…

I can confirm this on a brand new system using a GeForce? GT 610 - video way fast and out of sync with audio within Myth TV using open source drivers.

Video playback is perfect with other video apps - it is only ONLY MythTV that is misbehaving.

comment:13 Changed 3 years ago by sherif.onion@…

Just installed nvidia drivers (yuk - now tty1-6 resolution is horrid - huge text [which is why I wanted to avoid the proprietary driver]).. but now Myth frontend plays correctly :)

I still think the comment "Though I think this is probably a nouveau thing, not a myth thing." is erroneous though. If other video apps (mplayer, vlc, etc.) work, but myth doesn't, it seem pretty obvious to me whose software is mucking it up...

comment:14 Changed 3 years ago by kielogl@…

I have same problem with nouveau driver and VGA compatible controller: NVIDIA Corporation G96 9400 GT? (rev a1). mplayer works fine.

comment:15 Changed 3 years ago by myoung008@…

I have the same issue on two machines: Media center system with 610M - currently using nvidia drivers but would like to go multi-seat with nouveau. Also have an AMD/ATI card on order so I can try it's open drivers instead.

Laptop with Quadro 2700M - Running nouveau because nvidia drivers are a pain to configure several different multi-screen setups. Nvidia proprietary also seems to lock the card at it's max frequency eating battery life and causing the system to occasionally drop performance levels to pentium-pro days (thermal protect I believe).

Both are running near identical copies of Gentoo, mostly stable. Media kernel is 3.10.x (x=11 IIRC), Laptop is 3.11.6. I've tried lots of kernels from the 3.9 - 3.12pre range to address the problem. Nothing I've found fixes the problem RELIABLY. The problem shows up when myth chooses the DRI video timing method. Some 3.10 kernels with Nouveau fixed the issue on the laptop occasionally by falling back to other timing methods, but in those cases the processor was used 100% and video was stalling a couple times per second.

Looking through the video timing source I found that myth always looks to /dev/dri/card0 for timing. That will probably affect my multi-seat setup when I get it working (...with mythtv -- I've had it working with most everything else already). Would like to do two mythtv seats from that PC (and two desktop seats).

comment:16 Changed 3 years ago by astroparticle0@…

I have this same issue in MythTV 0.27 on two Arch Linux machines, although it is not playing at quite double speed (don't think my hardware can keep up with 60 Hz)

One machine is using the noveau driver with an Nvidia 6200.

The other is using the Intel driver with an Intel GM45 Express chipset. On this machine, it happens whether or not I'm using VAAPI.

comment:17 Changed 3 years ago by sumnerfit@…

Add me to the list. GT220 on a new install. I had it running fine on a clean install until steam complained about video drivers needing to be upgraded. I obliged with new nvidia proprietary drivers and now have this problem.

comment:18 Changed 3 years ago by wagnerrp

  • Ticket locked set

Too many "me too" comments. Locking ticket.

Please read the Ticket HowTo.

comment:19 Changed 3 years ago by xris

  • Ticket locked unset

Just an FYI for those of you watching this. I thought that this issue might be affecting me but it turns out that some process (maybe an errant db migration or renaming of my mythbox network name) resulted in the audio sync playback setting being bumped to its maximum value. It's something I should have checked first thing when debugging this, but it never even occurred to me to do so because I haven't had to touch that setting since very early analog capture cards.

Anyway, I'm going to unlock the ticket with the hope that this is the case for other people, but please restrain from too many "me too" comments or it will be locked again. The original purpose of this bug is the double playback speed, not the audio sync issue.

comment:20 Changed 3 years ago by mythtv@…

How do we as testers check if your audio-sync setting is causing this problem on our systems? Can you give explicit instructions on what to check or test? Thanks!

comment:21 Changed 3 years ago by xris

While watching a recording, press M and scroll down to the audio section. I can't remember the specific wording, but sync is in there. Once you select it, you will get another popup that lets you adjust the sync timing fast or slow.

comment:22 Changed 3 years ago by lklinker@…

Running Ubuntu 13.10 - Myth 0.27 - NVIDIA NV25 GeForce4 Ti4200 Just updated to kernel version 3.11.0-17-generic that would finally work with my network card. Prior versions would not boot up. Started viewing a recording and saw the double speed video. Found this thread and tried the suggestion with the audio-sync. Did not notice any change at all. Re-booted to the prior kernel 3.8.0-32-generic and everything works fine.

comment:23 Changed 3 years ago by Russell Knighton <russell@…>

I have checked my audio-sync settings, and these are as expected, yet I am also experiencing this double-speed video with normal speed audio problem. (It's more like 3-4x speed on my system, so I presume it appears differently on different hardware specs..)

I have also tried the above "test.patch", but I haven't seen any difference.

What is the next step to help diagnose the cause of this problem? I'd like to move exclusively to using the nouveau driver, especially now that is supports full VDPAU on my hardware.

Some additional info that might help:

starbug ~ # uname -a Linux starbug 3.13.4-gentoo #1 SMP PREEMPT Sun Feb 23 14:57:28 GMT 2014 x86_64 Intel(R) Core(TM) i7-2600S CPU @ 2.80GHz GenuineIntel GNU/Linux

starbug ~ # lspci | grep -i vga 06:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 430] (rev a1)

starbug ~ # mythfrontend --version Please attach all output as a file in bug reports. MythTV Version : 317d5b7 MythTV Branch : tag: v0.27 Network Protocol : 77 Library API : 0.27.20131107-1 QT Version : 4.8.5 Options compiled in: linux profile use_hidesyms using_alsa using_oss using_backend using_bindings_python using_bindings_php using_dvb using_frontend using_hdhomerun using_ceton using_hdpvr using_ivtv using_libcrypto using_libfftw3 using_libxml2 using_libudf using_lirc using_mheg using_opengl using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv using_profiletype using_mythlogserver using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2 using_libudf

Changed 3 years ago by Cédric Schieli <cschieli@…>

Kernel patch

Changed 3 years ago by Cédric Schieli <cschieli@…>

MythTV patch (interim workaround)

comment:24 Changed 3 years ago by Cédric Schieli <cschieli@…>

This is definitely a kernel bug. It was introduced in commit 0fa9061ae8c and will be fixed in 3.14 (commit 7d3428cd4b2). The patch has also been queued for stable kernel branches 3.10 and 3.13.

Due to this bug, the calls to DRM_IOCTL_WAIT_VBLANK in libmythtv/vsync.cpp were returning immediately, resulting in the anormal speed.

I've patched my 3.11 Ubuntu kernel with drm-nouveau-set-irq_enabled-manually.patch and everything work smoothly here. Alternately it is possible to workaround the problem by patching MythTV to skip DRM VSYNC timing : workaround.patch

comment:25 Changed 3 years ago by mdean

  • Resolution set to Upstream Bug
  • Status changed from new to closed

Upstream bug in kernel (see comment:24 ).

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'new'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.