+++ 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): kaffeine-1.2.2-1.fc16.i686 kdelibs-4.8.1-2.fc16.i686 kernel-PAE-3.2.9-2.fc16.i686 or kernel-PAE-3.3.0-4.fc16.i686 How reproducible: Always Steps to Reproduce: 1. Start Kaffeine 2. Try to watch DVB-T television 3. Actual results: Read error Expected results: TV shows. Additional info: I have an af9015 DVB-T tuner. .xsession-errors shows a lot of error messages. --- Additional comment from rdieter.edu on 2012-03-24 16:05:42 EDT --- rpm -q xine-lib xine-lib-extra-freeworld please. --- Additional comment from kevin.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 m.a.young.uk 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 kevin.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 juhani.jaakola on 2012-03-25 02:32:04 EDT --- (In reply to comment #1) > rpm -q xine-lib xine-lib-extra-freeworld > please. $ rpm -q xine-lib xine-lib-extra-freeworld xine-lib-1.1.20.1-1.fc16.i686 package xine-lib-extra-freeworld is not installed --- Additional comment from kevin.org on 2012-03-25 02:47:58 EDT --- It's "xine-lib-extras-freeworld" with an 's'! --- Additional comment from juhani.jaakola 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: Device 1 Name: Afatech AF9013 DVB-T Device not connected. Device 2 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 4.95.0.0 --- Additional comment from juhani.jaakola 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 xine-lib-extras-freeworld-1.1.20.1-1.fc16.i686 --- Additional comment from juhani.jaakola 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 juhani.jaakola 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 xine dvb://MTV3 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 kevin.org 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 juhani.jaakola 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 mkuehnel 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 kaffeine-1.2.2-1.fc16.x86_64 kernel-3.3.0-4.fc16.x86_64 xine-lib-1.1.20.1-1.fc16.x86_64 xine-lib-extras-freeworld-1.1.20.1-1.fc16.x86_64 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 kevin.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 mkuehnel 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 mkuehnel 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 kevin.org 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 juhani.jaakola 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 kevin.org 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 mkuehnel on 2012-03-26 17:28:20 EDT --- I filed the kernel related bug as Bug 807052. --- Additional comment from juhani.jaakola 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: kernel-3.3.0-4.fc16.i686 xine-lib-1.1.20.1-1.fc16.i686 xine-lib-extras-freeworld-1.1.20.1-1.fc16.i686 kaffeine-1.2.2-1.fc16.i686 kdelibs-4.7.4-1.fc16.i686 ffmpeg-libs-0.8.9-1.fc16.i686 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 kevin.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 juhani.jaakola 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 juhani.jaakola 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 mchehab 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 mchehab on 2012-03-28 08:11:14 EDT --- @Kaffeine maintainers: A quick fix for Kaffeine would be to do something like this: http://linuxtv.org/hg/dvb-apps/rev/0c9932885287 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[1]; dvb_prop[0].cmd = DTV_ENUM_DELSYS; props.num = 1; props.props = dvb_prop; if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) return -1; The number of supported standards will be at: dvb_prop[0].u.buffer.len And the standards, in DVBv5 format, will be at: parms->dvb_prop[0].u.buffer.data[i] 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 terrestrial standards. Regards, Mauro
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 dvb-fe-tool utility.
v4l-utils-0.8.7-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/v4l-utils-0.8.7-1.fc17
v4l-utils-0.8.7-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/v4l-utils-0.8.7-1.fc16
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. :(
Hi, (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 ... Regards, Hans
(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: https://bugzilla.redhat.com/show_bug.cgi?id=807052#c13 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.
Package v4l-utils-0.8.7-1.fc17: * 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: https://admin.fedoraproject.org/updates/FEDORA-2012-5595/v4l-utils-0.8.7-1.fc17 then log in and leave karma (feedback).
kernel-3.3.1-5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kernel-3.3.1-5.fc16
kernel-3.3.1-5.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kernel-3.3.1-5.fc17
kernel-2.6.43.1-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.43.1-5.fc15
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-2.6.43.2-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.43.2-2.fc15
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-2.6.43.2-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.43.2-6.fc15
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-2.6.43.2-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.