HVR-4000 may be broken in kernel mods (again) ?
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 -- 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: >>> 75400:INVERSION_AUT
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 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_fd
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
Fwd: HVR-4000 may be broken in kernel mods (again) ?
-- Forwarded message -- From: jonathanjstev...@gmail.com Date: 12 November 2011 16:44 Subject: Re: HVR-4000 may be broken in kernel mods (again) ? To: Devin Heitmueller On 12 November 2011 15:08, Devin Heitmueller wrote: > 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. > That seems a bit harsh but I understand your point. Running a hypervisor is far from unusual. I half expected this sort of response (not my problem mate). But, considering it's Xen dom0, I'm surprised there is nothing I can do? > 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? Nova-T works perfectly in MythTV on Xen. I haven't tried it in Kaffeine - you could be entirely right here. Whichever - because it's apparent there is a Xen versus dvb issue. I guess what I'd fall back to, xen dom0 support is now a part of the mainline kernel - so it shouldn't conflict with with particular hardware support such as that for the HVR-4000. It's obvious it "can" work, but from what I'm hearing from you - no-one would own this. I don't mind putting the hours in to resolve this, I really don't, but I don't have sufficient knowledge to do this on my own. -- 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) ?
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
