I now compiled kaffeine with debug USE flag and I get,
when changing channel, a thousends of
---
[00007f4d84007848] vdpau_display vout display error: presentation queue display failure: An invalid handle value was provided. Either the handle does not exist at all, or refers to an object of an incorrect type.
[00007f4d84007848] vdpau_display vout display error: presentation queue display failure: An invalid handle value was provided. Either the handle does not exist at all, or refers to an object of an incorrect type.
[00007f4d84007848] vdpau_display vout display error: presentation queue display failure: An invalid handle value was provided. Either the handle does not exist at all, or refers to an object of an incorrect type.
12-06-16 01:30:53.649 [System  ] tune to: "T 674000000 8MHz 2/3 NONE QAM16 8k 1/4 NONE"
----
After three channel changes kaffeine bailes out now instead of freezing the system.
A workaround is to press STOP and PLAY often.

Freezing the system sounds a symptom or either a Kernel bug or some invalid instruction sent to the GPU. What video drivers are you using? Do you have some Kernel logs? Those can be seen using the dmesg command.

I experienced something similar a few minutes ago.
Stopping playback or changing the channel after a few channel changes resulted in temporary system freeze:

dmesg shows:
Jun 14 08:29:37 Q6600 kernel: NVRM: GPU at PCI:0000:01:00
Jun 14 08:29:37 Q6600 kernel: NVRM: Xid (PCI:0000:01:00): 31, Ch 00000021, engmask 00008100, intr 10000000
Jun 14 08:29:39 Q6600 kernel: NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
Jun 14 08:29:41 Q6600 kernel: NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context

(In reply to lev.cohan from comment #3)
> I experienced something similar a few minutes ago.
> Stopping playback or changing the channel after a few channel changes
> resulted in temporary system freeze:
> 
> dmesg shows:
> Jun 14 08:29:37 Q6600 kernel: NVRM: GPU at PCI:0000:01:00
> Jun 14 08:29:37 Q6600 kernel: NVRM: Xid (PCI:0000:01:00): 31, Ch 00000021,
> engmask 00008100, intr 10000000
> Jun 14 08:29:39 Q6600 kernel: NVRM: os_schedule: Attempted to yield the CPU
> while in atomic or interrupt context
> Jun 14 08:29:41 Q6600 kernel: NVRM: os_schedule: Attempted to yield the CPU
> while in atomic or interrupt context

That sounds a bug with the Nvidia proprietary driver. There's not much open source developers can do to fix it, as the driver is closed source, and it is known to cause random troubles by the Kernel maintainers.  What the above says is that the Nvidia proprietary driver is sleeping to wait for some data in a part of the Kernel code that it is not allowed to. Only Nvidia can fix it.

You may either use the open source driver or pass some extra parameters to libVLC to use a different video output driver. Kaffeine version 2.0.3 has an option to pass such parameters, as described on its README. It was originally conceived to be a workaround for some common problems found with using via X11/VNC, but you could use it as well to force the usage of a different video driver:

---

Remote Access and Kaffeine
==========================

Accessing Kaffeine remotely via X11/ssh/vnc can be a problem, as Qt5 will,
by default, use hardware acceleration and DRI3.

There is a known bug, present on Fedora 23/24, and likely on other distros,
at mesa-libGL/dri-drivers that cause it to wait forever when it is started
from a X11 section. Such bug causes Kaffeine windows to not open:

* <https://bugzilla.redhat.com/show_bug.cgi?id=1174257>

A workaround is to start Kaffeine with:

	LIBGL_DRI3_DISABLE=1 kaffeine

Another solution is to use a vnc server.

Still, libVLC will try to use hardware acceleration on the machine with
Kaffeine, with obviously with won't work via the X11 protocol. For such
scenarios, you may try to change the arguments passed to libVLC via the
"Settings" -->  "Configure Kaffeine" -->  "libVLC", changing the libVLC
arguments to:
	--no-video-title-show -V xcb_glx
or:

	--no-video-title-show -V xcb_xv

and re-start Kaffeine.

---

As this is a Kernel bug, and we can't do much to fix,  I'm closing this bug.

As this is an issue related to hardware acceleration
and I am remembering to have had a similar issue years age:

Now, I refrain from using USE flag vdpau
and am recompiling all of that packages having vdpau
This may be equivalent to  LIBGL_DRI3_DISABLE=1

(In reply to Ralph from comment #5)
> As this is an issue related to hardware acceleration
> and I am remembering to have had a similar issue years age:
> 
> Now, I refrain from using USE flag vdpau
> and am recompiling all of that packages having vdpau
> This may be equivalent to  LIBGL_DRI3_DISABLE=1

Yeah, vdpau is something that from time to time is broken, depending on the hardware. I had to remove the Mesa vdpau on some Intel machines with newer chipsets where it weren't working properly until the vdpau weren't updated.

VLC used to have a command line argument to disable it on version 1.0.x (or 1.1.x), but it seems it has gone on newer versions.