Canadian TV, Computing and Home Theatre Forums banner

Mythtv

76K views 397 replies 31 participants last post by  mwalma 
#1 ·
Mythtv has announced version 0.22 release candidate 1 is now available. Hopefully all goes well and a stable 0.22 will come out shortly.

The release notes are here.
 
#119 ·
I finally got a moment to plug everything back in at home last night and 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.
 
#122 ·
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.
 
#120 ·
Thanks for the updates on MythTV with the HVR-1600. Last week I began what must be my third attempt over the years to get Myth running. I hadn't even gotten to configuring my HVR-1600 yet but it sounds like there is still work to be done so I'll wait a couple months for the dust to settle on 10.4. My hope this time around was to get better Clear QAM support than I'm getting with my Windows set up among other things.
 
#125 ·
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...
 
#128 ·
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
 
#129 ·
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. ;)
 
#130 ·
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
 
#132 ·
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
 
#131 ·
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.
 
#133 ·
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.
 
#139 ·
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
 
#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.
 
#140 ·
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
 
#144 ·
re: 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.
The patch works: it doesn't fix whatever the underlying bug is, but it does appear to very reliably work around the problem. Good audio!
Code:
# HG changeset patch
# User Andy Walls <awalls@md.metrocast.net>
# Date 1270961101 14400
# Node ID 95caae49dacd93d92904f84faa977a287e9e2940
# Parent  7c0b887911cf5186beb446aea0ec8558ad5cebd2
cx18: Allow for fallback broadcast audio standard detections

From: Andy Walls <awalls@md.metrocast.net>

Sometimes the CX23418 A/V decoder's microcontroller never figures out
the audio standard.  Now we watch to see if the microcontroller fails to detect,
and we come through and tell it to try a fall back detection.  Right now the
only real audio standard fall back detection is for NTSC-M/BTSC.  All the other
TV standards "fall back" to their current audio standard auto-detection.

Priority: normal

Signed-off-by: Andy Walls <awalls@md.metrocast.net>

--- a/linux/drivers/media/video/cx18/cx18-av-core.c     Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/media/video/cx18/cx18-av-core.c     Sun Apr 11 00:45:01 2010 -0400
@@ -22,6 +22,7 @@
  *  02110-1301, USA.
  */

+#include <linux/timer.h>
 #include <media/v4l2-chip-ident.h>
 #include "cx18-driver.h"
 #include "cx18-io.h"
@@ -514,40 +515,58 @@
        cx18_av_write(cx, 0x47f, state->slicer_line_delay);
 }

