+++ This bug was initially created as a clone of Bug #806558 +++
Created attachment 572461 [details]
.xsession-errors with DVB error messages
Description of problem:
Yesterday Kaffeine worked fine. Today I upgraded to latest packages, including KDE 4.8.1. Now trying to watch DVB-T television gives "read error".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start Kaffeine
2. Try to watch DVB-T television
I have an af9015 DVB-T tuner.
.xsession-errors shows a lot of error messages.
--- Additional comment from email@example.com on 2012-03-24 16:05:42 EDT ---
rpm -q xine-lib xine-lib-extra-freeworld
--- Additional comment from firstname.lastname@example.org on 2012-03-24 16:57:57 EDT ---
I don't think the KDE SC update can possibly have anything to do with this problem. It looks like a problem in a component closer to the hardware (kernel, maybe?).
--- Additional comment from email@example.com on 2012-03-24 20:21:13 EDT ---
I have dvb-t problems as well. tzap (from dvb-apps) does show signal strength but xine won't connect if I am using kernel-3.3.0-4.fc16.x86_64 . If instead I boot with kernel-3.2.10-3.fc16.x86_64 then I can use xine to watch TV.
--- Additional comment from firstname.lastname@example.org on 2012-03-24 20:29:54 EDT ---
Looks very much like a kernel bug then. Juhani Jaakola, are you sure it doesn't work with kernel 3.2.9?
--- Additional comment from email@example.com on 2012-03-25 02:32:04 EDT ---
(In reply to comment #1)
> rpm -q xine-lib xine-lib-extra-freeworld
$ rpm -q xine-lib xine-lib-extra-freeworld
package xine-lib-extra-freeworld is not installed
--- Additional comment from firstname.lastname@example.org on 2012-03-25 02:47:58 EDT ---
It's "xine-lib-extras-freeworld" with an 's'!
--- Additional comment from email@example.com on 2012-03-25 02:52:10 EDT ---
(In reply to comment #4)
> Looks very much like a kernel bug then. Juhani Jaakola, are you sure it doesn't
> work with kernel 3.2.9?
I re-tested Kaffeine with kernels 3.3.0-4.fc16.i686.PAE and 3.2.9-2.fc16.i686.PAE today. They both give error message "No device found".
In fact when I looked in Kaffeine at Television -> Configure Television, it shoud two devices:
Name: Afatech AF9013 DVB-T
Device not connected.
Name: Afatech AF9013
(other data seems sensible, no error messages)
I removed Device 1, so that only one device is left. Then I try to watch a channel, but I still get error No device found.
By the way, I'm using firmware dvb-usb-af9015.fw version 126.96.36.199
--- Additional comment from firstname.lastname@example.org on 2012-03-25 02:53:30 EDT ---
(In reply to comment #6)
> It's "xine-lib-extras-freeworld" with an 's'!
$ rpm -q xine-lib-extras-freeworld
--- Additional comment from email@example.com on 2012-03-25 03:12:10 EDT ---
I tried with kernel 3.2.9-2.fc16.i686.PAE with another DVB USB stick Artec T14BR DVB-T (driver dvb_usb_dib0700). Kaffeine gives error No device found.
When I look at Televison -> Configure Television, it now shows two devices: the old AF9013 and the new Artec T14BR, so the configuration found that device, but playing a channel does not find it!
--- Additional comment from firstname.lastname@example.org on 2012-03-25 06:57:43 EDT ---
I tested the following commands with both kernels 3.2.9-2.fc16.i686.PAE and 3.3.0-4.fc16.i686.PAE:
scandvb /usr/share/dvb/dvb-t/fi-Espoo > .xine/channels.conf
Both commands worked fine with both kernels!
But Kaffeine complains "No device found" with both kernels.
So I guess it is not a kernel problem? Kaffeine worked fine yesterday, but when I upgraded to latest packages (including KDE 4.8.1) it stopped working. The last time I upgraded this system was two weeks ago, so I guess one of the over 200 packages whose upgrade was pushed public during last two weeks breaks Kaffeine.
--- Additional comment from email@example.com on 2012-03-25 14:05:25 EDT ---
That's exactly the problem, there are more than 200 packages in your update, from many different update groups. I don't see how the KDE SC one can possibly cause this, it must be something else.
Can you please attach the list of packages which were updated (the lines of yum.log dated the day of your update)?
--- Additional comment from firstname.lastname@example.org on 2012-03-25 14:18:17 EDT ---
Created attachment 572559 [details]
List of updated packages
The machine is question is not physically here now, so I can't provide the yum.log right now. But because I save the output of "yum update" before the y/N prompt to a file so that I can use yumdownloader to save the packages to a USB memory for re-use in other computers, I can provide that list to you. I hope this helps you.
--- Additional comment from email@example.com on 2012-03-25 16:46:43 EDT ---
I have a similar problem with kaffeine and an AF9013 DVB-T device which worked fine until today. Kaffeine now tells me "No device found". I am using FC16 with
The updates I installed after the last time using kaffeine for dvb-t without any errors are listed below. As you can see there is no
kernel update included. However, if I boot kernel-3.2.10-3.fc16.x86_64
instead of 3.3.0-4 kaffeine works fine again and I can watch tv.
Mar 24 11:44:31 Updated: audit-libs-2.2-1.fc16.x86_64
Mar 24 11:44:33 Updated: 2:libpng-1.2.48-1.fc16.x86_64
Mar 24 11:44:33 Updated: libjpeg-turbo-1.2.0-1.fc16.x86_64
Mar 24 11:44:35 Updated: 1:cups-libs-1.5.2-6.fc16.x86_64
Mar 24 11:45:09 Updated: selinux-policy-3.10.0-80.fc16.noarch
Mar 24 11:47:23 Updated: selinux-policy-targeted-3.10.0-80.fc16.noarch
Mar 24 11:47:30 Updated: 1:cups-1.5.2-6.fc16.x86_64
Mar 24 11:47:31 Updated: audit-2.2-1.fc16.x86_64
Mar 24 11:47:32 Updated: audit-libs-python-2.2-1.fc16.x86_64
Mar 24 11:47:35 Updated: iproute-2.6.39-5.fc16.x86_64
Mar 24 11:47:37 Updated: lohit-punjabi-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:38 Updated: dash-0.5.7-1.fc16.x86_64
Mar 24 11:47:40 Updated: libquvi-scripts-0.4.3-1.fc16.noarch
Mar 24 11:47:41 Updated: quvi-0.4.2-1.fc16.x86_64
Mar 24 11:47:44 Updated: lohit-kannada-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:45 Updated: foomatic-filters-4.0.8-8.fc16.x86_64
Mar 24 11:47:47 Updated: lohit-assamese-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:49 Updated: lohit-telugu-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:51 Updated: lohit-bengali-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:53 Updated: lohit-oriya-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:55 Updated: lohit-gujarati-fonts-2.5.1-1.fc16.noarch
Mar 24 11:47:56 Updated: audit-libs-2.2-1.fc16.i686
Mar 24 11:47:57 Updated: 2:libpng-1.2.48-1.fc16.i686
Mar 24 11:47:57 Updated: libjpeg-turbo-1.2.0-1.fc16.i686
Mar 24 11:47:58 Updated: 1:cups-libs-1.5.2-6.fc16.i686
--- Additional comment from firstname.lastname@example.org on 2012-03-25 16:55:38 EDT ---
Hmmm, selinux-policy… Do you get any AVCs? Can you try with SELinux permissive (su -c "setenforce 0") or disabled?
--- Additional comment from email@example.com on 2012-03-25 18:21:46 EDT ---
No,I do not get any AVCs. Also setting SELinux to permissive or disabling it does not have any effect.
--- Additional comment from firstname.lastname@example.org on 2012-03-25 19:52:47 EDT ---
Sorry, I made a mistake about the last time I watched TV with kaffeine. This was on March 20, so there are some more updates to be considered. In particular, the new kernel 3.3.0-4 is one of them. The additional updates are
Mar 21 23:00:19 Updated: gd-2.0.35-14.fc16.x86_64
Mar 21 23:00:21 Updated: 1:grub2-1.99-13.fc16.2.x86_64
Mar 21 23:00:25 Updated: GraphicsMagick-1.3.14-1.fc16.x86_64
Mar 21 23:00:26 Updated: gd-2.0.35-14.fc16.i686
Mar 23 00:48:53 Updated: libgcc-4.6.3-2.fc16.x86_64
Mar 23 00:48:55 Updated: bash-4.2.24-1.fc16.x86_64
Mar 23 00:48:55 Updated: xorg-x11-server-common-1.11.4-2.fc16.x86_64
Mar 23 00:48:56 Updated: libquadmath-4.6.3-2.fc16.x86_64
Mar 23 00:48:57 Updated: libstdc++-4.6.3-2.fc16.x86_64
Mar 23 00:48:59 Updated: libuser-0.57.4-1.fc16.x86_64
Mar 23 00:49:00 Updated: libuser-python-0.57.4-1.fc16.x86_64
Mar 23 00:49:01 Updated: exempi-2.2.0-1.fc16.x86_64
Mar 23 00:49:02 Updated: libgfortran-4.6.3-2.fc16.x86_64
Mar 23 00:49:03 Updated: xorg-x11-server-Xephyr-1.11.4-2.fc16.x86_64
Mar 23 00:49:05 Updated: xorg-x11-server-Xorg-1.11.4-2.fc16.x86_64
Mar 23 00:49:06 Updated: kernel-tools-3.3.0-4.fc16.x86_64
Mar 23 00:49:14 Updated: libgcj-4.6.3-2.fc16.x86_64
Mar 23 00:49:45 Updated: google-chrome-stable-17.0.963.83-127885.x86_64
Mar 23 00:49:45 Updated: libgomp-4.6.3-2.fc16.x86_64
Mar 23 00:49:46 Updated: libtool-ltdl-2.4-9.fc16.x86_64
Mar 23 00:49:47 Updated: chkconfig-1.3.59-1.fc16.x86_64
Mar 23 00:49:48 Updated: psmisc-22.16-1.fc16.x86_64
Mar 23 00:49:49 Updated: libgcc-4.6.3-2.fc16.i686
Mar 23 00:49:50 Updated: libstdc++-4.6.3-2.fc16.i686
Mar 23 00:49:51 Updated: libquadmath-4.6.3-2.fc16.i686
Mar 23 00:49:52 Updated: libtool-ltdl-2.4-9.fc16.i686
Mar 23 00:50:03 Installed: kernel-3.3.0-4.fc16.x86_64
--- Additional comment from email@example.com on 2012-03-25 20:08:45 EDT ---
Might there be 2 separate bugs? Marco Kuehnel's evidence all points to the kernel as the culprit, but Juhani Jaakola seems to be hitting a different issue (possibly in addition to the kernel bug), maybe in FFmpeg?
In any case, I'm reassigning this to the kernel based on comment #3 and followups.
--- Additional comment from firstname.lastname@example.org on 2012-03-26 01:17:44 EDT ---
In comment #3 Michael Young writes that he can't watch DVB-T with Xine with kernel-3.3.0-4.fc16.x86_64
However, as I wrote in comment #10, I can watch DVB-T with Xine without problems with kernel 3.3.0-4.fc16.i686.PAE (and 3.2.9-2.fc16.i686.PAE as well). So xine and scandvb work for me with both kernels. I have 32-bit kernel and Michael has 64-bit kernel - are there other differences, such as weak signal? I have a strong signal.
Also the old program Klear 0.7.1 from fc10 can record programs with kernel 3.3.0-4.fc16.i686.PAE.
And as I wrote in comment #9, Kaffeine detects new DVB-T USB sticks for its configuration, but can not play any programs (gives error No device found). This happens with two different USB DVB-T sticks, with two different drivers (af9013 and dvb_usb_dib0700).
Kaffeine can play programs (.m2t files) which were recorded with Kaffeine when it worked.
I do not have kernel-3.2.10-3 installed now, so I have not tested it.
It's hard for me to think that the problem is in the kernel, because Kaffeine worked with kernel 3.2.9-2.fc16.i686.PAE before the updates but does not work after the updates. If the problem really is in the kernel, there would have to be two changes: one change in 3.2.10-3 which is compatible with the other new updates and another change in 3.3.0-4 which breaks it???
--- Additional comment from email@example.com on 2012-03-26 11:16:45 EDT ---
Looks like there are definitely 2 different bugs.
Marco Kuehnel, please file a separate bug against the kernel.
--- Additional comment from firstname.lastname@example.org on 2012-03-26 17:28:20 EDT ---
I filed the kernel related bug as Bug 807052.
--- Additional comment from email@example.com on 2012-03-27 09:09:00 EDT ---
I have another laptop which has kernel-3.3.0-4.fc16.i686 and Terratec CinergyT2 DVB-T USB stick (driver cinergyT2). On that machine Kaffeine does not give the "No device found" error! Currently I do not have a proper antenna, the signal is too weak to display anything. But Kaffeine behaves correctly without any errors if I try to watch a channel or try to scan channels.
On that machine I have updated only the rpm* packages and kernel 3.3.0-4 lately, so it still has these versions:
Command "yum update" lists 31 packages to be installed and 220 packages to be updated, such as ffmpeg-libs-0.8.10-1.fc16. Do you want a list of those packages? Do you want me to try to update only one or some of them?
--- Additional comment from firstname.lastname@example.org on 2012-03-27 10:50:38 EDT ---
Well, yes, if you could narrow down the package(s) causing the problem, that'd help a lot. ffmpeg would be one possible suspect.
--- Additional comment from email@example.com on 2012-03-27 12:01:59 EDT ---
I have a third laptop as well. I performed the same test as in comment #21 for it as well and I got the same results. After that I updated to ffmpeg-libs-0.8.10-1.fc16 and Kaffeine works with CinergyT2 with it as well. So if CinergyT2 suffers from this problem at all, ffmpeg-libs is not the cause.
Do you have any other suggestions for packages to update? Perhaps kdelibs, because Kaffeine uses libkio?
--- Additional comment from firstname.lastname@example.org on 2012-03-28 05:50:34 EDT ---
I updated packages kdelibs and kdelibs-common from 4.7.4-1.fc16.i686 to 4.8.1-2.fc16.i686 on the third laptop and tested with CinergyT2. It still works without any error messages. I'm using kernel-3.3.0-4.fc16.i686. Other parts of KDE are still at level 4.7.4 except kdelibs and kdelibs-common.
Any suggestions which package I should try next?
I guess we now have two possibilities:
- The bug affects only USB DVB-T sticks with drivers af9013 and dvb_usb_dib0700, but not CinergyT2. Unfortunately I do not have other sticks than the CinergyT2 now with me, so I can't compare. OR
- The bug is caused by one of the about 200 packages which I have not yet updated on the second and third laptops. I'll continue updating packages one by one.
--- Additional comment from email@example.com on 2012-03-28 07:42:21 EDT ---
There was a large re-work on Kernel 3.3, fixing the DVB API support. Part of the issues can be due to that.
In thesis, they shouldn't be visible to users, but regressions might happen.
Also, there is a special case that can be visible by some:
There are a few devices whose the same frontend can work with more than one different video standard. Those frontends are supported by the drxk and cxd2820 frontend drivers. Both support DVB-T and DVB-C.
There was a hack on those two specific drivers inside the kernel to expose them as two separate devices, but this were causing troubles with some applications that were expecting them to be independent.
This hack were replaced by a proper support at Kernel v3.3. Applications using DVBv5 API (support added on kernel in 2008) shouldn't have any troubles, but, unfortunately, most applications are still using the legacy DVBv3 API.
With the new support, there's now just one DVB frontend on those devices, and a simple ioctl call is enough to switch it between DVB-T, DVB-T2 and DVB-C.
Applications need to either be ported to fully support the DVBv5 API, or at least, implement the device mode switch.
For applications using the legacy API, there's an userspace tool that allows changing the device mode. It is part of the v4l-utils development branch. Fedora
is using the stable branch. I'll open a BZ with regards to either upgrading it to the development branch or to port the DVB utils there to the stable branch.
AFAIKT, no CinergyT2 or dib0700 devices use those multi-standard frontends.
--- Additional comment from firstname.lastname@example.org on 2012-03-28 08:11:14 EDT ---
A quick fix for Kaffeine would be to do something like this:
in order to use a multi-standard FE. There is also an enum call that allows
detecting what video standards are supported. The code to get a list of the
standards supported by a given frontend should be done with this code:
struct dtv_properties props;
struct dtv_property dvb_prop;
dvb_prop.cmd = DTV_ENUM_DELSYS;
props.num = 1;
props.props = dvb_prop;
if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1)
The number of supported standards will be at:
And the standards, in DVBv5 format, will be at:
If you're willing to add such hack at the Kaffeine code, please remember that
SYS_ISDBT and SYS_CMMB should be handled on legacy code just like DVB-T, as the
Kernel drivers will auto-detect the parameters that are specific to those two
Several DVB applications don't rely on DTV_DELIVERY_SYSTEM call in order to set the frontend to the right DVB standard.
With the recent Fedora 16 upgrade to kernel 3.3, a regression happened, as two multi-frontend drivers got upgraded.
On those, a hack that were forcing them to announce two separate frontend "devices" for the same physical component got removed.
This affects users with multi-frontend devices based on drx-k and cxd2820.
The dvb-fe-tool utility allows users to manually select if they're using DVB-T, DVB-T2 or DVB-C.
While not all DVB tools are upgraded/fixed to work with the proper logic, an userspace tool is required to allow changing the DVB delivery system.
So, please either add the dvb-fe-tool patches on v4l-utils. Eventually, it may simply be easier to upgrade it to the 0.9 version.
I'm currently preparing an updated v4l-utils-0.8.7-1.fc16 package which will include the
v4l-utils-0.8.7-1.fc17 has been submitted as an update for Fedora 17.
v4l-utils-0.8.7-1.fc16 has been submitted as an update for Fedora 16.
I install it and (unfortunately) DVB-T still doesn't works. But it looks better, there are no errors anymore in terminal output of xine. :(
(In reply to comment #5)
> I install it and (unfortunately) DVB-T still doesn't works. But it looks
> better, there are no errors anymore in terminal output of xine. :(
I think that you actually need to run dvb-fe-tool and select a specific frontend, as (the current version of) xine does not know how to do that itself. And then after that run xine.
If you cannot figure out the cmdline options yourself Mauro should be able to help ...
(In reply to comment #5)
> I install it and (unfortunately) DVB-T still doesn't works. But it looks
> better, there are no errors anymore in terminal output of xine. :(
For xine, see this comment:
For whatever weird reason/bug, Xine expects to have a valid frequency read _before_ having the frontend locked.
Anyway, as this is a Kernel regression, I'm applying that patch upstream.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing v4l-utils-0.8.7-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
kernel-3.3.1-5.fc16 has been submitted as an update for Fedora 16.
kernel-3.3.1-5.fc17 has been submitted as an update for Fedora 17.
kernel-188.8.131.52-5.fc15 has been submitted as an update for Fedora 15.
With this kernel it works.
kernel-3.3.1-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
kernel-184.108.40.206-2.fc15 has been submitted as an update for Fedora 15.
kernel-3.3.1-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
v4l-utils-0.8.7-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
kernel-220.127.116.11-6.fc15 has been submitted as an update for Fedora 15.
v4l-utils-0.8.7-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
kernel-18.104.22.168-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.