Canadian TV, Computing and Home Theatre Forums banner

121 - 140 of 398 Posts

·
Registered
Joined
·
6,257 Posts
To bad we didn't document which config files needed to be edited and which lines need to be disabled to make it easier for others to follow in our footsteps.
Interesting. I was looking at the MythTV Drivers Instillation Guide for the HVR-1600 and it says:

note: While in menuconfig, unless you have downloaded the entire kernel source, you will need to disable Multimedia support-->DVB/ATSC adapters --->FireDTV and FloppyDTV or build will fail
I believe this is what Mark did, though he edited the config files manually.
 

·
Registered
Joined
·
6,257 Posts
I am now experiencing the no audio bug on live TV and new recordings with the analog tuner as described in post #108. Programs I had recorded previously work fine. I tried the fix that Mark suggested in that post and it didn't work for me (the MythTV wiki for the HVR-1600 says it doesn't always work). I haven't restarted the PC since I made that change though (only so much you can do while holding a baby) so I am not sure if that will help or not.
That fixed the problem. I actually did a full shutdown to be sure everything was completely reset. I had restarted at least once prior to making the change and that didn't solve the problem so I figure a restart was needed after the "fix" (though I hadn't done a shutdown so I can't be sure).

I am now a happy camper! :) Just need to get the playback of HD broadcasts to work properly, though I think I will need to get a better PC for that.
 

·
Registered
Joined
·
1,543 Posts
That fixed the [missing audio] problem. I actually did a full shutdown to be sure everything was completely reset.
Mmm.. some of the wiki notes about this are from me here. :)

I have done everything I can possibly think of, but the "missing audio" issue reared it's head again for this week's Survivor episode. So I'll have to watch that one in silence now. :(

I cannot really tell if the problem has gotten worse or not with more recent drivers. I used to use a pair of PVR-250 cards for analog, and even *those* would have the issue once every couple of months.

But since swapping the HVR-1600 in place of one of the PVR-250 cards, it is definitely worse than before, and only an issue with the HVR-1600 (I think).

So far, it *only* happens here when two analog recordings begin at the same time, one on the PVR-250 and another on the HVR-1600. Though that could simply be because the HVR-1600 is only used when the PVR-250 is already busy.

The combined extra PCI bus activity is probably affecting the timing-dependent I2C communcations (used to twiddle the audio registers), and causing things to end up misconfigured. Edit: actually, that's probably wrong. I think it is a driver startup-up issue, because once the audio works, it stays working until the next reboot.

And once they get that way, the only thing that clears it is to unload/reload the drivers, which generally means "reboot".

We need to find a solution for this.

Cheers
 

·
OTA Forum Moderator
Joined
·
24,867 Posts
About the missing audio on analogue recordings issue, not knowing much about how your system is setup in regards to sound, does fiddling with alsamixer settings (particularly "SPDIF loop") while it is playing help? That's a common issue I've had with recordings from my Hauppauge 150 analogue cards on all of my mythfrontend boxes I've built. Once its fixed I store the alsa settings and it never happens again. Just tossing this out there...
 

·
Registered
Joined
·
1,543 Posts
No, ALSA has nothing to do with any tuner cards that feature onboard MPEG2 encoders, eg. PVR-250, HVR-1600, etc.. though it can get involved with non-encoding analog tuners such as the HVR-950Q.

Cheers
 

·
OTA Forum Moderator
Joined
·
24,867 Posts
Suit yourself, I've never bothered to dig into it so I'm not saying its an ALSA issue, just saying what fixes the problem every time for me. The 150s have onboard MPEG2 encoding. :)
 

·
Registered
Joined
·
1,543 Posts
HVR1600/cx18 analog "no audio" bug

Stampeder said:
About the missing audio on analogue recordings issue, not knowing much about how your system is setup in regards to sound, does fiddling with alsamixer settings (particularly "SPDIF loop") while it is playing help?
The "playing" of programs works fine. It's just the "recording" of a program which experiences the bug, resulting in no audio in the recorded file... and then no audio during playback regardless of what one tries.

I fiddled some more with it today, and noticed that there is also a cx18_alsa kernel module being built/loaded with the latest v4l2-dvb stuff. so I guess ALSA does now have something to do with stuff. But not on my system -- nothing uses that module.

Back to the actual problem now..

It's definitely a startup issue -- when the bug manifests, it does so immediately after loading the cx18 driver, and stays busted until the driver is unloaded/reloaded.

