On 12-12-02 02:50 PM, Brian J. Murrell wrote:
Was this information helpful? If not, please let me know what else I
can provide to give you something you can diagnose with.
Here's something interesting...
When a tuner/encoder is blocking reads, the following is printed to the
kernel log
On 12-11-29 02:47 PM, Brian J. Murrell wrote:
I'm afraid I didn't notice the problem until about 40m into the
recording bug given that MythTV is in a loop repeatedly opening the
card and trying to use it perhaps the high volume even 40 minutes into
the recording is useful.
Then once you
On 12-11-29 10:29 AM, Ezequiel Garcia wrote:
Hi Brian,
Hi Garcia,
Mmm, the log shows this repeating pattern:
---
Nov 28 17:54:46 cmurrell kernel: [878779.229702] ivtv0: info: Setup
VBI start 0x002fea04 frames 4 fpi 1
Nov 28 17:54:46 cmurrell kernel: [878779.233129] ivtv0: info: PGM
On 12-11-29 10:50 AM, Andy Walls wrote:
Hi Ezequiel,
Nope. IIRC, that's just MythTV timing-out, closing the device node, and
reopening the device node, in attempt to make things work again.
Seems a very reasonable explanation.
Hi Brian,
Hi Andy,
I haven't checked the log you provided
On 12-11-29 10:50 AM, Andy Walls wrote:
until the problem appears.
I'm afraid I didn't notice the problem until about 40m into the
recording bug given that MythTV is in a loop repeatedly opening the
card and trying to use it perhaps the high volume even 40 minutes into
the recording is useful.
On 12-11-28 08:08 AM, Ezequiel Garcia wrote:
Can you post a dmesg output when this happens?
Unfortunately, there is nothing at all in dmesg when this happens.
b.
signature.asc
Description: OpenPGP digital signature
On 12-11-28 08:13 AM, Ezequiel Garcia wrote:
Try again with
modprobe ivtv ivtv_debug=10
That actually errored out but I think you meant:
# modprobe ivtv debug=10
which actually was successful in loading the module. Now we just wait
for the failure and see.
I will update here as soon as I
On 12-11-28 08:13 AM, Ezequiel Garcia wrote:
Try again with
modprobe ivtv ivtv_debug=10
OK. Happened again. The kernel log for the whole day since starting
the module with debug this morning can be found at
http://brian.interlinx.bc.ca/ivtv-dmesg.txt.bz2.
Associated with that log there was
I wonder if anyone here has control over or knows anyone who has control
over the ivtvdriver.org website and lists.
They seem to be down and have been for a bit now.
Does anyone know if there is any expectation that this stuff will come
back or is headed for moribund-land?
Cheers,
b.
I have a machine with a PVR-150 and a PVR-500 in it on a
3.2.0-33-generic (Ubuntu kernel, based on 3.2.1 IIUC) kernel.
I am having problems where at random times random /dev/video[0,1,2]
inputs will just block on read. It's not the same input every time and
it's not even the same card every
On 12-11-22 07:33 AM, Brian J. Murrell wrote:
I have a PVR-500 in a machine here where one of the /dev/video* devices
can successfully be opened and return data while the other can be
opened but returns to data to a read(2). i.e.:
open(/dev/video3, O_RDONLY|O_LARGEFILE) = 3
dup3(3, 0, 0
I have a PVR-500 in a machine here where one of the /dev/video* devices
can successfully be opened and return data while the other can be
opened but returns to data to a read(2). i.e.:
open(/dev/video3, O_RDONLY|O_LARGEFILE) = 3
dup3(3, 0, 0) = 0
close(3)
Hi,
As I wrote about a number (3-4) of weeks ago, I am still having a
problem with my HVR-1600 failing on multiple digital recordings. At the
time I reported this previously, there was a question of whether my
current version of MythTV was to blame.
To that end, I updated my MythTV to the
I have a fairly new HVR-1600 which I have seen fail quite a number of
times now when it's asked to record more than one channel on a clearqam
multiplex. This time it was 3 recordings at once.
There's nothing at all in the kernel ring buffer, just mythtv reports a
failed recording. Usually one
On 12-10-04 10:18 AM, Devin Heitmueller wrote:
I think the real question at this point is: what version of MythTV are
you running?
0.25-fixes, specifically 46cab93 from 20120801. Indeed, not the latest,
but I don't think much if anything has been done in the affected code
paths. I want to
I have a fairly new HVR-1600 which I have seen fail quite a number of
times now when it's asked to record more than one channel on a clearqam
multiplex. This time it was 3 recordings at once.
There's nothing at all in the kernel ring buffer, just mythtv reports a
failed recording. Usually one
On 12-06-03 05:01 PM, Antti Palosaari wrote:
That firmware downloading patch is done top of my new dvb-usb
development tree. I have converted very limited set of drivers for that
tree, af9015, au6610, ec168 and anysee (and those are only on my local
hard disk). I tried to backport patch for
On 12-06-04 09:35 AM, Devin Heitmueller wrote:
The 950q doesn't use the dvb-usb framework (nor does it load the
firmware at init). Whatever is going on there is completely unrelated
to what Antti is debugging.
Ahhh. Pity. I was almost giddy there for a second. :-/
Cheers,
b.
On 12-06-02 10:44 PM, Antti Palosaari wrote:
That solves DVB USB firmware loading problems.
As in you have a patch that works or it's just solved in theory. If
you have a patch I'd love to apply it here and get this machine
suspendable again.
Cheers,
b.
signature.asc
Description: OpenPGP
When using gnutv with -out stdout it doesn't exit when it's reader
quits (i.e. and it gets an EPIPE/SIGPIPE).
Signed-off-by: Brian J. Murrell br...@interlinx.bc.ca
---
--- linuxtv-dvb-apps-1.1.1+rev1273~/util/gnutv/gnutv_data.c 2011-11-28
09:10:33.010407011 -0500
+++ linuxtv-dvb-apps-1.1.1
On 12-05-03 10:48 AM, Devin Heitmueller wrote:
I doubt this is a dvb-usb problem, but rather something specific to
the realtek parts (suspend/resume does work with other devices that
rely on dvb-usb).
Dunno if it's at all relevant but I used to be able (circa 2.6.32
perhaps? it's a bit
On 12-05-03 11:37 AM, Andy Walls wrote:
Devin Heitmueller dheitmuel...@kernellabs.com wrote:
Also, which version of the HVR-1600 is this? The one with the
mxl5005s or the tda18271? You can check the dmesg output to tell (and
if you cannot tell, please pastebin the dmesg output so I can
On 12-04-29 08:09 PM, Devin Heitmueller wrote:
I don't know why you're not seeing valid data on femon with the 950q.
It should be printing out fine, and it's on the same 0.1 dB scale.
Try running just azap and see if the SNR is reported there.
$ azap -c ~/last-channel-scan.prev 100-3
using
So reading
http://linuxtv.org/wiki/index.php/KWorld_UB435-Q_USB_ATSC_TV_Stick it's
clear that just going out and buying one is a crapshoot.
I wonder if anyone has figured out how to determine, from the packaging
if one has the supported model or the unsupported model.
Cheers,
b.
signature.asc
On 12-04-19 08:08 AM, Brian J. Murrell wrote:
I have an HVR-950Q:
[44847.234403] tveeprom 0-0050: Hauppauge model 72001, rev B3F0, serial#
***
[44847.294643] tveeprom 0-0050: MAC address is **:**:**:**:**:**
[44847.343417] tveeprom 0-0050: tuner model is Xceive XC5000 (idx 150, type
On 12-04-29 03:02 AM, Rudy Zijlstra wrote:
Brian,
Hi Rudy,
There is no minimum cable length for RF. Although for practical reasons
i rarely go below 30 cm (1 ').
Indeed. Especially with RG6 they can get a bit stiff.
It should be possible for you to buy drop cables which have a length
of
On 12-04-28 10:56 AM, Andy Walls wrote:
grepping out the 0 lines doesn't let one see the trends in Signal to
Noise Ratio (SNR) before and after the uncorrectable (unc) block counts.
OK. I have completely reworked the way I use femon. I now start/stop
femon along with recordings so I should
One more question...
On 12-04-28 10:56 AM, Andy Walls wrote:
So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you
have problems. For 256-QAM cable signals, I think that is considered
marginal.
I've never gotten my mind around SNRs and dBs, etc. Generally speaking,
am I
On 12-04-28 02:36 PM, Brian J. Murrell wrote:
One more question...
And to answer my own question, and provide some more data...
I've never gotten my mind around SNRs and dBs, etc. Generally speaking,
am I looking for these snr values to go up or down (i.e. closer to 0
or further away
On 12-04-28 04:39 PM, Brian J. Murrell wrote:
I typically have one more splitter downstream from that 3 way splitter
which is a 4 way splitter to feed all of the tuners on my Mythtv box and
introducing that splitter reduces the SNR at the HVR-1600 to between
13c and 13e (31.6 - 31.8 dB
Hi,
I have two DVB devices in my machine that I want to be able to identify
persistently[1]. They are typically on /dev/dvb/adapter{0,1}/frontend0
but their order is arbitrary and can change from one boot to another.
So using udevadm info I tried to find attributes for them that I could
rely on
On 12-04-24 07:26 PM, Andy Walls wrote:
Maybe by using matches on DEVPATH and/or DEVNAME along with the other
attributes you already check?
...
KERNEL[1335308536.258048] add
/devices/pci:00/:00:14.4/:03:00.0/dvb/dvb0.frontend0 (dvb)
UDEV_LOG=3
ACTION=add
On 12-04-24 06:42 PM, Andy Walls wrote:
Signal level varaition coupled with the HVR-1600's, at times, mediocre
digital tuning side:
Ahh. Pity.
Run 'femon' on the cx18's dvb frontend when you have a live QAM capture
ongoing.
OK. Ran it all evening during the evening capture window.
On 12-04-22 04:56 PM, Andy Walls wrote:
If, in your system, IRQ service for device A under some circumstances
has precendence over IRQ service for the CX23418 and hence holds off its
service; and the irq handler in the driver for device A decides to
perform some some long I/O operations with
I've got an HVR-1600 in a fairly fast machine (P4 3GHz, two cores) on a
3.2.0 kernel and seem to be getting lots of this sort of thing:
Apr 19 20:09:10 pvr kernel: [34651.015170] cx18-0: Skipped encoder MPEG, MDL
63, 62 times - it must have dropped out of rotation
Apr 19 20:10:05 pvr kernel:
I was recording 3 programs last night using Mythtv (0.25) with my
HVR-950Q. All three recordings stopped dead after Mythtv reported:
Apr 18 20:32:04 pvr mythbackend[1857]: E DVBRead mpeg/mpegstreamdata.cpp:362
(AssemblePSIP) Error: offset181, pes length current cannot be queried
It also later
I have an HVR-950Q:
[44847.234403] tveeprom 0-0050: Hauppauge model 72001, rev B3F0, serial# ***
[44847.294643] tveeprom 0-0050: MAC address is **:**:**:**:**:**
[44847.343417] tveeprom 0-0050: tuner model is Xceive XC5000 (idx 150, type 76)
[44847.402873] tveeprom 0-0050: TV standards
On 11-11-25 08:36 AM, Brian J. Murrell wrote:
Yes, that is the other way to skin that cat I suppose.
I couldn't figure out what the right thing for writer thread to do to
terminate the application so I used SIGPIPE instead. Here's the patch:
--- linuxtv-dvb-apps-1.1.1+rev1273~/util/gnutv
Currently, (at least in rev. 1355) gnutv is ignoring SIGPIPE:
signal(SIGPIPE, SIG_IGN);
This means though that if it is used as such:
gnutv -out stdout -channels /home/mythtv/channels.conf.found 91-472 |
mplayer -
It will not terminate as it should when/if it's consumer (mplayer in
the
On 11-11-25 08:34 AM, Rémi Denis-Courmont wrote:
Anyway, the problem is not so mucgh ignoring SIGPIPE as ignoring EPIPE write
errors.
Yes, that is the other way to skin that cat I suppose.
What's the best/proper way to go about getting this fixed?
Cheers,
b.
signature.asc
Description:
Hi.
Using dvb-apps 1.1.1+rev1355-1ubuntu1 on Ubuntu, I'm scanning my qam
channels with scan on both an Hauppage HVR-950q and HVR-1600 and the
resulting output contains channels which I know are both audio and video
yet the VID field of the output is 0. i.e.
120:58500:QAM_256:0:5842:11
On 11-11-17 04:58 PM, Devin Heitmueller wrote:
I'm not sure about the ones that don't have a VID, but the ones that
have a VID which aren't viewable are probably because they're
encrypted.
Fair enough.
The /usr/bin/scan tool will return channels in the list
regardless of whether they can
Hi,
I was looking at the wiki for the supported status of the AVerMedia
AVerTV Hybrid Volar MAX (H826). The wiki says it's not supported. But
the wiki also says it's a PCIe card, which it's clearly not:
http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431
Additionally in the
On Mon, 2010-08-23 at 07:19 -0400, Devin Heitmueller wrote:
Hi Brian,
Hi Devin,
What command are you using to control the frontend? If it's azap,
did you remember to specify the -r argument?
Uh-oh. Here comes a grand display of my ignorance for the manual
workings of this device. :-/
Hi,
I have an HVR 950Q on my Ubuntu 2.6.32 kernel. I have in fact tried
several kernel versions on a couple of different machines with the same
behaviour.
What seems to be happening is that /dev/dvb/adapter0/dvr0 can be opened:
open(/dev/dvb/adapter0/dvr0, O_RDONLY|O_LARGEFILE) = 0
but a read
[ resend due to subscription complications. apologies if this winds up
becoming a duplicate. ]
Hi there.
I have a Hauppauge HVR 950Q. I am mostly successful with it, but lately
I have
been seeing a lot of these:
usb 1-4: new high speed USB device using ehci_hcd and address 9
usb 1-4:
46 matches
Mail list logo
