FWIW, I've just got rid of this same problem myself (loss of audio, need
to hit "-" or "+" to get it working, doesn't always work then anyway).
Original server (with the problem existing ONLY on the USB tuner):
Pentium III 866 dual-CPU server on AOpen motherboard
Hauppauge Nova-T PCI
DigitalNow TinyUSB 2 DVB T Receiver connected to USB 2.0 PCI card (mobo
has no USB 2.0 ports and device requires it).
Previous (temporary) server (acting as slave backend, the problem did
NOT exist):
Asus Pundit (not -R) Pentium 4 2800
Normally runs only frontend, was running as slave backend as temporary
measure (before I got the USB 2.0 PCI card for the original server)
DigitalNow TinyUSB 2 DVB T Receiver connected to native USB 2.0 bus.
New server (the problem no longer exists):
Gigabyte GA-7VAXP Ultra with Athlon 2800+ CPU
Hauppauge Nova-T PCI (from previous server)
DigitalNow TinyUSB 2 DVB T Receiver connected to native USB 2.0 bus.
My conclusion ... the bandwidth was stretched on the original server was
stretched to the point that it could not handle all of the data going
backwards and forwards (it's not a case of CPU utilisation as that was
always low, it's the various limited bus bandwidths PCI &
northbridge/southbridge links). The USB card was a second and lower
priority card in the original server, which meant that it was only used
when the Hauppauge card was recording already, and with the USB card
running over the PCI bus (rather than hanging off a USB port on the
southbridge) it was consuming a significant amount of the total
bandwidth and the system ended up dropping interrupts or otherwise
losing data (as if the reception was poor). Now on the new server with
more modern hardware (USB 2.0 directly on southbridge, etc) the problem
has gone away (and wife is happy). I may be completely wrong, of
course, but it's certainly believable/arguable (?).
btw - corruption in the DVB stream will also explain the strange
behaviour you're seeing where some applications can recover /
reinterpret the missed data. I had the same thing with my streams,
usually using PVA Strumento to convert them to true PS streams would
result in many lost & gained audio frames and usually an unusable mpeg
file. Reception should also be identical between the two devices as
they both hang off the same signal amplifier/splitter, so it's not a
signal quality issue.
Denis
ffrr wrote:
Phill Edwards wrote:
It's October and I still have this same problem (been with me since
version 0.17).
From my experience, it's more often a playback problem. If I use
mythlink.sh to create mpeg links, I can play the video in winamp under
winxp and it works. This is a major hand-brake to having my partner
enjoy using Mythtv. I record a heap of shows for her, but 20% of them
lose audio at some point. Some of them, you can hit space bar to set a
bookmark, watch something else for a few seconds, switch back and it
works. For most of them, the Myth box won't ever play audio.
I'm very surprised (and dissapointed) that this hasn't been fixed
yet as
it's literally a show stopper for me.
I would guess that this is a symptom of recording in PS mode instead
of TS mode. This has also been covered loads of times on this list so
I'm very surprised you haven't come across it.
Regards,
Phill
_
I struck this problem at one point (temporarily cured by hitting the +
key to switch audio tracks), and was told that it was PS vs TS causing
the problem. However, switching to TS did not make any difference.
Luckily for me, it went away when I rebuilt my box - probably because
the rpms I used the second time are a later build.
Just wanted to say that, although many people may think the answer has
been found and that it is purely the choice of PS as a recording
format, it ain't necessarily so....
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