-static void input_change(struct cx18 *cx)
+static void cx18_av_setup_aud_detect(struct cx18 *cx,
+                                    u8 std_mode_sys, u8 format, u16 fallback);
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 20)
+void cx18_av_aud_detect_work(struct work_struct *work)
+{
+#else
+void cx18_av_aud_detect_work(void *arg)
+{
+       struct work_struct *work = arg;
+#endif
+       struct cx18_av_state *state = container_of(work, struct cx18_av_state,
+                                                  aud_detect_work);
+       struct v4l2_subdev *sd = &state->sd;
+       struct cx18 *cx = v4l2_get_subdevdata(sd);
+
+       u8 mod_det_stat1 = cx18_av_read(cx, 0x805);
+       u16 fallback;
+
+       /* Did the microcontroller detect something ? */
+       if (mod_det_stat1 == 0xfe || /* Forced mode */
+           (mod_det_stat1 > 0 && mod_det_stat1 < 0x12))
+               return;
+       /* (re)attempt the fallback position */
+       printk(KERN_INFO "%s: cx18/hvr1600 audio bug: doing fallback detection\n", __func__);
+       fallback = atomic_read(&state->fallback_aud_std_mode);
+       cx18_av_setup_aud_detect(cx, fallback >> 8, fallback & 0xff, fallback);
+}
+
+static void cx18_av_aud_detect_timeout(unsigned long data)
+{
+       struct cx18_av_state *state = (struct cx18_av_state *) data;
+       /* do audio detection failure checks in a non-interrupt context */
+       schedule_work(&state->aud_detect_work);
+}
+
+static void cx18_av_setup_aud_detect(struct cx18 *cx,
+                                    u8 std_mode_sys, u8 format, u16 fallback)
 {
        struct cx18_av_state *state = &cx->av_state;
-       v4l2_std_id std = state->std;
        u8 v;

-       /* Follow step 8c and 8d of section 3.16 in the cx18_av datasheet */
-       cx18_av_write(cx, 0x49f, (std & V4L2_STD_NTSC) ? 0x14 : 0x11);
-       cx18_av_and_or(cx, 0x401, ~0x60, 0);
-       cx18_av_and_or(cx, 0x401, ~0x60, 0x60);
+       mutex_lock(&state->aud_detect_mutex);
+       /* Set for broadcast audio detection */
+       cx18_av_write_expect(cx, 0x808, std_mode_sys, std_mode_sys, 0xff);
+       cx18_av_write_expect(cx, 0x80b, format, format, 0x3f);
+       atomic_set(&state->fallback_aud_std_mode, fallback);

-       if (std & V4L2_STD_525_60) {
-               if (std == V4L2_STD_NTSC_M_JP) {
-                       /* Japan uses EIAJ audio standard */
-                       cx18_av_write_expect(cx, 0x808, 0xf7, 0xf7, 0xff);
-                       cx18_av_write_expect(cx, 0x80b, 0x02, 0x02, 0x3f);
-               } else if (std == V4L2_STD_NTSC_M_KR) {
-                       /* South Korea uses A2 audio standard */
-                       cx18_av_write_expect(cx, 0x808, 0xf8, 0xf8, 0xff);
-                       cx18_av_write_expect(cx, 0x80b, 0x03, 0x03, 0x3f);
-               } else {
-                       /* Others use the BTSC audio standard */
-                       cx18_av_write_expect(cx, 0x808, 0xf6, 0xf6, 0xff);
-                       cx18_av_write_expect(cx, 0x80b, 0x01, 0x01, 0x3f);
-               }
-       } else if (std & V4L2_STD_PAL) {
-               /* Follow tuner change procedure for PAL */
-               cx18_av_write_expect(cx, 0x808, 0xff, 0xff, 0xff);
-               cx18_av_write_expect(cx, 0x80b, 0x03, 0x03, 0x3f);
-       } else if (std & V4L2_STD_SECAM) {
-               /* Select autodetect for SECAM */
-               cx18_av_write_expect(cx, 0x808, 0xff, 0xff, 0xff);
-               cx18_av_write_expect(cx, 0x80b, 0x03, 0x03, 0x3f);
-       }
+       /* Unmute on detect, even if not the exact mode (Mono/Stereo/Lang B) */
+       v = cx18_av_read(cx, 0x809);
+       v &= ~0x10;
+       cx18_av_write_expect(cx, 0x809, v, v, 0x10);

        v = cx18_av_read(cx, 0x803);
        if (v & 0x10) {
@@ -556,6 +575,55 @@
                cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
                v |= 0x10;
                cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
+
+               /* restart the format detection loop */
+               v = cx18_av_read(cx, 0x9cc);
+               v &= ~0x02;
+               cx18_av_write_expect(cx, 0x9cc, v, v, 0x02);
+               v |= 0x02;
+               cx18_av_write_expect(cx, 0x9cc, v, v, 0x02);
+               v &= ~0x02;
+               cx18_av_write_expect(cx, 0x9cc, v, v, 0x02);
+
+               /* Setup to check later if detecton worked */
+               mod_timer(&state->aud_detect_timer,
+                         jiffies + msecs_to_jiffies(1500));
+       }
+       mutex_unlock(&state->aud_detect_mutex);
+}
+
+static void input_change(struct cx18 *cx)
+{
+       struct cx18_av_state *state = &cx->av_state;
+       v4l2_std_id std = state->std;
+
+       /* Follow step 8c and 8d of section 3.16 in the cx18_av datasheet */
+       cx18_av_write(cx, 0x49f, (std & V4L2_STD_NTSC) ? 0x14 : 0x11);
+       cx18_av_and_or(cx, 0x401, ~0x60, 0);
+       cx18_av_and_or(cx, 0x401, ~0x60, 0x60);
+
+       /*
+        * Setup broadcast audio detection.
+        * Look in log_audio_status() to decode magic numbers used for
+        * registers 0x808 and 0x80b.
+        */
+       if (std & V4L2_STD_525_60) {
+               if (std == V4L2_STD_NTSC_M_JP) {
+                       /* Japan uses EIAJ audio standard */
+                       cx18_av_setup_aud_detect(cx, 0xf7, 0x02, 0xf702);
+               } else if (std == V4L2_STD_NTSC_M_KR) {
+                       /* South Korea uses A2 audio standard */
+                       cx18_av_setup_aud_detect(cx, 0xf8, 0x03, 0xf803);
+               } else {
+                       /* Others use the BTSC audio standard */
+                       cx18_av_setup_aud_detect(cx, 0xf6, 0x01, 0x1101);
+               }
+       } else if (std & V4L2_STD_PAL) {
+               /* Follow tuner change procedure for PAL */
+               cx18_av_setup_aud_detect(cx, 0xff, 0x03, 0xff03);
+       } else if (std & V4L2_STD_SECAM) {
+               /* Select autodetect for SECAM */
+               cx18_av_setup_aud_detect(cx, 0xff, 0x03, 0xff03);
        }
 }

@@ -1433,6 +1501,17 @@
        state->slicer_line_delay = 0;
        state->slicer_line_offset = (10 + state->slicer_line_delay - 2);

+       mutex_init(&state->aud_detect_mutex);
+       setup_timer(&state->aud_detect_timer, cx18_av_aud_detect_timeout,
+                   (unsigned long) state);
+       atomic_set(&state->fallback_aud_std_mode, 0xf601); /* Autodetect BTSC */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 20)
+       INIT_WORK(&state->aud_detect_work, cx18_av_aud_detect_work);
+#else
+       INIT_WORK(&state->aud_detect_work, cx18_av_aud_detect_work,
+                 &state->aud_detect_work);
+#endif
+
        sd = &state->sd;
        v4l2_subdev_init(sd, &cx18_av_ops);
        v4l2_set_subdevdata(sd, cx);