So I've written a script to detect the problem, before starting mythbackend, and to rmmod/modprobe cx18 over and over until the problem goes away, up to a reasonable retry limit.

fix_hvr1600_stutter.sh:
Code:
#!/bin/bash
#
# Script to fix HVR-1600 initialization problems:
#
# (1) fix stuttering of first analog recording, by tuning/recording a fragment.
# (2) fix(?) "no analog audio" problem by reloading driver if audio comes up muted.
#

function initialize_tuner(){
        logger -- "$dev: $MYNAME: Pre-initializing"
        ivtv-tune -c 24 $dev &>/dev/null
        dd if=$dev bs=256k count=1 > /dev/null 2>/dev/null      ## Fix "stuttering audio"
}

function check_mute(){
        for t in {0..15} ; do
                sleep 0.1
                mute=`v4l2-ctl -d $dev -C mute`
                [ "$mute" = "mute: 0" ] && exit
        done
        echo "muted"
}

function fix_tuners(){
        for dev in /dev/video[0-9] ; do
                if v4l2-ctl -D -d $dev | grep -q 'Hauppauge HVR-1600' &>/dev/null ; then
                        initialize_tuner
                        muted="`check_mute`"
                        if [ "$muted" != "muted" ]; then
                                logger -- "$dev: $MYNAME: HVR1600/cx18 audio ok."
                        else
                                logger -- "$dev: $MYNAME: HVR1600/cx18 audio bug, reloading cx18 driver"
                                rmmod cx18_alsa
                                rmmod cx18 || logger -- "$dev: $MYNAME: rmmod cx18 failed"
                                modprobe cx18
                                break
                        fi
                fi
        done
        echo -n "$muted"
}

export MYNAME="${0##*/}"

for t in {0..4} ; do
        [ "`fix_tuners &>/dev/null`" == "muted" ] || exit 0
done
logger -- "$dev: $MYNAME: HVR1600/cx18 audio bug, reloading failed to fix it"
exit 1
Now we just have to wait for the bug to happen again here, to validate the workaround. :)

Cheers
 

·
Registered
Joined
·
1,543 Posts
I also looked deep into the cx18-driver.c source code today, and I'm not terribly impressed.

The version I'm using here (the "tip" of the git development tree), includes a "fix" for the other issue: "stuttering audio" on first analog recording.

But their idea of a "fix" was to simply duplicate about 50 lines of code which deals with downloading firmware to the card (rather than, say, having only one copy of that code in a function that then gets called twice.. duh).

Now, I suspect the "no audio" bug is really due to a corrupted firmware download. So by downloading the firmware twice in a row on startup, they've now doubled the odds of the bug happening. Which likely explains why we see it much more often now than in the past.

Or that could just be my hyperactive imagination at work. ;)
 

·
Registered
Joined
·
1,543 Posts
Mmm.. I told Duke (our MythTV butler) to record two analog programs at the same time every two hours overnight, powering down automatically between each pair of recordings.

Dang thang want fail fur meh naw. ;)

None of the various audio-bug workarounds are being triggered -- I know this, because they all write to the syslog() when they get triggered.

So.. assuming the problem really has gone away, the only "workaround" that is currently in effect, is the removal of the new cx18-alsa driver. We don't need this for anything whatsoever, so I had simply deleted the file from Duke:

find /lib/modules -name cx18-alsa.ko | xargs -r rm ; depmod

Gone, after the next reboot.

Maybe that driver was the problem. Perhaps it was doing something that upset the APU (audio processing unit) on the cx18 (MPEG2 encoder) chip, causing it to stop working?

Time will tell. In the meanwhile, Roger: you should nuke that file from your system too.

The only use I can imagine for it, would be to capture audio-only recordings from the A/V inputs of the HVR-1600. But MythTV has no use for it right now.. so nuke it!

Cheers

Mark
 

·
OTA Forum Moderator
Joined
·
24,867 Posts
Module blacklisting for device loading control

mlord said:
We don't need this for anything whatsoever, so I had simply deleted the file from Duke:

find /lib/modules -name cx18-alsa.ko | xargs -r rm ; depmod
mlord we all obviously trust that you've done your due diligence to prove that it is not needed so nothing wrong with deleting it, but for those who aren't sure about possible side-effects it's just as effective to blacklist a module in /etc/modprobe.conf so that if it does have a purpose it will still be available on the system. You can debug devices quite well between bootups by using blacklisting too.

