If you’re running MythTV with an HVR2200 in Australia then I need to hear from you!
I spent six hours over the weekend logged in remotely to an Australian users system trying to track down a problem that was seemingly preventing the driver from responding correctly after being loaded. Requests into the firmware were being ignored for an apparently unknown reason. dmesg was showing massive numbers of I2C errors and general timeout warnings.
Well, after installing many different debug builds, tracing the driver manually, adding extra levels of debug, forcing certain things to happen …. nothing would work. Yes, nothing. A real head scratcher.
Yet, an almost identical board worked with tzap correctly in our development systems.
As a hunch I happened to notice that MythTV was set to automatically start. I disabled this, rebooted and tzap, dvbtraffic and everything else was working perfectly. At first glance it looks like this users MythTV configuration is breaking the driver, I need more investigation on this. I’ll do this and report back.
Why this post then? I’d also like to open up this post for comments by people who are using MythTV specifically with the HVR2200. Please describe either your successful or unsuccessful experiences. ‘Works for me’ is fine as a comment if you’re not in a writing mood.
As always, your feedback is appreciated.
works for me :^)
I’m using fedora 11, stock standard kernel / mythtv rpms
had the card for about 3 days, worked soon as I compiled up your v4l-dvb version.
Feel free to contact me for more specific details.
Adam from Perth wrote to me privately and said”
“I am using mythbuntu 9.04 with this card, and with so far limited use, it has
been fine. I am waiting on the driver to be released to the distro’s before
the machine goes into daily use. The mythtv build is from J Avenard’s PPA:
http://www.avenard.org/media/Home.html which has the VDPAU patched in.
Mythtv runs automatically.”
Great!
Thank you Adam.
Steven,
main frontend /Mythtv 23 / 10.10 Kubuntu 64-bit / X58 Gigabyte mobo / i7 / 4gb ram / Hr2200
backend / Athlon Mythtv 23 / 10.10 Kubuntu 64-bit / old crappy mobo 4gb ram / Divico fusion PCI / Compro USB U300 stick.
Perth Western Australia Northern Suburbs.
System has been running on and off ok for 18 months or so, 10.10 upgrade about December.
Tried originally running the E900 Compro but no Linux drivers so ditched it for HR2200.
Same as everyone else, unable to tune ch 9 here in Mythtv, gets all other channels.
Be nice if someone(Steven?) came up with driver for E900 as chipset seems to be the same as HR2200.
I’m fairly new to Linux but now almoooost 100% weaned of the Windows7, just need it for my swimming pool controller interface (bluetooth).
I’m an ex tv tech (no bugger repairs anything these days) so can handle the technical stuff if I can help.
Tony Brown (vidtek)
@Damien, thanks.
Thanks for raising this issue steve. Hopefully somebody an shed some light on the issue!
I did want to note, I ran mythtv-setup after boot (driver correctly loaded), and was able to scan in only 3 of 6 multiplexes. Of course once I exited and the backend started, the I2C errors returned.
Don’t know whether this provides any more insight into the situation.
Regards,
Nasha
I am from Australia and I am currently using 2 HVR-2200s in my MythTV box and it has been working for 24 hours non stop so far.
I am using Ubuntu 9.04 and MythTV 0.21. I just followed the steps in the wiki guide and it was pretty much up and running in no time.
I’ve setup this card for a friend and he is having issues getting channels. In Darwin, we can scan and find channel 7, ABC and SBS. Of those 3, ABC won’t get a signal lock. The scan is also not detecting channel 9 and Channel 10. I’ve tested this with 2 separate locations with known good antenna rigs. I’ve also run the scan in both DVB apps and MythTV with the same result. I can only conclude it is an issue with the driver somewhere
@Paul, other users are having success in Australia so it has to be something specific in your case. Most likely a user, signal or RF issue. The only driver bugs we’ve seen were some full system hangs or some i2c reported errors in syslog (which could cause a miss-tune) leading to a zero length recording in mythtv.
The install is a unmodified Mythbuntu 9.04 install with the only change being the installation as per the wiki instructions? It’s odd that the card is ‘kind of’ working. I personally own a Hauppage Nova 500 T PCI, and that driver had issues in Australia for quite some time for intermittent people. Of course, I happened to be one of them and there is prior evidence of Australian users working or not working depending on their geographic location. Unfortunately, I think to summarize if it works for some Australians means it works for all is not the case. To fix my issue, It required an additional option added;
options dib3000mc buggy_sfn_workaround=1
See this link at the MythTV Wiki for more info. (There is a note to Australian users right at the bottom.)
http://www.mythtv.org/wiki/Hauppauge_WinTV_Nova-T_500_PCI
Given the card is working to some degree, I suspect the issue I am getting with the HVR 2200 might be similar a similar root cause to the problem I experienced with the Nova T.
I’ve read parts of the mailing list (linked from the wiki article above) which is related to my previous issue with the Nova T, and there are some statements that may offer some more information;
———
“Australian broadcasters use a 7mHz bandwidth (most of the world use 8mHz)”
———
“For those interested the issue actually had nothing to do with Hauppauge,
but rather was a chipset issue which we have identified in other tuner and
set-top products. Because the issue is unique to only small parts of
Australia, many users and manufacturers write the symptoms off as a
reception problem. Once a final firmware/driver update is released, anyone
interested in the technical details can contact me for more info.”
@Paul, thanks for the detailed reply.
While I can’t say “No, the sfn issue isn’t the cause of the problem”, I’d have no evidence to back this up other than to say that Hauppauge don’t have this issue under Windows (and didn’t have to build anything specific in their drivers for this), likewise, the linux tda10048 and tda18271 drivers are in great shape and I would not expect them to have this issue either.
Real proof would be to either run the HVR2200 under windows in exactly the same environment, or to find a similar TDA10048 / TDA18271 based board to compare against under Linux. In this way at least various parts of the equation could be isolated and ruled out with testing.
More likely it could be a generic 7Mhz vs 8Mhz tuning issue and could show itself more obviously if the adjacent channels next to the failing DVB-T channels are populated. IE, the app is issuing a 8Mhz tune request in 7Mhz RF space and the adjacent channel is causing locking issues for the RF frontend.
@Paul, thanks for the detailed reply.
While I can’t say “No, the sfn issue isn’t the cause of the problem”, I’d have no evidence to back this up other than to say that Hauppauge don’t have this issue under Windows (and didn’t have to build anything specific in their drivers for this), likewise, the linux tda10048 and tda18271 drivers are in great shape and I would not expect them to have this issue either.
Real proof would be to either run the HVR2200 under windows in exactly the same environment, or to find a similar TDA10048 / TDA18271 based board to compare against under Linux. In this way at least various parts of the equation could be isolated and ruled out with testing.
More likely it could be a generic 7Mhz vs 8Mhz tuning issue and could show itself more obviously if the adjacent channels next to the failing DVB-T channels are populated. IE, the app is issuing a 8Mhz tune request in 7Mhz RF space and the adjacent channel is causing locking issues for the RF frontend.
I believe that many of the signal detection problems particularly in Australia? (apart from being 7Mhz) are due to the 2200/ 2250 needing to tune to the exact frequency offset.
http://www.quantexzone.com/faq/wintv_faq/wintv_kb_enable_auto_offset.htm#Philips_PCI_and_PCIe_Devices
I’m not sure what I’d need to do to test your theory Steve?
I have noticed my friends system logs are rapidly filling up with I2C errors. Was there a bug with the driver regarding this, or was there a work around?
@Paul, i2c messages were cleaned up a couple of weeks ago. Everyone should be running saa7164-stable (http://www.kernellabs.com/hg/saa7164-stable/) at this point. Your friends should try this and report back.
If you have tuning issues you should also try the current dev tree at http://www.kernellabs.com/hg/~stoth/saa7164-dev/, which contains some tuner optimizations and calibration fixes.
Once you have the dev tree installed I’d expect tzap and dvbtraffic to work correctly.
I can confirm that only TEN is tuning in Goulburn, NSW using the stable drivers. I have had similar problems with a Dvico HDTV dual digital express where it would not tune some channels in this area.
@Alex, have you tried using tzap and the command line Linux tools to debug the issue? If you have issues with another unrelated product then it’s probably environment, mythtv or something. Regardless, tzap would help you diagnose tuning and signal level issues.
I currently have 2x Dvico Dual Digital 4 (PCI) cards in my MythTV backend. They are working perfectly. When I connect this card to that same antenna, I can only scan one transport.
I have tried using tzap, but I get similar results. The transport that I can lock on with MythTV is the only transport I can get a lock with any channel. Incidentally, that one transport has perfect picture quality.
I’m not quite sure where to go from here.
Quick update. I have taken the same computer to Canberra and it tuned all transports except for ABC. I have been told that the antenna I hooked up to had issues with ABC, so I wasn’t too surprised.
@Alex, So, not a driver bug, and environmental specific issue or bug?
Ok, I’ve kept trying on my mates server… (cause he’s a whiney nagging little girls blouse and wont leave me alone till I get it working!)
He’s recently moved house, and had a new antenna installed at the new location. I’ve tried all three branches, stable, dev, and merge. All return the same results as reported earlier except the i2c errors have now disappeared. So testing to date has returned the following,….3 houses, all known good antenna rigs, 2 installations of Linux, 3 different compiles of driver branch,…and still the issue persists.
It’s either the card, or something funky with the card and Darwin. My last test will be to install a Windows rig and driver to at least prove the card isn’t faulty and it works in Darwin.
Steven, do you have any advice in what else I can do to debug? I’m not that literate in tzap so I’m not sure what I need to do here.
@Paul, My only advise would be to try and debug the issue using tzap and modify the channels.conf, varying the frequency to see if it really is a tuning issues. This is what I had to do in NZ for another user, and found no problems.
HVR-2200 Ubuntu 9.04 using latest stable saa7164. Picks up all channels except for SBS and channel 9. If I plug the antenna diriectly into the TV it picks them up?
@John Cornelius, what town are you in and what frequencies should these channels be running on? If you create a channels.conf with those frequency and use tzap does this work? We’ve seen some odd frequency offset related issues in Australia and it usually turns out to be configuration or scanning related rather than a typical driver bug.
Steven thankyou for you prompt reply.
ubuntu 9.04 – 64 bit – 2.6.28-15- I used scan and au_Perth to create a channel.conf and it created more channels than mythtv picked up. However it did not pick up any SBS channels. The funny thing is that in another box running ubuntu 9.04 – 32 bit using the same card mythtv scanned all channels but scan and au_Perth did not pick up SBS either. I used tzap to check that the channel.conf channels locked OK. I now have all channels as I created another channel.conf file using a different model card. So all is working now except for the second card I brought at the same time which I explain in the next reply.
0x0000 0x0681: pmt_pid 0x0101 Ten Perth — ONE HD (running)
0x0000 0x0685: pmt_pid 0x0100 Ten Perth — TEN Digital (running)
0x0000 0x0687: pmt_pid 0x0106 Ten Perth — ONE HD (running)
0x0000 0x0688: pmt_pid 0x0107 Ten Perth — ONE Digital (running)
NIT (actual TS)
Network Name ‘Network TEN’
>>> tune to: 536500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8: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: 536500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE (tuning failed)
>>> 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!!!
dumping lists (19 services)
I purchased 2 cards on the internet and one of them the firmware will not load. No one else seems to have this problem. I have tried this card in both boxes and both result in
saa7164_downloadimage() image corrupt. What do you reckon is the card faulty?
Thanks for your help.
[ 12.450358] saa7164 driver loaded
[ 12.450390] saa7164 0000:09:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 12.450622] CORE saa7164[0]: subsystem: 0070:8980, board: Hauppauge WinTV-HVR2200 [card=4,autodetected]
[ 12.450628] saa7164[0]/0: found at 0000:09:00.0, rev: 129, irq: 18, latency: 0, mmio: 0xec000000
[ 12.450634] saa7164 0000:09:00.0: setting latency timer to 64
[ 12.608006] saa7164_downloadfirmware() no first image
[ 12.608015] saa7164_downloadfirmware() Waiting for firmware upload (v4l-saa7164-1.0.3.fw)
[ 12.608018] saa7164 0000:09:00.0: firmware: requesting v4l-saa7164-1.0.3.fw
[ 13.640094] saa7164_downloadfirmware() firmware read 3978608 bytes.
[ 13.640096] saa7164_downloadfirmware() firmware loaded.
[ 13.640101] saa7164_downloadfirmware() SecBootLoader.FileSize = 3978608
[ 13.640107] saa7164_downloadfirmware() FirmwareSize = 0x1fd6
[ 13.640108] saa7164_downloadfirmware() BSLSize = 0x0
[ 13.640109] saa7164_downloadfirmware() Reserved = 0x0
[ 13.640110] saa7164_downloadfirmware() Version = 0x51cc1
[ 17.488013] saa7164_downloadimage() image corrupt
I replied to the mailing list, but I might post here too. I have found that with the exception of channel TEN in Goulburn, all channels use adjacent channels. I could be looking at a interference issue with the analog channels if the driver is not using a 7Mhz channel separation.
@Alex Ferrara, that’s an interesting observation. Let me digest that and see.
@John Cornelius, cold boot and try again. I’ve seen the cards get sick and never recover without either a cold boot or being physically removed/re-inserted
@Alex Ferrara, remind me… Does the windows driver work with that card properly on ALL of your channels?
I’m not sure. I don’t have a Windows machine handy to try it out on. I will arrange one and post back.
I have already tried removing the card and installing it in another computer. Same problem the card is detected but the firmware doesn’t load.
Hi Steven
An update on my testing. Given the current config was failing to scan most channels in my area, I exported a known good channels.conf on my MythTV server and manually imported it into my friends. Remarkably, the results have turned out quite well. The card will tune pretty much all channels except any of the ABC channels. Here is the Channel.conf file;
ABC HDTV:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2314:0:640
ABC1:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:641
ABC2:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2307:2308:642
ABC1:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:643
ABC3:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:644
ABC DiG Radio:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:2317:646
ABC DiG Jazz:543625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:2318:647
SBS ONE:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:865
SBS TWO:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:162:83:866
SBS 3:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:867
SBS 4:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:868
SBS HD:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:102:103:869
SBS Radio 1:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:201:878
SBS Radio 2:536625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:202:879
Nine Darwin SD:550625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:512:650:1793
Nine Darwin HD:550625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:514:0:1794
SCTV Darwin:557625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:609:610:2305
SCTV HD – Darwin:557625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:3311:0:2337
SCTV:557625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:609:610:2369
DDT:564625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:3901:3902:2074
DDT HD:564625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:3911:0:2106
Test with TZAP has the following output;
root@myth-server:~# tzap -a 1 ABC1
using ‘/dev/dvb/adapter1/frontend0’ and ‘/dev/dvb/adapter1/demux0’
reading channels from file ‘/root/.tzap/channels.conf’
tuning to 543500000 Hz
video pid 0x0200, audio pid 0x028a
status 00 | signal acac | snr 0036 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
^C
root@myth-server:~# tzap -a 1 DDT
using ‘/dev/dvb/adapter1/frontend0’ and ‘/dev/dvb/adapter1/demux0’
reading channels from file ‘/root/.tzap/channels.conf’
tuning to 564500000 Hz
video pid 0x0f3d, audio pid 0x0f3e
status 00 | signal e3e3 | snr 0065 | ber 0000ffff | unc 00000000 |
status 00 | signal afaf | snr 0037 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal b1b1 | snr 0038 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
status 00 | signal ffff | snr 0000 | ber 0000ffff | unc 00000000 |
^C
root@myth-server:~# tzap -a 1 ‘Nine Darwin SD’
using ‘/dev/dvb/adapter1/frontend0’ and ‘/dev/dvb/adapter1/demux0’
reading channels from file ‘/root/.tzap/channels.conf’
tuning to 550500000 Hz
video pid 0x0200, audio pid 0x028a
status 00 | signal acac | snr 0036 | ber 0000ffff | unc 00000000 |
status 00 | signal caca | snr 0049 | ber 0000ffff | unc 00000000 |
status 00 | signal dada | snr 0059 | ber 0000ffff | unc 00000000 |
status 00 | signal d8d8 | snr 0056 | ber 0000ffff | unc 00000000 |
status 00 | signal d3d3 | snr 0051 | ber 0000ffff | unc 00000000 |
status 00 | signal c0c0 | snr 0035 | ber 0000ffff | unc 00000000 |
status 00 | signal d9d9 | snr 0058 | ber 0000ffff | unc 00000000 |
status 00 | signal c0c0 | snr 0034 | ber 0000ffff | unc 00000000 |
status 00 | signal d9d9 | snr 0058 | ber 0000ffff | unc 00000000 |
status 00 | signal dbdb | snr 005a | ber 0000ffff | unc 00000000 |
status 00 | signal d8d8 | snr 0056 | ber 0000ffff | unc 00000000 |
status 00 | signal cdcd | snr 004c | ber 0000ffff | unc 00000000 |
status 00 | signal b8b8 | snr 002f | ber 0000ffff | unc 00000000 |
status 00 | signal dbdb | snr 005a | ber 0000ffff | unc 00000000 |
^C
Like I’ve previously mentioned, I’m no expert with TZAP or it’s associated output so please pardon my ignorance here. One thing I’ve managed to notice so far is the frequency TZAP is reporting tuning channels too, doesn’t match the frequency of the channels.conf file? Could this be part of the problem?
Cheers,
Paul
@Paul, Yes, I’d noticed that. Are you sure that this channels file is called $HOME/.tzap/channels.conf? tzap doesn’t look like it’s using it.
OMG!! I’m such a plonker! Sorry, you were correct. I must of done something wrong when copying the new channels.conf across. Anyway, moving forward, I have good news. ABC is finally working!!! After discovering my little blunder with TZAP and the old channels.conf, another test proved that ABC was in fact locking perfectly. Alas MythTV still failed, even after a total delete and reconfig of DVB cards and channels. Finally I had success by manually extracting the Channel specifics from the channels.conf, and running a tuned import for channels on the ABC frequency manually. A total mission in the long run to get working, but finally all channels are finally tuning in Myth.. Happy days!!!… My mate owes me so much beer he can’t begin to imagine the dent in his wallet.. Thank you for your persistence Steve and continued efforts with the driver.. I’ll tell my mate he owes you a donation…. He reads this Blog too… He doesn’t understand it, but he reads it 😉
@Paul, thanks.
I can confirm that using Windows 7 RC I can tune all channels in my area. If I reboot into Linux, I can only tune the three channels on the TEN transport. I am still experimenting, so I will post back with my findings.
Looking at the acma.org website, it seems my theory might be looking good. In Canberra, which is about 1 hour drive away, most of the channels have at least one free channel of separation. ABC, which is the only channel I can’t tune with a HVR-2200 in Canberra, uses channel 9 for analog TV, and channel 9A for digital. Is it possible that the adjacent frequencies being in use is causing this tuner problem? I know that Australia, just to be different, uses 7Mhz separation, instead of 8Mhz like the rest of the world.
When I get a lock, it is a great picture! Just getting the lock is the problem.
Just for completeness, I was originally using the saa7164-stable drivers, I have also tried the saa7164-dev and v4l main repo with no difference.
Alex Ferrara, please try this tree http://www.kernellabs.com/hg/~mkrufky/saa7164/
If it still doesn’t work then please arrange for remote ssh access so we can analyze your environment. Contact me privately with the details. My email details are on the Contact page.
Will do. Thanks for your help.
Alex Ferrara, can you also just take a look at your channels.conf? Confirm that it’s actually set to tune to 7MHz channels rather than 8MHz channels…
You have to keep in mind that the applications are written *mostly* by Europeans… Those Europeans tend to forget to account for specific country-isms, such as AU using 7MHz bandwidth across the board.
Nothing against the Europeans — it’s just a simple matter of fact. I had to become an active LinuxTV developer years ago before ATSC was properly supported in many of these applications, and even still, many would say that even still ATSC isnt properly supported, but I digress.
Please post your channels.conf or scan file … *or* try the w_scan latest version and specify the AU country code to ensure it’s Doing The Right Thing ™
If you find that the channels.conf has 8MHz channels, just change them to 7MHz and see if that helps.
This is just a stab in the dark, but hey – it just might help (then again, might not) Let us know.
Initial scan data – I made this by hand from the output of MythTV with a working tuner.
# Australia / Goulburn / Rocky Hill
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
# ABC
T 725500000 7MHz 3/4 3/4 QAM64 8k 1/16 NONE
# SBS
T 746500000 7MHz 2/3 2/3 QAM64 8k 1/8 NONE
# WIN
T 767500000 7MHz 3/4 3/4 QAM64 8k 1/16 NONE
# Prime
T 788500000 7MHz 3/4 3/4 QAM64 8k 1/16 NONE
# TEN
T 809500000 7MHz 3/4 3/4 QAM64 8k 1/16 NONE
Channels.conf – I tuned this with the same working card using my inital scan data
ABC HDTV:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:516:0:672
ABC1:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:673
ABC2:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:651:674
ABC1:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:675
ABC3:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:676
ABC DiG Radio:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:690:678
ABC DiG Jazz:725500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:700:679
SBS ONE:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:849
SBS TWO:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:162:83:850
SBS 3:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:851
SBS 4:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:852
SBS HD:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:102:103:853
SBS Radio 1:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:201:862
SBS Radio 2:746500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:202:863
WIN TV Canberra:767500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:33:36:1
WIN TV HD:767500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:129:0:10
GO!:767500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:50:51:2
PRIME Canberra:788500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2740:2741:2374
PRIME HD:788500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2740:2741:2400
PRIME View 1:788500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2740:2741:2401
PRIME View 2:788500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2740:2741:2402
PRIME View 3:788500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2740:2741:2403
SC10 Canberra:809500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:353:354:2055
One HD Canberra:809500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:1711:0:2087
SC Ten:809500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:353:354:2119
I have had some success with the latest version of w_scan. It appears to be picking up some channels that it did not pick up before. The frequencies are slightly off though. Here is a copy of the newly generated channels.conf using the latest w_scan
ABC HDTV;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:516+2307:0;654:580:0:672:0:0:0
ABC1;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:512+128:650=eng;660:576:0:673:0:0:0
ABC2;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:513+2306:651=eng:577:0:674:0:0:0
ABC1;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:512+128:650=eng;660:576:0:675:0:0:0
ABC3;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:512+128:650=eng:576:0:676:0:0:0
ABC DiG Radio;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:0:690=eng:0:0:678:0:0:0
ABC DiG Jazz;ABC:725625:I999B7C999D999M999T999G999Y999:T:27500:0:700=eng:0:0:679:0:0:0
SBS ONE;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:161:81=eng:41:0:849:0:0:0
SBS TWO;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:162:83=eng:42:0:850:0:0:0
SBS 3;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:161:81=eng:41:0:851:0:0:0
SBS 4;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:161:81=eng:41:0:852:0:0:0
SBS HD;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:102:103=eng:41:0:853:0:0:0
SBS Radio 1;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:0:201=eng:0:0:862:0:0:0
SBS Radio 2;SBS:746625:I999B7C999D999M999T999G999Y999:T:27500:0:202=eng:0:0:863:0:0:0
WIN TV Canberra;WIN Digital:767625:I999B7C999D999M999T999G999Y999:T:27500:33:36=eng:47:0:1:0:0:0
WIN TV HD;WIN Digital:767625:I999B7C999D999M999T999G999Y999:T:27500:129:0;8001:0:0:10:0:0:0
GO!;WIN Digital:767625:I999B7C999D999M999T999G999Y999:T:27500:50:51=eng:52:0:2:0:0:0
PRIME Canberra;PRIME:788625:I999B7C999D999M999T999G999Y999:T:27500:2740:2741=eng:2745:0:2374:0:0:0
PRIME HD;PRIME:788625:I999B7C999D999M999T999G999Y999:T:27500:4600:0;4602:4605:0:2400:0:0:0
PRIME View 1;PRIME:788625:I999B7C999D999M999T999G999Y999:T:27500:2740:2741=eng:0:0:2401:0:0:0
PRIME View 2;PRIME:788625:I999B7C999D999M999T999G999Y999:T:27500:2740:2741=eng:0:0:2402:0:0:0
PRIME View 3;PRIME:788625:I999B7C999D999M999T999G999Y999:T:27500:2740:2741=eng:0:0:2403:0:0:0
SC10 Canberra;Southern Cross Television:809500:I999B7C999D999M999T999G999Y999:T:27500:353:354=eng:355:0:2055:0:0:0
One HD Canberra;Southern Cross Television:809500:I999B7C999D999M999T999G999Y999:T:27500:1711:0;1712:1713:0:2087:0:0:0
SC Ten;Southern Cross Television:809500:I999B7C999D999M999T999G999Y999:T:27500:353:354=eng:355:0:2119:0:0:0
Done.
I was reading through some documentation and I found something interesting that is definately related.
In Australia, the DVB-T frequency is the channel centre frequency +/- 125Khz at the discretion of the transmitter. So basically, the TV stations have the flexibility to move the frequency they transmit on to counteract interference and friends.
That simply cannot be a coincidence. My question is if that is something the driver needs to take care of in the tuning code or is it really up to the application software? I’m not quite sure what the right thing to doâ„¢ is?
Just a FYI, I manually added the transports into MythTV, along with the appropriate +125Khz offset and scanned for channels. You wouldn’t believe it, but they all work perfectly.
I’m not sure if this is now a Myth bug or a driver bug as to why it doesn’t find the transports automagically.
Alex,
I’m in Canberra and I’m having dramas getting ABC from Black Mountain to work. I can’t get it to lock from the Myth frontend, but I can get it to find the signal (from the backend setup).
Where did you set the 125KHz offset?
@Alex Ferrara, thanks for your feedback.
I’m glad to hear things are starting to work out for you. I’m going to take another pass at the demod driver and double check that we have broad locking enabled. I’d still like to try a few things on your remote PC and provide a patch if not.
You are welcome to do whatever you want to my machine. Just let me know when you are done.
Thanks.
I wonder if this 125Khz offset is the same reason I had issues with some channels on my Fusion Dual Digital Express? When you are finished with my dev box, I might take a look into that card as well. It has the same feel about it, in that in some areas it works perfectly, and in some areas it does not have good quality on all channels. The fact that the quality is bad could just be the card having a more sensitive tuner and actually locking on the wrong frequency.
This is completely off topic now, so I will start a new thread on the v4l list when I know something.
I have found an interesting post which might apply to DVB-T in regional Australia wholesale.
http://www.xpmediacentre.com.au/community/tuners-vista/33610-hauppauge-hvr-2200-gold-coast-resolved.html
I know that this is a guy talking about Windows Media Centre, but I especially took interest in his comment about the frequency tag in the transport stream not necessarily being changed for regional broadcasters. Just found it and thought I should share.
Is there still plans for a forum?
Last I spoke to ST he seemed to think that was on the cards.
Just curious.
cheers,
jed
A forum is likely to happen.
I just upgraded to Mythbuntu 10.10 and mythtv 0.23.1 and got a strange problem.
HW MB: Intel DH55TC, Tuner: PVR2200.
The setup worked perfectly in ubuntu 10.04 and mythtv 0.23+fixes.
As I did before, I use the same fw, drivers are in the kernel.
I do scan /usr/share/dvb/dvb-t/au-Melbourne > /ch.conf
And use that file as input in mythtv-setup.
It picks up channels on all 5 transporters but misses Ten HD & Seven HD.
I can look at all channels but SBS, GO, GEM and Nine won’t pick up any EIT data, the rest do that just fine.
I get One HD and ABC HD so it has nothing to do with HD channels, however the HD channels are a bit choppy in the picture.
That never happened with mythbuntu 10.04.
I have reinstalled from scratch and it stays the same.
Any suggestions what to do?
Oh, I just get about 40-50% signal strength when scanning, that was 80-100% on 10.04
I know this is an old thread, but not sure where to post for help …
Using MythTV with HVR-2200, on Debian Squeeze amd64.
It works pretty well on the 2.6.32 kernel (though one mux inclined to picture breaking up).
To build it I just used:
hg clone http://kernellabs.com/hg/saa7164-stable/
and ‘make’ went ahead and built it, no problem.
Now trying to get it going with 2.6.38 backport kernel, to enable audio over HDMI.
What do I need to do to build it for this kernel? Anyone else done it?