--- a/linux/drivers/media/video/cx18/cx18-av-core.h     Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/media/video/cx18/cx18-av-core.h     Sun Apr 11 00:45:01 2010 -0400
@@ -25,6 +25,9 @@
 #ifndef _CX18_AV_CORE_H_
 #define _CX18_AV_CORE_H_

+#include <linux/timer.h>
+#include <linux/workqueue.h>
+#include <linux/mutex.h>
 #include <media/v4l2-device.h>

 struct cx18;
@@ -102,6 +105,10 @@
        u32 audclk_freq;
        int audmode;
        int default_volume;
+       struct mutex aud_detect_mutex; /* protect microcontroller setup */
+       struct timer_list aud_detect_timer;
+       struct work_struct aud_detect_work;
+       atomic_t fallback_aud_std_mode;
        u32 id;
        u32 rev;
        int is_initialized;
 
#141 ·
Great news Mark! Lets hope this issue is resolved for once and for all.

As for this weekend, I will have to check with my wife to see what our schedule is like. I do know that I am stuck at home Saturday morning and have a commitment late afternoon that I can't avoid.
 
#143 ·
Mythbuntu-10.04 EPG: schedule-ui.xml.patch

Yeah, Baby! That's what I'm talkin' about!! :)

Code:
--- schedule-ui.xml.orig        2010-04-12 21:10:49.000000000 -0400
+++ schedule-ui.xml     2010-04-12 21:10:50.000000000 -0400
@@ -1,6 +1,14 @@
 <mythuitheme>

     <window name="programguide">
+       <font name="gridfont" face="DejaVu Sans">
+            <size>10</size>
+            <color>#FFFFFF</color>
+       </font>
+       <font name="channelfont" face="DejaVu Sans">
+            <size>12</size>
+            <color>#FFFFFF</color>
+       </font>

         <shape name="shape2" from="baseboxbackground">
             <area>30,125,1220,100</area>
@@ -34,8 +42,8 @@
         <guidegrid name="guidegrid">
             <area>220,295,1032,390</area>
             <layout>horizontal</layout>
-            <channels>5</channels>
-            <timeslots>4</timeslots>
+            <channels>10</channels>
+            <timeslots>8</timeslots>
             <solidcolor>#003256</solidcolor>
             <selector type="box" linecolor="#bcbcbc" ></selector>
             <showcategories>yes</showcategories>