I use modprobe blacklisting to stage the loading of all my TV devices in my own desired sequence to guarantee that udev doesn't change their order and thus confuse the mythbackend by assigning them different device names. I've been using this method since before udev was ever introduced so I still keep doing it with my existing script rather than write a bunch of new udev rules. :)

First I put the ivtv module used by my two Hauppauge 150 PCI analogue cards into /etc/modprobe.preload so that those card are available as the kernel loads. In my experience this is preferable for them, so they come alive and load their v4l-cx2341x-enc.fw firnware. They are invariably assigned the same device names.

OTOH I don't want any of my other TV device modules automatically loaded since the system might assign different device names on each boot. NOTE: it is possible to write special udev rules that prevent that, but what I've got works perfectly so I cannot be bothered.

So, the following devices are blacklisted at the top of /etc/modprobe.conf before any other existing lines:
Code:
blacklist em28xx # Hauppauge 980 ATSC USB device(s)
blacklist em28xx-dvb # Hauppauge 980 ATSC USB device(s)
blacklist em28xx-alsa # Hauppauge 980 ATSC USB device(s)
blacklist au0828 # Hauppauge 950Q ATSC USB device(s)
blacklist cx88-alsa # pcHDTV PCI card(s)
blacklist cx8800 # pcHDTV PCI card(s)
blacklist cx8802 # pcHDTV PCI card(s)
blacklist cx88-dvb # pcHDTV PCI card(s)
blacklist cx88xx # pcHDTV PCI card(s)
options xc5000 no_poweroff=1 # workaround for lazy 950Q Live TV tuning bug
Then I have this script called almost last in the bootup process:
Code:
#!/bin/sh                          
#                                  
# Make sure that pcHDTV dvb modules are loaded first:
# (does not load any firmware)
#                                                    
/sbin/lsmod|grep cx88 >& /dev/null                   
if [ $? != 0 ]
 then
  /sbin/modprobe cx88-alsa
  /sbin/modprobe cx8800
  /sbin/modprobe cx8802
  /sbin/modprobe cx88-dvb
  /sbin/modprobe cx88xx
fi
# Then make sure that Hauppauge 950Q USB dvb modules are loaded: 
# (loads dvb-fexc5000-1.6.114.fw firmware)
#
/sbin/lsmod|grep au0828 >& /dev/null
if [ $? != 0 ]
 then
  /sbin/modprobe au0828
fi

# Then make sure that Hauppauge 980 dvb modules are loaded:
# (loads xc3028-v27.fw firmware)
#
/sbin/lsmod|grep em28xx >& /dev/null
if [ $? != 0 ]
 then
  /sbin/modprobe em28xx
  /sbin/modprobe em28xx-dvb
  /sbin/modprobe em28xx-alsa
fi
The only reason I put the "if" test on each device's turn was so that I could run the script in real time as needed if I felt like it.

Once again the purpose of all this was to use blacklisting to prevent the system from automatically loading modules for certain devices so that my own script loads them in proper order. Again, it is possible to do this with udev rules but as I say, it has worked fine for me this way for years so I haven't bothered.
 

·
Registered
Joined
·
1,543 Posts
Got it! HVR-1600 / cx18 "no audio" workaround

Mmm.. I told Duke (our MythTV butler) to record two analog programs at the same time every two hours overnight, powering down automatically between each pair of recordings.

Dang thang want fail fur meh naw. ;)
It failed again this evening, and tried to put the Amazing Race into the silent film realm..

But the rmmod/modprobe script caught it and corrected things, so no damage done! Yahoo!!

There was a tiny one-character bug in the script, but it still worked. Here's the updated (fixed) script, with an errant ampersand eliminated. To use it, just arrange for it to be invoked prior to starting mythbackend, typically by inserting a call to it into /etc/init/mythtv-backend.conf and/or /etc/init.d/mythtv-backend

Yay! :)

fix_hvr1600_audio.sh, v2
Code:
#!/bin/bash
#
# Script to fix HVR-1600 audio initialization problems (v2):
#
# (1) fix stuttering of first analog recording, by tuning/recording a fragment.
# (2) fix(?) "no analog audio" problem by reloading driver if audio comes up muted.
#

for prog in ivtv-tune v4l2-ctl logger rmmod modprobe ; do
        if ! type -all "$prog" &>/dev/null ; then
                echo "$0: '$prog' not found on PATH, aborted." >&2
                exit 1
        fi
