Bug 376844 - Freeze at channel switching with GPU/VDPAU
Summary: Freeze at channel switching with GPU/VDPAU
Status: RESOLVED NOT A BUG
Alias: None
Product: kaffeine
Classification: Applications
Component: general (show other bugs)
Version: 2.0.5
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Mauro Carvalho Chehab
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-23 13:37 UTC by Tenzin
Modified: 2018-05-30 12:11 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tenzin 2017-02-23 13:37:59 UTC
Hi,
I'm using Kaffeine 2.0.5 on Ubuntu 16.04, to watch DVB with a Hauppauge nova-t-hd.
It works fine usually but quite often it freezes at channel switching. Ubuntu is continuing to work, but no way to restart Kaffeine, I have to reboot the system. And Ubuntu doesn't show any crash message.

Is there something to do ?
Thank you for your help.
Tenzin.
Comment 1 Mauro Carvalho Chehab 2017-02-23 17:44:59 UTC
(In reply to Tenzin from comment #0)
> Hi,
> I'm using Kaffeine 2.0.5 on Ubuntu 16.04, to watch DVB with a Hauppauge
> nova-t-hd.
> It works fine usually but quite often it freezes at channel switching.
> Ubuntu is continuing to work, but no way to restart Kaffeine, I have to
> reboot the system. And Ubuntu doesn't show any crash message.
> 
> Is there something to do ?

What do you mean by "freezing"? just Kaffeine application becomes irresponsible? Can it be killed with "killall -9 kaffeine"?
Comment 2 Michael Zapf 2017-02-24 12:07:08 UTC
I have the same problem. As I learned, kaffeine has switched from xine to vlc, and so I tried to watch TV on vlc directly.

When I use VDPAU, VLC freezes at some occasions when switching channels. When I change the output to "OpenGL GLX video output", I never experienced a freeze when switching channels.

(Freeze: The video/audio output stops, but the program is still responsive. In Kaffeine, however, when I press the stop button, the button seems to freeze as well in that occasion.)

Now in Kaffeine, there is a setting for libVLC. But although I added the parameter "--vout=glx_xcb", there are still freezes for Kaffeine. So maybe I did it wrong, but I think I read somewhere that the vout parameter is ignored at that point.

Also, I found that when I stop DVB in kaffeine with the Stop button, I can avoid freezes for most of the time; they sometimes still occur, but rarely.
Comment 3 Mauro Carvalho Chehab 2017-02-24 14:07:02 UTC
(In reply to Michael Zapf from comment #2)
> I have the same problem. As I learned, kaffeine has switched from xine to
> vlc, and so I tried to watch TV on vlc directly.
> 
> When I use VDPAU, VLC freezes at some occasions when switching channels.
> When I change the output to "OpenGL GLX video output", I never experienced a
> freeze when switching channels.

Ah! That could very likely be due to GPU driver issues, specially if you're using some proprietary driver. If this is a GPU driver issue, I guess there's not much we can do at Kaffeine side.

> 
> (Freeze: The video/audio output stops, but the program is still responsive.
> In Kaffeine, however, when I press the stop button, the button seems to
> freeze as well in that occasion.)

Hmm... libVLC sometimes don't synchronize with a mpeg-TS screen, with causes it to fail parsing it. That happens even with recorded videos when played on vlc. There are some improvements on it at version 3.0 (although "version 3.0" is actually a rolling version, as its final release didn't happen yet - so results may vary, depending on the patches applied to it).

> 
> Now in Kaffeine, there is a setting for libVLC. But although I added the
> parameter "--vout=glx_xcb", there are still freezes for Kaffeine. So maybe I
> did it wrong, but I think I read somewhere that the vout parameter is
> ignored at that point.

You need to restart Kaffeine for it to use --vout. This parameter is passed when Kaffeine starts the libVLC backend, so it should not be ignored.

Unfortunately, even on current versions of libVLC, there's no way to configure the vout in runtime. I've been discussing with VLC developers for a while about adding a way to better control vout and mouse events passed to it, in order to fix BZ#373814.

> Also, I found that when I stop DVB in kaffeine with the Stop button, I can
> avoid freezes for most of the time; they sometimes still occur, but rarely.

Not sure if, currently, changing channels makes libvlc to stop/restart, but I guess it doesn't. I'll take deeper a look, but such kind of change may slow down channel changes and cause issues with pause.
Comment 4 Michael Zapf 2017-02-24 14:29:53 UTC
The problem appeared after my hardware upgrade (including a RX 480) and operating system upgrade (openSUSE Tumbleweed). Had to go to Tumbleweed (rolling release) because the Catalyst driver has become unavailable, and the RX 480 is only supported in later releases of the OSS driver (amdgpu). So in contrast, I'm not using the proprietary driver anymore.

However, with all these changes, including kaffeine's switch to VLC, it is hard to tell where the problem actually is.

What I saw was that despite my setting of vout (and restart of kaffeine), I'm getting these lines:

24-02-17 15:27:01.255 [Info    ] Using built-in dvb device manager
24-02-17 15:27:01.821 [Info    ] Found dvb device : Montage Technology DS3000
[00007f0d7c093fa8] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding.

libVLC arguments are: --no-video-title-show --vout=glx_xcb

(Where can I actually find the values for vout? Not even the man page of vlc was helpful in that respect.)
Comment 5 Michael Zapf 2017-02-24 14:37:41 UTC
Just noticed that vlc outputs the same line "Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding" although video is set to OpenGL GLX video output (XCB).
Comment 6 yulinux 2017-02-24 16:57:17 UTC
(In reply to Michael Zapf from comment #4)
> (Where can I actually find the values for vout? Not even the man page of vlc
> was helpful in that respect.)
I have the same problem, vlc -H gives some more information. But I can't really make kaffeine do what VLC does. In my case the performace in kaffeine is bad, but in VLC and in other players it is good. I will open a separate bug for it.

BTW: Do you use wayland? I use it and there were problems with the detection of the correct driver for VDPAU. I had to set an environment variable in order to use VDPAU_DRIVER=r600 instead of nvidia. And maybe it gives helpful information when using also -v (or -vv )
Comment 7 Tenzin 2017-03-07 13:03:23 UTC
> What do you mean by "freezing"? just Kaffeine application becomes
> irresponsible? Can it be killed with "killall -9 kaffeine"?

Hello,
I've had to wait for a new bug to try this, and exceptionally it has taken a week to crash again. 
It can be killed by "killall -9 kaffeine", but it's still impossible to re-launch without rebooting ubuntu.
By "freezing" I mean Kaffeine becomes irresponsible. Even getting out of the fullscreen mode is impossible.
Comment 8 Mauro Carvalho Chehab 2017-10-04 12:18:04 UTC
There were several performance improvements on Kaffeine since version 2.0.5. Could you please check if this bug still happens on Kaffeine version 2.0.13?
Comment 9 Michael Zapf 2017-10-08 16:07:59 UTC
I used VLC in the meantime; trying Kaffeine now, almost none of my channels can be tuned anymore; only a few are working. I'll have to check that first. VLC is still working, though.
Comment 10 romeoK 2018-05-01 11:58:30 UTC
Same error here with Kaffeine 2.0.14

While switching through the channellist using keyboard or mouse, sometimes suddenly Kaffeine freezes video and audio.

In the terminal window it then prints continously the following error message: 

Failed to idle DMA
Failed to idle DMA
Failed to idle DMA
etc.

The complete system seems to hang then, the mouse barely moves. I have to press strg-alt-backspace to logout (takes up to 10 seconds until keypress is recognised by the system)

When i log back in, often i need to kill the process Kaffeine first before i can use it again.

The "failed to idle DMA" only happens when switching through channels 1 out of ~25 times. It happens in fullscreen as well as in windowed-modes.
Comment 11 Mauro Carvalho Chehab 2018-05-01 12:15:47 UTC
(In reply to romeoK from comment #10)
> Same error here with Kaffeine 2.0.14
> 
> While switching through the channellist using keyboard or mouse, sometimes
> suddenly Kaffeine freezes video and audio.
> 
> In the terminal window it then prints continously the following error
> message: 
> 
> Failed to idle DMA
> Failed to idle DMA
> Failed to idle DMA
> etc.
> 
> The complete system seems to hang then, the mouse barely moves. I have to
> press strg-alt-backspace to logout (takes up to 10 seconds until keypress is
> recognised by the system)
> 
> When i log back in, often i need to kill the process Kaffeine first before i
> can use it again.
> 
> The "failed to idle DMA" only happens when switching through channels 1 out
> of ~25 times. It happens in fullscreen as well as in windowed-modes.

The error message means that there's something wrong with the hardware/driver when managing the Direct Memory Access (DMA) channels.

Are you using any proprietary driver? I suspect so, as, on a quick search for this message, it seems that it is produced by the closed-source Nvidia driver:

https://devtalk.nvidia.com/default/topic/1020399/linux/vdpau-fails-decoding-mpeg2-on-gtx-660-and-384-59/2

In any case, this is unrelated to Kaffeine.

If it is for a proprietary driver, you should complain to the ones that have access to their source code, e. g. to the hardware manufacturer.

Another option would be to either uninstall the proprietary driver or disable its usage by libVLC. See the README.md file for some instructions about some parameters that could be passed to libVLC in order to disable the usage of vdpau and/or other broken graphics accel.
Comment 12 romeoK 2018-05-01 12:26:00 UTC
Ok thanks, you are right, i am using

avcodec decoder: Using NVIDIA VDPAU Driver Shared Library  384.111  Tue Dec 19 22:55:29 PST 2017 for hardware decoding.

I will try what you suggested with the libVLC parameters.
Comment 13 romeoK 2018-05-13 13:36:47 UTC
I had several other continous errors and freezes when switching channels, like below:

core input error: ES_OUT_SET_(GROUP_)PCR  is called too late (pts_delay increased to 300 ms)
core input error: ES_OUT_RESET_PCR called

and also

Stream seems to be too havy[sic] to be displayed.

I could completely get rid of all these errors by setting the following parameter:

--file-caching 1000 (tested with lower values too, but gave above errors again).

I'm not sure why file-caching and not live-caching has to be altered, but it works. 
Hopefully this helps someone, and maybe the vlc buffer could be raised by default?
Comment 14 romeoK 2018-05-13 21:42:03 UTC
I need to withdraw from my above statement. After doing more tests (with hundred of freezes) and searching the web for another 10 hours, i have to agree with Mauro, that when you have an nvidia card and using proprietary driver with Kaffeine/libVLC, the only way to overcome the 'failed to idle DMA' error, is to disable vdpau (until nvidia has fixed this problem). So i inserted the line 'export VDPAU_DRIVER=none' into /home/.profile , and have had no freezes and errors until now.
Comment 15 Mauro Carvalho Chehab 2018-05-30 12:11:50 UTC
(In reply to romeoK from comment #14)
> I need to withdraw from my above statement. After doing more tests (with
> hundred of freezes) and searching the web for another 10 hours, i have to
> agree with Mauro, that when you have an nvidia card and using proprietary
> driver with Kaffeine/libVLC, the only way to overcome the 'failed to idle
> DMA' error, is to disable vdpau (until nvidia has fixed this problem). So i
> inserted the line 'export VDPAU_DRIVER=none' into /home/.profile , and have
> had no freezes and errors until now.

Thanks for your tests! Unfortunately, proprietary drivers like NVidia are well known by causing all sorts of troubles, and there's nothing we can do to solve, as only the vendor has access to the source code. Usually, those drivers are actually designed to work on another OS and has only a "shelf" to run on Linux. That's sub-optimal, and may lead into starving of resources, with seems to be the case here.

As this is not a Kaffeine bug, and the issues are already commented at README.md, I don't see anything more that we could do.

So, I'm closing it.