@@ -44,7 +52,7 @@
             <conflictingcolor>#ff6600</conflictingcolor>
             <cutdown>no</cutdown>
             <multiline>yes</multiline>
-            <textoffset>9,6</textoffset>
+            <textoffset>6,3</textoffset>
             <recordstatus type="SingleRecord" image="shared/gg-rs-single.png"></recordstatus>
             <recordstatus type="TimeslotRecord" image="shared/gg-rs-timeslot.png"></recordstatus>
             <recordstatus type="ChannelRecord" image="shared/gg-rs-channel.png"></recordstatus>
@@ -54,7 +62,7 @@
             <recordstatus type="OverrideRecord" image="shared/gg-rs-override.png"></recordstatus>
             <arrow direction="left" image="shared/gg-arrow-left.png"></arrow>
             <arrow direction="right" image="shared/gg-arrow-right.png"></arrow>
-            <font>basesmall</font>
+            <font>gridfont</font>
         </guidegrid>

         <buttonlist name="timelist">
@@ -63,16 +71,16 @@
             <spacing>0</spacing>
             <buttonarea>0,0,1036,36</buttonarea>
             <statetype name="buttonitem">
-                <area>0,0,258,36</area>
+                <area>0,0,129,36</area>
                 <state name="active">
                    <shape name="buttonbackground">
-                       <area>0,0,258,36</area>
+                       <area>0,0,129,36</area>
                        <fill color="#222222" alpha="150" />
                        <type>roundbox</type>
                        <cornerradius>18</cornerradius>
                    </shape>
                     <textarea name="buttontext" from="basetextarea">
-                        <area>10,0,238,36</area>
+                        <area>10,0,119,36</area>
                         <font>basesmall</font>
                         <align>center</align>
                     </textarea>
@@ -112,20 +120,20 @@
             <spacing>0</spacing>
             <buttonarea>0,0,190,395</buttonarea>
             <statetype name="buttonitem">
-                <area>0,0,190,74</area>
+                <area>0,0,190,37</area>
                 <state name="active">
                    <shape name="buttonbackground">
-                       <area>0,0,190,78</area>
+                       <area>0,0,190,39</area>
                        <fill color="#222222" alpha="150" />
                        <type>roundbox</type>
                        <cornerradius>10</cornerradius>
                    </shape>
                     <imagetype name="channelicon">
-                        <area>10,15,40,40</area>
+                        <area>10,5,30,30</area>
                     </imagetype>
                     <textarea name="buttontext" from="basetextarea">
-                        <area>55,0,130,78</area>
-                        <font>basesmall</font>
+                        <area>55,0,130,39</area>
+                        <font>channelfont</font>
                         <font state="favourite">basesmallyellow</font>
                         <font state="unavailable">basesmallblue</font>
                         <font state="favunavailable">basesmallpurple</font>
That's 10 channels by 8 half-hour timeslots for the default Mythbuntu-10.04 theme, which is four times the amount of information presented there by default.

Time to think seriously about an upgrade now.. ;)
 
#152 ·
MythTV-0.23

Well, it's still mostly working, and by now it has enough tendrils into the SQL database that I couldn't wipe it away even if I wanted to.

So mythtv-0.23 is on Duke to stay.

It is noticeably buggier than 0.21 was, though. Lots of (vdpau) playback glitches on CBC-HD recordings -- was never an issue with 0.21-vdapu.

And the front-end has mysteriously crashed/exited twice now. I suppose there might be info in a log file somewhere, but I'll just ignore it and hope it goes away some day soon. :)

I haven't yet fixed all of the annoying b0rked arrow keys in the GUI, but the main one (Media->Recordings) has been patched away, making it bearable for now.

Last evening, mythtv got confused somehow and couldn't tune anything on the HVR-950Q, which is used only for digital in that system. Rebooting cured it, for now.

In my separate, test system, the analog side of the 950Q suddenly started working again for no obvious reason. But it too requires the odd reboot on occasion when the tuner stops working.

All in all, very reminiscent of mythtv-0.18, when I first installed it. A bit of a shame it's all gone backward after the steller 0.21 series, but that's progress.

Cheers
 
