Re: HVR-4000 may be broken in kernel mods (again) ?
I'd be much obliged if someone could give me some interpretation on the following? If I read it right, this means that the tuner tunes OK, and then the filter loads OK (no error message on the filter load), but no data is being returned? If so, could this be a DMA problem? Would anyone know a way to look closer at that? This is from the a working USB DVB: Take from a strace -ttt -f -F -v scandvb -a 1 -f1 -d 0 -5 -v -v -v -5 ~/dvbscan.channels.conf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
Sorry - hit the wrong button and sent too early... please ignore that last email. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
On 11/12/11 09:53, jonathanjstev...@gmail.com wrote: I've just done some tests without Xen. The situation does change, in that scandvb finds the services (so no more filter timeouts). Kaffeine also manages to scan the channels OK - however despite managing to scan, tune and get the EPG there is no picture on any channel. I can't test MythTV without Xen, as it relies on an SQL database that is on a Xen VM. Not sure where to go with this next? The card worked Ok through Xen (am running all this in dom0 by the way) with Opensuse (once patches applied) and the version of Xen is not very different - although the dom0 kernel will be I guess. Try mplayer (or VLC) directly. Kaffeine uses a pipe from mplayer. I use VLC to open my channels.conf (I forget which file format, mplayer format?) which works. Mplayer doesn't work very well on my system but vlc does. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
Thanks all for your feedback. I've been investigating the Xen angle as well and there seem to be quite a few reports of DVB cards not working in Xen at the moment. The culprit appears to be something to do with DMA, although whether it's Xen or the drivers remains to be seen . From what I can tell, the card tunes OK but then when the driver tries to access the datastream (via DMA) things go bad. If anyone knows of a good way to look deeper into this area - please let me know! Anyway, I'm going to go and hassle the Xen developers to see if they can shed some more light on this. I'll also have a play with vlc. Try mplayer (or VLC) directly. Kaffeine uses a pipe from mplayer. I use VLC to open my channels.conf (I forget which file format, mplayer format?) which works. Mplayer doesn't work very well on my system but vlc does. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
On Sat, Nov 12, 2011 at 5:33 AM, jonathanjstev...@gmail.com jonathanjstev...@gmail.com wrote: Description of problem: Support for Hauupauge HVR-4000 appears to be broken (again) in kernel mods. This is a bit of a tale of woe, but this hardware is supposed to have been sorted in stock kernel roundabout 3.0. Stock F16 kernel cannot scan or tune in mythtv, kaffeine, w_scan, or dvbscan. Compiled/Installed latest video-media build still no joy. I used another USB DVB (nova-t) to scan, and using the results obtained from w_scan on this managed to get tzap to FE LOCK. However this only worked with tzap - no other app can get a lock. Have tested with i2c reset patch enabled and not, and also with strobing patch enabled and not (cs88-dvb.c). Also with mythtv kludge (delaying on FE close in dvbutils.cpp). All make no difference. So sad :( Version-Release number of selected component (if applicable): Linux mythtvtuner.home 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Install F16 and try to make use of HVR-4000. Steps to Reproduce: 1. Install F16 on a machine with HVR-4000 2. Try to use it 3. Cry Actual results: Can't scan or tune. Expected results: Can scan and tune and be happy. Additional info: Should mention this machine is also running Xen. If necessary I have a spare machine I can put a HVR-4000 into and can compile whatever you want to try to fix this. Pretty sure this is a problem upstream in video-media, but will report here to try and get some help! Willing to put in the hours this side to get to the bottom of this, sorry I don't have the programming skills to attack it myself. All the problems historically that the HVR-4000 has had in v4l were supposed to be fixed in 3.0... Let me know what additional info you might want? Jonathan Hi Jonathan, It was actually broken for months (including 3.0), and not fixed until 3.1. I'm assuming you're having problems with dvb-s and dvb-t? Please clarify exactly which standards aren't working for you? Also, take Xen out of the picture. Validate it isn't working in a regular system. Virtualization is definitely a source of problems and should be ruled out. Any suspicious output in dmesg? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
i also have hvr-4000 but havent tried it on recent kernels yet. i get no lock problems only with dvb-s2 but that is a hardware limitation, that it is not able to get right parameters. i dont know if they did something with it. would be about time however. i am alos curious what he means by try to use it. i mean did he try to use it with tzap, or szap, or w_scan, or what? because i dont even know about mythtv, i only use dvbutils, mplayer, xine and vdr. On Sat, 12 Nov 2011 07:55:37 -0500 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, Nov 12, 2011 at 5:33 AM, jonathanjstev...@gmail.com jonathanjstev...@gmail.com wrote: Description of problem: Support for Hauupauge HVR-4000 appears to be broken (again) in kernel mods. This is a bit of a tale of woe, but this hardware is supposed to have been sorted in stock kernel roundabout 3.0. Stock F16 kernel cannot scan or tune in mythtv, kaffeine, w_scan, or dvbscan. Compiled/Installed latest video-media build still no joy. I used another USB DVB (nova-t) to scan, and using the results obtained from w_scan on this managed to get tzap to FE LOCK. However this only worked with tzap - no other app can get a lock. Have tested with i2c reset patch enabled and not, and also with strobing patch enabled and not (cs88-dvb.c). Also with mythtv kludge (delaying on FE close in dvbutils.cpp). All make no difference. So sad :( Version-Release number of selected component (if applicable): Linux mythtvtuner.home 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Install F16 and try to make use of HVR-4000. Steps to Reproduce: 1. Install F16 on a machine with HVR-4000 2. Try to use it 3. Cry Actual results: Can't scan or tune. Expected results: Can scan and tune and be happy. Additional info: Should mention this machine is also running Xen. If necessary I have a spare machine I can put a HVR-4000 into and can compile whatever you want to try to fix this. Pretty sure this is a problem upstream in video-media, but will report here to try and get some help! Willing to put in the hours this side to get to the bottom of this, sorry I don't have the programming skills to attack it myself. All the problems historically that the HVR-4000 has had in v4l were supposed to be fixed in 3.0... Let me know what additional info you might want? Jonathan Hi Jonathan, It was actually broken for months (including 3.0), and not fixed until 3.1. I'm assuming you're having problems with dvb-s and dvb-t? Please clarify exactly which standards aren't working for you? Also, take Xen out of the picture. Validate it isn't working in a regular system. Virtualization is definitely a source of problems and should be ruled out. Any suspicious output in dmesg? Devin -- Lars Schotte @ Hana (F16) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
On Sat, Nov 12, 2011 at 8:14 AM, Lars Schotte gu...@guttok.net wrote: i am alos curious what he means by try to use it. i mean did he try to use it with tzap, or szap, or w_scan, or what? because i dont even know about mythtv, i only use dvbutils, mplayer, xine and vdr. I agree with Lars on this. It would be useful if the user could describe in more detail his testing methodology. Also, is there some previous kernel in which he knew it was working properly? Has he *ever* seen it work in his environment? Do we know definitively that this really a regression or has the user never seen the board work? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
Devin Heitmueller dheitmueller at kernellabs.com writes: On Sat, Nov 12, 2011 at 8:14 AM, Lars Schotte gusto at guttok.net wrote: i am alos curious what he means by try to use it. i mean did he try to use it with tzap, or szap, or w_scan, or what? because i dont even know about mythtv, i only use dvbutils, mplayer, xine and vdr. I agree with Lars on this. It would be useful if the user could describe in more detail his testing methodology. Also, is there some previous kernel in which he knew it was working properly? Has he *ever* seen it work in his environment? Do we know definitively that this really a regression or has the user never seen the board work? Devin I think your problem and mine are the same I've too an hauppauge dvb-t http://www.spinics.net/lists/linux-media/msg39917.html Since upgrade from kernel 2.6.38 to 2.6.39/3.0 channels can't be lock. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
OK, sure... bit more history... I've struggled along with the card for many year. Was previously in a F12 x64, with the http://hg.kewl.org/pub/v4l-dvb-20100517/ DVB modules compiled in and everything worked except MythTV. Then with a few kludges to MythTV everything ended up working. The system is a under the stairs server so does a fair few things for me, quite a few VMs (hence Xen), mythtvbackend with a few tuners, file server, etc... Last year to get the Xen support I moved to OpenSuse 11.4, and again had to patch v4l modules and MythTV. So, I didn't really get on with OpenSuse at all, and was keen to get back to Fedora. F16 provides the upstream support for dom0 under Xen (I'm not one for compiling my own kernel - that's a bit out of my comfort zone). So been testing the F16 and all seemed fine, so went for the move. I also spotted http://www.kernellabs.com/blog/?p=1568 from which I figured that I'd probably be fairly safe wrt the HVR-4000 - should have tested it I suppose, but there we go... So, the system itself is all known to work with patched opensuse 11.4 and patched MythTV (which shouldn't be necessary now as per the above links) and Xen did not get in the way. Now, more details: First off, I have no satellite, so this is all about DVB-T (terrestrial UK/Freeview) MythTV could not scan the HVR-4000, but was fine with my Nova USB, fed from same wire. So, I tried scandvb (not sure why it's called scandvb instead of dvbscan in Fedora). Did not manage to find any services. So, I tried w_scan, and again was unable to discover any services. It looks a bit like it finds the transponders (sometimes) but mutters about timeout loading filters. I then used the Nova to scan for channels with w_scan, which worked, and I used the resulting output to successfully get FE_LOCK with tzap on the HVR-4000. However, using the transponder information from w_scan with scandvb did not find any services. I thought therefore it might just be a tuning issue, so used the tuning info from the Nova in MythTV for the HVR-4000. MythTV reports Partial Lock. dmesg does not report any errors that I can see. I'm happy to post up a pile of diags, but don't want to bombard the list with stuff you're not interested in - so if you tell me what you'd like me to run/test I'll happily do that. I will verify Xen is not causing this in the meantime. Here is a very verbose scandvb... [root@mythtvtuner jon]# scandvb -a 0 -f 1 -d 1 -v -v -v -v -5 -n -x 0 dvbscan.channels.conf scanning dvbscan.channels.conf using '/dev/dvb/adapter0/frontend1' and '/dev/dvb/adapter0/demux1' initial transponder 65000 0 9 9 6 2 4 4 initial transponder 75400 0 3 9 3 1 0 0 initial transponder 79400 0 2 9 3 1 0 0 initial transponder 73800 0 2 9 3 1 0 0 initial transponder 69000 0 2 9 3 1 0 0 initial transponder 72200 0 2 9 3 1 0 0 initial transponder 70600 0 9 9 6 2 4 4 initial transponder 84200 0 9 9 6 2 4 4 tune to: 65000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO tuning status == 0x01 tuning status == 0x1f add_filter:1377: add filter pid 0x start_filter:1317: start filter pid 0x table_id 0x00 update_poll_fds:1297: poll fd 4 add_filter:1377: add filter pid 0x0011 start_filter:1317: start filter pid 0x0011 table_id 0x42 update_poll_fds:1297: poll fd 5 update_poll_fds:1297: poll fd 4 add_filter:1377: add filter pid 0x0010 start_filter:1317: start filter pid 0x0010 table_id 0x40 update_poll_fds:1297: poll fd 6 update_poll_fds:1297: poll fd 5 update_poll_fds:1297: poll fd 4 add_filter:1377: add filter pid 0x0010 start_filter:1317: start filter pid 0x0010 table_id 0x41 update_poll_fds:1297: poll fd 7 update_poll_fds:1297: poll fd 6 update_poll_fds:1297: poll fd 5 update_poll_fds:1297: poll fd 4 WARNING: filter timeout pid 0x0011 remove_filter:1385: remove filter pid 0x0011 stop_filter:1363: stop filter pid 0x0011 update_poll_fds:1297: poll fd 7 update_poll_fds:1297: poll fd 6 update_poll_fds:1297: poll fd 4 WARNING: filter timeout pid 0x remove_filter:1385: remove filter pid 0x stop_filter:1363: stop filter pid 0x update_poll_fds:1297: poll fd 7 update_poll_fds:1297: poll fd 6 WARNING: filter timeout pid 0x0010 remove_filter:1385: remove filter pid 0x0010 stop_filter:1363: stop filter pid 0x0010 update_poll_fds:1297: poll fd 6 WARNING: filter timeout pid 0x0010 remove_filter:1385: remove filter pid 0x0010 stop_filter:1363: stop filter pid 0x0010 tune to: 75400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 WARNING: tuning failed!!! tune to:
Re: HVR-4000 may be broken in kernel mods (again) ?
I've just done some tests without Xen. The situation does change, in that scandvb finds the services (so no more filter timeouts). Kaffeine also manages to scan the channels OK - however despite managing to scan, tune and get the EPG there is no picture on any channel. I can't test MythTV without Xen, as it relies on an SQL database that is on a Xen VM. Not sure where to go with this next? The card worked Ok through Xen (am running all this in dom0 by the way) with Opensuse (once patches applied) and the version of Xen is not very different - although the dom0 kernel will be I guess. On 12 November 2011 14:16, jonathanjstev...@gmail.com jonathanjstev...@gmail.com wrote: OK, sure... bit more history... I've struggled along with the card for many year. Was previously in a F12 x64, with the http://hg.kewl.org/pub/v4l-dvb-20100517/ DVB modules compiled in and everything worked except MythTV. Then with a few kludges to MythTV everything ended up working. The system is a under the stairs server so does a fair few things for me, quite a few VMs (hence Xen), mythtvbackend with a few tuners, file server, etc... Last year to get the Xen support I moved to OpenSuse 11.4, and again had to patch v4l modules and MythTV. So, I didn't really get on with OpenSuse at all, and was keen to get back to Fedora. F16 provides the upstream support for dom0 under Xen (I'm not one for compiling my own kernel - that's a bit out of my comfort zone). So been testing the F16 and all seemed fine, so went for the move. I also spotted http://www.kernellabs.com/blog/?p=1568 from which I figured that I'd probably be fairly safe wrt the HVR-4000 - should have tested it I suppose, but there we go... So, the system itself is all known to work with patched opensuse 11.4 and patched MythTV (which shouldn't be necessary now as per the above links) and Xen did not get in the way. Now, more details: First off, I have no satellite, so this is all about DVB-T (terrestrial UK/Freeview) MythTV could not scan the HVR-4000, but was fine with my Nova USB, fed from same wire. So, I tried scandvb (not sure why it's called scandvb instead of dvbscan in Fedora). Did not manage to find any services. So, I tried w_scan, and again was unable to discover any services. It looks a bit like it finds the transponders (sometimes) but mutters about timeout loading filters. I then used the Nova to scan for channels with w_scan, which worked, and I used the resulting output to successfully get FE_LOCK with tzap on the HVR-4000. However, using the transponder information from w_scan with scandvb did not find any services. I thought therefore it might just be a tuning issue, so used the tuning info from the Nova in MythTV for the HVR-4000. MythTV reports Partial Lock. dmesg does not report any errors that I can see. I'm happy to post up a pile of diags, but don't want to bombard the list with stuff you're not interested in - so if you tell me what you'd like me to run/test I'll happily do that. I will verify Xen is not causing this in the meantime. Here is a very verbose scandvb... [root@mythtvtuner jon]# scandvb -a 0 -f 1 -d 1 -v -v -v -v -5 -n -x 0 dvbscan.channels.conf scanning dvbscan.channels.conf using '/dev/dvb/adapter0/frontend1' and '/dev/dvb/adapter0/demux1' initial transponder 65000 0 9 9 6 2 4 4 initial transponder 75400 0 3 9 3 1 0 0 initial transponder 79400 0 2 9 3 1 0 0 initial transponder 73800 0 2 9 3 1 0 0 initial transponder 69000 0 2 9 3 1 0 0 initial transponder 72200 0 2 9 3 1 0 0 initial transponder 70600 0 9 9 6 2 4 4 initial transponder 84200 0 9 9 6 2 4 4 tune to: 65000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO tuning status == 0x01 tuning status == 0x1f add_filter:1377: add filter pid 0x start_filter:1317: start filter pid 0x table_id 0x00 update_poll_fds:1297: poll fd 4 add_filter:1377: add filter pid 0x0011 start_filter:1317: start filter pid 0x0011 table_id 0x42 update_poll_fds:1297: poll fd 5 update_poll_fds:1297: poll fd 4 add_filter:1377: add filter pid 0x0010 start_filter:1317: start filter pid 0x0010 table_id 0x40 update_poll_fds:1297: poll fd 6 update_poll_fds:1297: poll fd 5 update_poll_fds:1297: poll fd 4 add_filter:1377: add filter pid 0x0010 start_filter:1317: start filter pid 0x0010 table_id 0x41 update_poll_fds:1297: poll fd 7 update_poll_fds:1297: poll fd 6 update_poll_fds:1297: poll fd 5 update_poll_fds:1297: poll fd 4 WARNING: filter timeout pid 0x0011 remove_filter:1385: remove filter pid 0x0011 stop_filter:1363: stop filter pid 0x0011 update_poll_fds:1297: poll fd 7 update_poll_fds:1297: poll fd 6 update_poll_fds:1297: poll fd 4 WARNING: filter timeout pid 0x remove_filter:1385: remove filter pid 0x stop_filter:1363: stop filter pid 0x update_poll_fds:1297: poll fd 7
Re: HVR-4000 may be broken in kernel mods (again) ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/12/2011 08:53 AM, jonathanjstev...@gmail.com wrote: I've just done some tests without Xen. The situation does change, in that scandvb finds the services (so no more filter timeouts). Kaffeine also manages to scan the channels OK - however despite managing to scan, tune and get the EPG there is no picture on any channel. I can't test MythTV without Xen, as it relies on an SQL database that is on a Xen VM. Not sure where to go with this next? The card worked Ok through Xen (am running all this in dom0 by the way) with Opensuse (once patches applied) and the version of Xen is not very different - although the dom0 kernel will be I guess. Hi Jonathon, I would make two suggestions to you. 1. Check on the Mythtv forums (and post the question there), if you haven't already. They may have a bit more insight into the card with their system. And they may be able to sort out the lack of picture (even though it's not on their software). 2. If you can allocate a lower percentage of processor and/or memory to the Xen VM, that may solve part of the problem. My theory is that Xen is using too much of the CPU and/or memory right now, and everything else has to fight for what's left. Which means that when you try using the card, it's basically getting scraps. So it times out and can't scan. That's why it works (better at least) when Xen is off. If you can't allocate lower percentages, then maybe trying Virtualbox or VMWare would work. But, I would see what all you can do with Xen first. Have a great weekend. :) Patrick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6+i3AACgkQMp6rvjb3CASrAACfW67fWDTETYRu6kQg/rRnxM14 53AAn3C3MMkFZaKcdGn+IUE9EGuuwBkn =p/K3 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
If you're running Xen, then as far as I'm concerned you're on a *totally* unsupported path. If it happened to have worked in some previous version, it was dumb luck. As for you issue when not using Xen, you're probably just missing the Kaffeine libraries required for video playback (a common problem). Did you try the Nova-T on that box to confirm playback works at all? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
Hi Jonathon, I would make two suggestions to you. 1. Check on the Mythtv forums (and post the question there), if you haven't already. They may have a bit more insight into the card with their system. And they may be able to sort out the lack of picture (even though it's not on their software). HVR-4000 quite a tale of woe with MythTV, see earlier posts. Been patching for years, but I don't think this is a MythTV issue, not something they can do much about. 2. If you can allocate a lower percentage of processor and/or memory to the Xen VM, that may solve part of the problem. My theory is that Xen is using too much of the CPU and/or memory right now, and everything else has to fight for what's left. Which means that when you try using the card, it's basically getting scraps. So it times out and can't scan. That's why it works (better at least) when Xen is off. If you can't allocate lower percentages, then maybe trying Virtualbox or VMWare would work. But, I would see what all you can do with Xen first. Not really following you here. I'm running all this in dom0. There is 16GB of memory in the system, and it's an i3, and nothing else is really running. I've allocated 4GB to dom0, and even with all the other VMs running, CPU usage is low and there's about 7GB free. I'm not doing any kind of PCI passthru, and in fact the main reason I'm running Xen is that it allows me to run mythtv in dom0 and get direct access to the PCI DVB cards. Have a great weekend. :) Patrick. You too and thanks for helping out. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