done

function initialize_tuner(){
        logger -- "$dev: $MYNAME: Pre-initializing"
        ivtv-tune -c 24 $dev &>/dev/null
        dd if=$dev bs=256k count=1 &>/dev/null  ## Fix "stuttering audio"
}

function check_mute(){
        for t in {0..15} ; do
                sleep 0.1
                mute=`v4l2-ctl -d $dev -C mute`
                [ "$mute" = "mute: 0" ] && exit
        done
        echo "muted"
}

function fix_tuners(){
        for dev in /dev/video[0-9] ; do
                if v4l2-ctl -D -d $dev | grep -q 'Hauppauge HVR-1600' &>/dev/null ; then
                        initialize_tuner
                        muted="`check_mute`"
                        if [ "$muted" != "muted" ]; then
                                logger -- "$dev: $MYNAME: HVR1600/cx18 audio ok."
                        else
                                logger -- "$dev: $MYNAME: HVR1600/cx18 audio bug, reloading cx18 driver"
                                rmmod cx18_alsa &>/dev/null
                                rmmod cx18 || logger -- "$dev: $MYNAME: rmmod cx18 failed"
                                modprobe cx18
                                break
                        fi
                fi
        done
        echo "$muted"
}

export MYNAME="${0##*/}"

rmmod cx18_alsa &>/dev/null     ## don't need this loaded, so get rid of it!
for t in {0..4} ; do
        [ "`fix_tuners 2>/dev/null`" == "muted" ] || exit 0
done
logger -- "$dev: $MYNAME: HVR1600/cx18 audio bug, reloading failed to fix it"
exit 1
 

·
Registered
Joined
·
1,543 Posts
Another failure tonight. Pretty regular, now.

Except this one couldn't be fixed. The audio was still working after modprobe, but failed later when mythbackend did it's initial channel tuning on startup.

Nothing lost, but this means the "workaround" doesn't catch everything.

Ugh.
 

·
Registered
Joined
·
405 Posts
Discussion Starter #134
Roger and I finally got together last evening, and enabled the Hauppauge remote control of the HVR-1600, on his Mythbuntu 9.10 system.

Not easy.

...

I expect this all to just go away with the upcoming Mythbuntu-10.4 release (April 2010), which is based on the 2.6.32 Linux kernel, with a working ir-kbd-i2c driver included by default. The enable_hauppauge_remote.sh script will still be needed, but that's a simple thing to tack on.

Cheers
Based on the long list of instructions that were way above my head, I'm going to have to wait for 10.4 to come out. Hopefully the April date holds.

Mlord, do you think your existing script will work, or will it need some tweaks?
 

·
Registered
Joined
·
405 Posts
Discussion Starter #136
I actually tried mythdora 10.21 a few months ago when I was trying to work out a video driver bug. It didn't solve that problem and I never got far enough into the install to try the remote. I will definitly give MD 12 a try. I noticed that the beta is supposed to be over after february so maybe a final release will be coming shortly.

Thanks for the suggestion.
 

·
Registered
Joined
·
405 Posts
Discussion Starter #138
Well, I tried to get the mythdora 12 beta but it was already over. The final version is going to be based on mythtv 0.23 anyway, so it looks like I have to wait.
 

·
Registered
Joined
·
1,543 Posts
Another failure tonight. Pretty regular, now.

Except this one couldn't be fixed. The audio was still working after modprobe, but failed later when mythbackend did it's initial channel tuning on startup.

Nothing lost, but this means the "workaround" doesn't catch everything.
Continuing with the HVR-1600 "missing analog audio" issue..

I've been in contact with Andy Walls, who seems to be a/the lead cx18 driver dude. He suspects something wrong with the hard/soft reset code in the driver, and has made some patches available to try and fix things.

I've been busy elsewhere, but today I updated the drivers to the latest "tip", and added his reset patches on top of the mix.

We'll see how things go over the next week or three.

Cheers
 

·
Registered
Joined
·
1,543 Posts
the HVR-1600 missing audio issue

More progress. The developer (Andy) managed to find an analog O.T.A. NTSC channel, and reproduced the problem on his own machine.

He's now got a new patch that he believes is a solid fix for the issue. I'm testing it here now.

Ottawa folks with HVR-1600's in their MythTV box should plan on getting in touch, perhaps next weekend -- we could get together and update everyone's system to a reliable working state.

Cheers
 
121 - 140 of 398 Posts
Top