#155 ·
Re: MythTV, HVR-950Q, and Analog Support Woes - Arghhh

If anyone can help me setup my 950Q with analog to work with mythtv, I would sure appreciate it, just google 950Q and mythtv and all the hits are mine. Perhaps someone on this site has a new insight (I am relatively new to mythtv, and all the basics are set up for the HVR-950Q drivers and "no power off" (it's working great in tvtime). What can I do for Mythtv to work???
 
#156 ·
If anyone can help me setup my 950Q with analog to work with mythtv, I would sure appreciate it
It works, but is not yet foolproof. The blog of the driver developer was updated recently, noting that MythTV still doesn't get locking correct between the digital and analog sides (despite recording groups, which are supposed to solve issues like this).

That said, it mostly works.

The digital side is easy to set up -- if your 950Q is your only tuner, then it will show up (digital) as the only DVB device. The only trick here, is to create a custom recorder group (instead of the default of "generic") for it.

Then tackle the analog side. If it is your only tuner device, then this will be /dev/video0, and probably /dev/dsp1 for the audio -- yes you need this field.

Then put it in the same recorder group as the digital side.

After doing mythfilldatabase and setting up the channels for everything, fire up mythfrontend. Go into the Setup -> ... -> Recording Profiles, and set the resolution for the analog to be 720x480 for everything (default, live-tv, etc..). Change the audio sampling rate to 48000.

Now restart everything (reboot?), and the analog will probably work.

Cheers
 
#157 ·
Something I should add, is that you'll need to create an "input source" for digital, and a second "input source" for analog. Yes, they can both point at exactly the same schedulesdirect.org channel lineup, but they do need to be separate otherwise.

Then use the "input connections" menu in mythtv-setup to point the digital side of the 950Q at the digital "source", and the analog side at the analog "source".

Cheers
 
#158 · (Edited)
Analog cable, HVR950Q, MythTV Blues!!!!!

Cool thanks for the reply! 2 months and this is the best explicit response yet. I am trying to do everything you said in a fresh setup, to the letter (even though I don't have any digital cable channels). I am hoping at this point that it is a simple MythTV oversight as I am still new to all this tuner stuff.

Not working yet, only a black screen....

My first question ( of many - if you are patient enough) is ... Could you be more specific about the changing of the default group? Is that in the Backend/input_Connections/Select_A _Card/second page? And would you do anything different if you only had an NTSC analog cable signal.

Second Question is ...What would you be using for username:password/localhost or IPaddress/ for mythconverg for a backend on the same machine as the frontend BUT I plan (Optimistically perhaps) to get it to work with another laptop frontend for fun. Presently I changed it from mythtv:mythtv (to ack(my username):to user password because I changed my storage to my user account and that solved livetv problems with another card - PVRUSB2 that now works with LiveTV.

Thanks for the new optimism

Mark :p
 
#159 ·
Not working yet, only a black screen....
If you haven't discovered free, over-the-air HDTV yet, then yes.. you can just not configure the digital half of the tuner at all. Just delete it from the "tuner cards" list, and then you don't have to fuss with the "recording groups" at all.

But you MUST still fix the "Recording Profiles" to use 720x480. That is a 100% requirement.

Now.. forget LiveTV, and just tell MythTV to record something. See if the recording it creates is viewable or not.

On my system here, for a while I could record and watch a recording, but not watch "LiveTV" (even though the two are more or less identical in functionality). At some later point, LiveTV started working too.
 
#162 ·
Change Episode Name

Is there an easy way to change the title/episode name in MythTV 0.22? Apparently this feature was added in 0.21 (highlight the recording, press I, select "Recording Options", and select "Change Recording Title"), but I can't seem to find the "Change Recording Title" option in 0.22? Was it removed?

One of the programs I record for my older daughter doesn't seem to have the episode name in the guide data and since she likes to watch them again and again, I thought it would be nice to know which was which.
 
#191 ·
Is there an easy way to change the title/episode name in MythTV 0.22? Apparently this feature was added in 0.21 (highlight the recording, press I, select "Recording Options", and select "Change Recording Title"), but I can't seem to find the "Change Recording Title" option in 0.22?
I must have been blind the previous times I looked for it (or more likely half asleep) as I saw it there the other day, staring me right in the face. Sorry about that.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top