Re: ivtv driver inputs randomly block
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: [1451927.797336] ivtv1: file: open encoder MPG [1451927.797344] ivtv1: mb: MB Call: CX2341X_ENC_PING_FW [1451927.797413] ivtv1: mb: MB Call: CX2341X_ENC_MISC [1451927.797513] ivtv1 encoder MPG: unknown ioctl 'T', dir=--, #1 (0x5401) error -22 [1451927.797531] ivtv1: info: Start encoder stream encoder MPG [1451927.797535] ivtv1: mb: MB Call: CX2341X_ENC_SET_DMA_BLOCK_SIZE [1451927.797539] ivtv1: mb: MB Call: CX2341X_ENC_SET_VERT_CROP_LINE [1451927.797609] ivtv1: mb: MB Call: CX2341X_ENC_MISC [1451927.797679] ivtv1: mb: MB Call: CX2341X_ENC_MISC [1451927.797752] ivtv1: mb: MB Call: CX2341X_ENC_MISC [1451927.797831] ivtv1: mb: MB Call: CX2341X_ENC_MISC [1451927.797904] ivtv1: mb: MB Call: CX2341X_ENC_SET_PLACEHOLDER [1451927.797907] ivtv1: mb: MB Call: CX2341X_ENC_SET_NUM_VSYNC_LINES [1451927.797911] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821351] ivtv1: info: Setup VBI API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456 [1451927.821358] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_CONFIG [1451927.821439] ivtv1: info: Setup VBI start 0x002fea04 frames 4 fpi 1 [1451927.821442] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821519] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821595] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821673] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821750] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821828] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821905] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.821980] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822056] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822135] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822211] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822289] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822367] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822443] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822519] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822594] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822672] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822749] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822827] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822902] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.822979] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823057] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823134] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823211] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823287] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823363] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823438] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823516] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823593] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823670] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823747] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823826] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823902] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.823979] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824095] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824174] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824248] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824324] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824400] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824478] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824554] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824629] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824706] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824782] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824857] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.824934] ivtv1: mb: MB Call: CX2341X_ENC_SET_VBI_LINE [1451927.825009] ivtv1: mb: MB Call: CX2341X_ENC_SET_PGM_INDEX_INFO [1451927.825079] ivtv1: info: PGM Index at 0x00180150 with 400 elements [1451927.825082] ivtv1: mb: MB Call: CX2341X_ENC_SET_OUTPUT_PORT [1451927.825086] ivtv1: mb: MB Call: CX2341X_ENC_SET_FRAME_RATE [1451927.832028] ivtv1: mb: MB Call: CX2341X_ENC_SET_FRAME_SIZE [1451927.832042] ivtv1: mb: MB Call: CX2341X_ENC_SET_STREAM_TYPE [1451927.832046] ivtv1: mb: MB Call: CX2341X_ENC_SET_BIT_RATE [1451927.832051] ivtv1: mb: MB Call: CX2341X_ENC_SET_AUDIO_PROPERTIES [1451927.832055] ivtv1: mb: MB Call: CX2341X_ENC_MUTE_AUDIO [1451927.832130] ivtv1: mb: MB Call: CX2341X_ENC_SET_ASPECT_RATIO [1451927.832144] ivtv1: mb: MB
Re: ivtv driver inputs randomly block
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 experience the problem change it to high volume # echo 0x47f /sys/module/ivtv/parameters/debug It seems to be a loop of: ... Was this information helpful? If not, please let me know what else I can provide to give you something you can diagnose with. Cheers and much thanks, b. signature.asc Description: OpenPGP digital signature
Re: ivtv driver inputs randomly block
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 Index at 0x00180150 with 400 elements Nov 28 17:54:47 cmurrell kernel: [878779.556039] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 17:54:49 cmurrell kernel: [878782.059204] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 17:54:49 cmurrell kernel: [878782.059209] ivtv0: info: close stopping capture Nov 28 17:54:49 cmurrell kernel: [878782.059214] ivtv0: info: Stop Capture Nov 28 17:54:51 cmurrell kernel: [878784.156135] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 17:54:51 cmurrell kernel: [878784.166157] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 17:54:51 cmurrell kernel: [878784.166165] ivtv0: info: Start encoder stream encoder MPG Yes, as I indicated. And from 15:00 to 18:00 recording fails? Yes. Perhaps it would make sense to restart application upon driver failure, now that output is more verbose. Meaning what exactly? Restart MythTV? How would I restart MythTV when the failure occurs? Do you mean like having a daemon watching dmesg that restarts MythTV when this happens? That's a very ugly hack-around that will have negative side effects per below... This failure doesn't necessarily affect all tuners at the same time so I would potentially be restarting MythTV while other tuners are recording, interrupting good recordings to fix one tuner which is having a problem. I am sure you would agree that this is not really a suitable work-around, yes? PS: Please don't drop linux-media list from Cc I don't think I did. All of my messages have been copied to the list, albeit I post them through gmane rather than posting to the list directly since I read via gmane and am not a direct subscriber to the list. Most lists will disallow postings by non-subscribers. I know vger.kernel.org does allow posting by non-subscribers on at least some of their lists but I am not aware of it being a site-wide policy or not so to be on the safe side I just let gmane post it to the list. Perhaps you got the copy I CC'd to you directly before you got the copy that went to the list via gmane. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: ivtv driver inputs randomly block
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 yet, but you'll likely need to set the module debug flags a little more verbose. OK. /sbin/modinfo ivtv | less [...] parm: debug:Debug level (bitmask). Default: 0 1/0x0001: warning 2/0x0002: info 4/0x0004: mailbox 8/0x0008: ioctl 16/0x0010: file 32/0x0020: dma 64/0x0040: irq 128/0x0080: decoder 256/0x0100: yuv 512/0x0200: i2c 1024/0x0400: high volume [..] So maybe as root # echo 0x07f /sys/module/ivtv/parameters/debug until the problem appears. Then once you experience the problem change it to high volume Will waiting for MythTV to report an error, such as: MPEGRec(/dev/video1): Device error detected be too late to turn up debugging or should that be sufficient enough timing? Although, MythTV seems to report that error at the end of every recording so I'm not sure how I will filter out the false reports -- unless I write a smarter (i.e. than a single line match) log watcher. Anyway, that's my problem, not yours. :-) # echo 0x47f /sys/module/ivtv/parameters/debug You may want to also get a baseline of what a good capture looks like using high volume debugging. Just did that. Reduced to 0x07f after about a minute and 23 seconds. Be aware that high volume debugging will fill up your logs and degrade performance a little, so you don't want to normally use high volume debugging. Indeed, it's quite verbose. +1 The ideas or interest of one individual often spurs that of others. Indeed, I always keep list replies on list and as I mentioned to Ezequiel (sorry Ezequiel, I got your name wrong on my previous post. my apologies) and I am seeing the copies -- but through gmane. I don't see the copies on the spincs.net archive. I suspect there is a lag at gmane posting to the list. In any case, I have CC'd this one directly to the list @vger.kernel.org and will just hope it has an open posting policy. Cheers and thanks much! b. signature.asc Description: OpenPGP digital signature
Re: ivtv driver inputs randomly block
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. Then once you experience the problem change it to high volume # echo 0x47f /sys/module/ivtv/parameters/debug It seems to be a loop of: Nov 29 14:39:47 cmurrell kernel: [953479.593771] ivtv0: file: Encoder poll Nov 29 14:39:47 cmurrell kernel: [953479.594127] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 29 14:39:47 cmurrell kernel: [953479.594131] ivtv0: file: close() of encoder MPG Nov 29 14:39:47 cmurrell kernel: [953479.594134] ivtv0: info: close stopping capture Nov 29 14:39:47 cmurrell kernel: [953479.594137] ivtv0: info: Stop Capture Nov 29 14:39:47 cmurrell kernel: [953479.594142] ivtv0: mb: MB Call: CX2341X_ENC_STOP_CAPTURE Nov 29 14:39:49 cmurrell kernel: [953481.592013] ivtv0: warn: encoder MPG: EOS interrupt not received! stopping anyway. Nov 29 14:39:49 cmurrell kernel: [953481.592021] ivtv0: warn: encoder MPG: waited 2000 ms. Nov 29 14:39:49 cmurrell kernel: [953481.692036] ivtv0: mb: MB Call: CX2341X_ENC_STOP_CAPTURE Nov 29 14:39:49 cmurrell kernel: [953481.692138] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 29 14:39:49 cmurrell kernel: [953481.692161] ivtv0: file: close encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692165] ivtv0: file: close() of encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692208] ivtv0: file: open encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692211] ivtv0: mb: MB Call: CX2341X_ENC_PING_FW Nov 29 14:39:49 cmurrell kernel: [953481.692272] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692348] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 29 14:39:49 cmurrell kernel: [953481.692352] ivtv0: info: Start encoder stream encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692356] ivtv0: mb: MB Call: CX2341X_ENC_SET_DMA_BLOCK_SIZE Nov 29 14:39:49 cmurrell kernel: [953481.692359] ivtv0: mb: MB Call: CX2341X_ENC_SET_VERT_CROP_LINE Nov 29 14:39:49 cmurrell kernel: [953481.692422] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692485] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692553] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692617] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692684] ivtv0: mb: MB Call: CX2341X_ENC_SET_PLACEHOLDER Nov 29 14:39:49 cmurrell kernel: [953481.692688] ivtv0: mb: MB Call: CX2341X_ENC_SET_NUM_VSYNC_LINES Nov 29 14:39:49 cmurrell kernel: [953481.692691] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.718739] ivtv0: info: Setup VBI API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456 Nov 29 14:39:49 cmurrell kernel: [953481.718746] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_CONFIG Nov 29 14:39:49 cmurrell kernel: [953481.718830] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 29 14:39:49 cmurrell kernel: [953481.718834] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.718906] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.718978] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719052] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719126] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719196] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719269] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719352] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719445] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719522] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719592] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719662] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719732] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719807] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719893] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719967] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.720060] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.720144] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.720213] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49
Re: ivtv driver inputs randomly block
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
Re: ivtv driver inputs randomly block
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 see it again. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: ivtv driver inputs randomly block
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 a successful recording from 09:00:00 until 10:00:00 then another successful recording from 14:00:00 until 15:00:00 and then failed recordings starting at 15:00:00 until 18:00:00. The log cuts off just short of 18:00:00 but there's nothing different about the pattern from the end of the log until 18:00:04 from the previous 3 hours or so. It seems that the problem lies in amongst the start of these lines from the log, as my best guess: Nov 28 15:00:05 cmurrell kernel: [868297.536049] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 15:00:07 cmurrell kernel: [868300.039324] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 15:00:07 cmurrell kernel: [868300.039330] ivtv0: info: close stopping capture Nov 28 15:00:07 cmurrell kernel: [868300.039334] ivtv0: info: Stop Capture Nov 28 15:00:09 cmurrell kernel: [868302.140151] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 15:00:09 cmurrell kernel: [868302.148093] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 15:00:09 cmurrell kernel: [868302.148101] ivtv0: info: Start encoder stream encoder MPG Nov 28 15:00:09 cmurrell kernel: [868302.188580] ivtv0: info: Setup VBI API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456 Nov 28 15:00:09 cmurrell kernel: [868302.188655] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 28 15:00:09 cmurrell kernel: [868302.191952] ivtv0: info: PGM Index at 0x00180150 with 400 elements Nov 28 15:00:10 cmurrell kernel: [868302.544052] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 15:00:12 cmurrell kernel: [868305.047260] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 15:00:12 cmurrell kernel: [868305.047265] ivtv0: info: close stopping capture Nov 28 15:00:12 cmurrell kernel: [868305.047270] ivtv0: info: Stop Capture ... FWIW, the recording software here is MythTV completely up to date on the 0.25-fixes branch. Thoughts? b. signature.asc Description: OpenPGP digital signature
anyone here know anyone at ivtvdriver.org? it's been down a few days now
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. signature.asc Description: OpenPGP digital signature
ivtv driver inputs randomly block
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 time. This is all hardware which has worked without any such problems before. To remedy the hanging input I simply have to rmmod ivtv modprobe ivtv and all is back to normal again, until it happens again. Any ideas? b. signature.asc Description: OpenPGP digital signature
Re: one tuner of a PVR-500 not returning any data
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) = 0
close(3)= 0
fstat64(0, {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 11), ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc7f568) = -1 EINVAL (Invalid
argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7423000
read(0,
and the process blocks there.
FWIW, simply rmoving and inserting the ivtv module seems to have fixed this.
But really odd (to me at least) that it's just one tuner of a dual-tuner
card. So like 1 piece of hardware, with only 1 submodule not working.
b.
signature.asc
Description: OpenPGP digital signature
one tuner of a PVR-500 not returning any data
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)= 0
fstat64(0, {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 11), ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc7f568) = -1 EINVAL (Invalid
argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7423000
read(0,
and the process blocks there.
Any idea why this might be happening? Kernel is 3.2.0-33-generic which
I believe is 3.2.1 based.
b.
signature.asc
Description: OpenPGP digital signature
hvr-1600 records one, fails recording the other on an mplex
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 latest (at the time) on the 0.25-fixes branch. I also, at the same time, switched my primary digital tuner to my HVR-950Q. I ran in that configuration for a couple of weeks without a single failed recording. A week ago, I switched back to having my HVR-1600 as the primary device to determine if it was the HVR-950Q switch or the MythTV update that gave me such success and sure enough, on a particularly busy evening of recording (but no busier than the same evening the prior two weeks where the HVR-950Q worked flawlessly) one recording on a given multiplex failed while another on the same multiplex, at the same time, was successful. Unsurprisingly femon reported FE_HAS_LOCK for the entire time period of the failed recording. I say unsurprisingly because as I mentioned prior, another recording on the HVR-1600 at the same time was successful. Additionally, many, many times during the last week more than one recording on a given multiplex on this HVR-1600 worked so this problem is most definitely intermittent, but my experience for the last 3-4 weeks I think proves that it's a problem with the HVR-1600 and not MythTV given that it's something that happens only with the HVR-1600 and not with the HVR-950Q. Unfortunately, there was nothing on the kernel log at the time of the failed recording. How can I gather further information on what might be going on which is causing this failure? b. signature.asc Description: OpenPGP digital signature
hvr-1600 fails frequently on multiple recordings
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 of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes. I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a: 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder or a: :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) Sorry. I don't recall which is which any more. But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it. Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out. Any ideas? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: hvr-1600 fails frequently on multiple recordings
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 upgrade and even thought about doing it today but today I also moved the HVR-1600 into secondary duty (and promoted the HVR-950Q) and didn't want to make another change which would only confuse the original cause. I understand that making such a change is not ideal in terms of debugging, but the grief of having a whole night of television recordings fail just causes too much strife here. And most nights it wouldn't really matter but of course it has to happen on the one night of the week that people here have to watch a show the same night it's broadcast or else hear about all of the spoilers at work the next day. :-( I've seen so many reports recently of breakage in the MythTV codebase related to recording, I am almost inclined to demand you reproduce it outside of MythTV before we even spend any time talking about it. That's fair enough I suppose. The one problem is that this problem is very intermittent. It only happens about once a week or so, not really at the same time every week though so not nearly repeatable. Is there much more to recording from these devices though than: # [ tune channel ] # cat $device $file akin to recording from PVR-x50s? I guess what I'm driving at is how much/little code are we talking about in Mythtv to do this? Also, has anything changed in your environment? Nothing other than the HVR-1600 being somewhat new. It has not really been worked hard since I got it given that I got it in the low season. Now that fall is here there is lots more on television and the card is being asked to perform multiplexed recordings way more frequently. Was it working before, Yes, but has always been on light duty since I got it. and then you upgraded the kernel or Myth, and now it's not working? Nope. No upgrades correlating. Or has there been a consistent pattern of failure over some extended period of time? Well, it's happened now 2-3 times since the start of the fall season, which means when it's being asked to do more. The cx18 driver has changed very little as of late - the MythTV codebase has changed heavily and people are all over the place complaining about breakage. Which does seem like a fair correlation. The only other possibility I am considering is a defective card since it's never really proven itself yet. I'm not trying to get into the finger-pointing game, No, I completely understand your perspective and these are all very fair questions. I hope you will allow me to be devil's advocate in hopes of getting to the bottom of it. :-) but I just want to better understand the history/background before I can make any recommendations. Indeed. Always a good idea. There's a reason doctors take patient histories before diagnosing. :-) FWIW, I'd be happy to take this over to the mythtv list if you want to pursue it being a mythtv problem. I filed a bug about mythtv's inability to recover from this situation and it deadlocking until killed (a KILL signal is typically required, demonstrating how badly mythtv is handling this situation) when this happens and even posted to the list about the bug but got zero response. Cheers, b. signature.asc Description: OpenPGP digital signature
hvr-1600 fails frequently on multiple recordings
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 of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes. I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a: 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder or a: :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) Sorry. I don't recall which is which any more. But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it. Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out. Any ideas? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()
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 the current dvb-usb but I ran many problems and gave up. Looks like it is almost impossible to convert old dvb-usb without big changes... So what driver you are using? I'm using the hvr-950q per https://bugzilla.kernel.org/show_bug.cgi?id=43145 and https://bugzilla.kernel.org/show_bug.cgi?id=43146. It is possible I can convert your driver too and then it is possible to test. Great. Ideally it would be great to get this backported and applied to the linux 3.2.0 release stream. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()
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. signature.asc Description: OpenPGP digital signature
Re: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()
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 digital signature
[PATCH 1/1] gnutv: exit on EPIPE/SIGPIPE
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+rev1273/util/gnutv/gnutv_data.c 2011-11-28
09:10:26.446258282 -0500
@@ -265,7 +265,10 @@
while(written size) {
int tmp = write(outfd, buf + written, size - written);
if (tmp == -1) {
- if (errno != EINTR) {
+ if (errno == EPIPE) {
+ fprintf(stderr, processing EPIPE\n);
+ return 0;
+ } else if (errno != EINTR) {
fprintf(stderr, Write error: %m\n);
break;
}
--- linuxtv-dvb-apps-1.1.1+rev1273~/util/gnutv/gnutv.c 2011-11-28
10:13:13.294445131 -0500
+++ linuxtv-dvb-apps-1.1.1+rev1273/util/gnutv/gnutv.c.new 2011-11-28
10:13:10.510492321 -0500
@@ -262,7 +262,7 @@
// setup any signals
signal(SIGINT, signal_handler);
- signal(SIGPIPE, SIG_IGN);
+ signal(SIGPIPE, signal_handler);
// start the CA stuff
gnutv_ca_params.adapter_id = adapter_id;
signature.asc
Description: OpenPGP digital signature
Re: common DVB USB issues we has currently
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 foggy now) to suspend/resume with my HVR-950q installed and modules loaded. Now suspending with them loaded hangs the suspend and they can't even reliably be rmmod/modprobed pre and post suspend/resume. I just wonder if that change in behavior is pointing at something. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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 look). http://brian.interlinx.bc.ca/hvr-1600-dmesg IIRC, Brian had a MXL5005s/S5H1409 variant. The latter part sounds familiar from femon and gnutv. I think Brian might have a bad cable or connector or splitter in the run feeding the hvr1600. The same 4-way splitter fed the HVR-950Q and the HVR-1600 and cables were swapped just about every way they could be to try to get the HVR-1600's SNR up. But as I mentioned before, it's now completely non-functional due to the coax connector on the card having become loose enough to turn (with some effort, so screwing an female F-connector on/off was still quite doable). Perhaps it was marginal before due to that same problem. I guess I will never know... unless I try cracking this thing open and reconnecting whatever has gotten disconnected -- if Hauppage won't RMA it for me. They seem to be pretty silent about that now though after an initial e-mail exchange. If not, I've got my eye on a KWorld UB435-Q if I can determine that it's a hardware rev. 1 unit somehow since the store doesn't want to take it out of the box to check for me. It's less than half the price of an HVR-950Q at $40, as much as I would love to stay loyal with Hauppage -- this coax connector on my HVR-1600 coming loose, aside. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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 '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 65100 Hz video pid 0x, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK ... Doesn't seem to be useful values. This indeed feels like a marginal signal condition problem, and Andy's assertion is well founded that the mxl5005/s5h1409 isn't exactly the best combo compared to more modern tuners and demodulators (Hauppauge switched to the tda18271 and s5h1411 for the newer revision of the HVR-1600). Well, now that the coax connector has come loose on the digital tuner (i.e. it spins albeit with enough friction that screwing a coax connector on and off is still quite doable but it would seem spins enough to have broken the connection internally and thus the tuner no longer receives signal) maybe it's time to cut my losses here and just consider this HVR-1600 garbage. I've wasted more than enough time on what's turned out to just be marginal hardware. ~sigh~ I wonder if I can still find the supported hardware rev. of the KWorld UB-435 around anywhere. The local computer store has one for $40 but they have no way of telling me if it's the new hardware rev. or the old one. Cheers, b. signature.asc Description: OpenPGP digital signature
kworld ub435 -- how to identify the unsupported one by packaging
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 Description: OpenPGP digital signature
Re: can't rmmod au0828; modprobe au0828 and have a working device
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 76) [44847.402873] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [44847.465471] tveeprom 0-0050: audio processor is AU8522 (idx 44) [44847.515481] tveeprom 0-0050: decoder processor is AU8522 (idx 42) [44847.567162] tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter [44847.630272] hauppauge_eeprom: hauppauge eeprom: model=72001 I cannot seem to get it to work after removing the au0828 xc5000 au8522 modules and then modprobing the au0828 module. To follow-up on this, it seems that if I remove and insert the au0828 enough times, it will be functional again. Race perhaps? It seems when it's inserted and doesn't work, the following is logged in the kernel message buffer: xc5000: Device not found at addr 0x61 (0x) and when it's inserted successfully: xc5000: Successfully identified at address 0x61 xc5000: Firmware has not been loaded previously It also seems that the module will become non-functional just as if I had removed and inserted it, all on it's own without any removal insertion. b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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 1m5 (about 5') and are commonly used in HE to connect equipment. Yeah, I'm trying to reduce the cable nest and I only have about 6 between the back of the equipment and the wall, where the splitter will be so 1' cables will probably do the trick. screw-on F-connectors are another source of problems. Yes. Crimping F-connectors are best, but those need a fitting crimp tool. Indeed, and I have one. :-) Thanks for the info! b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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 have a separate femon output for each recording (using Mythtv system events and a couple of recording start/stop scripts, fwiw). 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. OK. Good to know. (Can someone else with 256-QAM North American cable please confirm? I only have OTA) Would be great if somebody can. Thanks in advance. When you have no errors, what is the SNR? I'm guessing there are no large swings. From what I recall of the data, no, the SNR was pretty much the same throughout good and bad periods of the recordings. But with my configuration here, we will know for sure soon enough. Hard to tell, given that one of the other digital sub-channels may have been effected and not visible on the channel you were recording. Ahhh. I see. I normally watch DTV live with mplayer, and also have femon open in another window, when performing this sort of test. That's effectively what I am doing with my recordings. When a recording starts, an femon starts and logs. When the recording is done I use mplayer (-nosound -vo null -benchmark, just to make it run as fast as possible) and prune out the per frame counters so that what I am left with is the bits that mplayer complains about in the stream along with the frame count it happened at. The femon output is also included for cross reference. A video or audio glitch, 1 or 2 seconds after a non-zero uncorrectable block count, is usually a good indicator of correlation. That's what I will look for. Well, not the best performer from what I hear. Indeed. I don't have any of these problems with my HVR-950Q. This HVR-1600 was a really good deal though, so I can't totally complain. :-) Speaking of the HVR-950Q, does femon not work with it? I seem to always get zero values across the board trying. But certainly works just fine for many people in many contexts. Yes, and indeed, it works here for the most part even with small glitches some of the time. But some other times, the glitching is bad enough to make a recording more or less useless. OK. There are two ways to go here: 1. We assume your signal is marginal. Take a look here for things to check and fix if needed: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality I will see what I can do with those. As a test, you you might also want to temporarily change your coax wiring setup to reduce the number of splits and connectors before the signal goes into the HVR-1600, and see if things are better. Indeed. That was at the top of my list also, so isolate the rest of the cable plant in here. Every 2-way splitter will drop 3-5 dB of signal. OK. So about splitters. Given that I'm in a house with 4 cable television runs to different rooms, plus a cable modem, plus 4 PVR tuner inputs (so yeah, 9 consumers), what is my best splitter plan/options. Probably ideally I want to split the incoming signal into two, one for the cable modem and one to feed the television consumers. Once I have the feed off to the televisions though, am I best trying to split that into 8, (i.e. equally with an 8-way splitter -- if that's even possible) or would I be better served with some more smaller splits in somewhat of a tree formation? I'm also assuming that all splitters are not of the same quality and that the dollar store ones are likely of inferior quality. But dollar store aside, even amongst reasonable retailers, how can I tell (without having to get all electronics geeky with an oscilliscope and whatnot) what's good and what's bad? Also, splitting 8 ways, am I into amplification/boosting territory or am I likely to just boost noise along with the signal? 2. We assume your signal is too strong, and that it is overdriving the MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227 demodulator. Heh. I wonder if that could be possible given my description above. :-) Your corrective action here would be to attenuate the incoming RF signal with either an inline attenuator, or with additional, properly terminated, splitters. Indeed. Thanks so much for all of the input here. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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 looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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) to make my signal better? Clearly, bigger numbers are better. When I hook my HVR-1600 directly up to the cable connection coming into the house with a 25 foot cable and a barrel connector the SNR goes up to 148 (32.8 dB) so that's my ceiling. I can't leave it hooked up like this for anything more than a few minutes so I can't be sure that's a high enough SNR for me to get perfect recordings every time. If I add one two way splitter to the incoming cable with one feed going off to my cable modem and one to the HVR-1600, the SNR drops to 145 (32.5 dB). But again, I can't really leave it like that for too long. so splitting that leg of the 2-way split 3 more times through a 3 way splitter reduces the SNR at the HVR-1600 to between 142 and 145 (32.2 - 32.5 dB). 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). I have no idea where in these range of values acceptable is though. Given that the HVR-1600 seems to be more sensitive to signal quality that just about anything else in here, I suppose I could feed it more directly from a split closer to the source signal. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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). Interestingly enough, I moved the Myth backend to it's usual home, in the basement, right next to the incoming cable signal and replaced that 25' run that I had going to where it was temporarily with a smaller, say 10' run (of RG-59 so still room for improvement) and my SNR at the HVR-1600, even after all of the splitters is now 015c or 34.8 dB. I'm still going to go replacing all of that RG-59 with shorter, custom made lengths of RG6 cables. I can't go too short when making those can I or would even a 6-12 inch cable be perfectly fine? I'm thinking of the runs between that last 4 way splitter and the tuners in the Myth backend. b. signature.asc Description: OpenPGP digital signature
udev rules for persistent symlinks for adapter?/frontend0 devices
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 consistently. Here is the output from:
# udevadm info --attribute-walk --name /dev/dvb/adapter?/frontend0
First device:
looking at device
'/devices/pci:00/:00:1e.0/:02:09.0/dvb/dvb0.frontend0':
KERNEL==dvb0.frontend0
SUBSYSTEM==dvb
DRIVER==
looking at parent device '/devices/pci:00/:00:1e.0/:02:09.0':
KERNELS==:02:09.0
SUBSYSTEMS==pci
DRIVERS==cx18
ATTRS{vendor}==0x14f1
ATTRS{device}==0x5b7a
ATTRS{subsystem_vendor}==0x0070
ATTRS{subsystem_device}==0x7400
ATTRS{class}==0x04
ATTRS{irq}==21
ATTRS{local_cpus}==ff
ATTRS{local_cpulist}==0-7
ATTRS{dma_mask_bits}==32
ATTRS{consistent_dma_mask_bits}==32
ATTRS{enable}==1
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==
looking at parent device '/devices/pci:00/:00:1e.0':
KERNELS==:00:1e.0
SUBSYSTEMS==pci
DRIVERS==
ATTRS{vendor}==0x8086
ATTRS{device}==0x244e
ATTRS{subsystem_vendor}==0x
ATTRS{subsystem_device}==0x
ATTRS{class}==0x060400
ATTRS{irq}==0
ATTRS{local_cpus}==ff
ATTRS{local_cpulist}==0-7
ATTRS{dma_mask_bits}==32
ATTRS{consistent_dma_mask_bits}==32
ATTRS{enable}==1
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==1
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
And the second device:
looking at device
'/devices/pci:00/:00:1d.7/usb1/1-3/dvb/dvb1.frontend0':
KERNEL==dvb1.frontend0
SUBSYSTEM==dvb
DRIVER==
looking at parent device '/devices/pci:00/:00:1d.7/usb1/1-3':
KERNELS==1-3
SUBSYSTEMS==usb
DRIVERS==usb
ATTRS{configuration}==
ATTRS{bNumInterfaces}== 4
ATTRS{bConfigurationValue}==1
ATTRS{bmAttributes}==80
ATTRS{bMaxPower}==500mA
ATTRS{urbnum}==5941719
ATTRS{idVendor}==2040
ATTRS{idProduct}==7200
ATTRS{bcdDevice}==0005
ATTRS{bDeviceClass}==00
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceProtocol}==00
ATTRS{bNumConfigurations}==1
ATTRS{bMaxPacketSize0}==64
ATTRS{speed}==480
ATTRS{busnum}==1
ATTRS{devnum}==2
ATTRS{devpath}==3
ATTRS{version}== 2.00
ATTRS{maxchild}==0
ATTRS{quirks}==0x0
ATTRS{avoid_reset_quirk}==0
ATTRS{authorized}==1
ATTRS{manufacturer}==Hauppauge
ATTRS{product}==WinTV HVR-950
ATTRS{serial}==*
looking at parent device '/devices/pci:00/:00:1d.7/usb1':
KERNELS==usb1
SUBSYSTEMS==usb
DRIVERS==usb
ATTRS{configuration}==
ATTRS{bNumInterfaces}== 1
ATTRS{bConfigurationValue}==1
ATTRS{bmAttributes}==e0
ATTRS{bMaxPower}== 0mA
ATTRS{urbnum}==52
ATTRS{idVendor}==1d6b
ATTRS{idProduct}==0002
ATTRS{bcdDevice}==0302
ATTRS{bDeviceClass}==09
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceProtocol}==00
ATTRS{bNumConfigurations}==1
ATTRS{bMaxPacketSize0}==64
ATTRS{speed}==480
ATTRS{busnum}==1
ATTRS{devnum}==1
ATTRS{devpath}==0
ATTRS{version}== 2.00
ATTRS{maxchild}==8
ATTRS{quirks}==0x0
ATTRS{avoid_reset_quirk}==0
ATTRS{authorized}==1
ATTRS{manufacturer}==Linux 3.2.0-18-generic ehci_hcd
ATTRS{product}==EHCI Host Controller
ATTRS{serial}==:00:1d.7
ATTRS{authorized_default}==1
looking at parent device '/devices/pci:00/:00:1d.7':
KERNELS==:00:1d.7
SUBSYSTEMS==pci
DRIVERS==ehci_hcd
ATTRS{vendor}==0x8086
ATTRS{device}==0x24dd
ATTRS{subsystem_vendor}==0x1043
ATTRS{subsystem_device}==0x80a6
ATTRS{class}==0x0c0320
ATTRS{irq}==23
ATTRS{local_cpus}==ff
ATTRS{local_cpulist}==0-7
ATTRS{dma_mask_bits}==32
ATTRS{consistent_dma_mask_bits}==32
ATTRS{enable}==1
ATTRS{broken_parity_status}==0
ATTRS{msi_bus}==
ATTRS{companion}==
ATTRS{uframe_periodic_max}==100
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
So I tried rules like:
SUBSYSTEM==dvb, ATTRS{product}==WinTV HVR-950, SYMLINK=dvb_pvr950q
SUBSYSTEM==dvb, DRIVERS==cx18, SYMLINK=dvb_hvr1600
but those ended up symlinking to the net0 device:
lrwxrwxrwx 1 root root 17 Apr 24 12:56 /dev/dvb_hvr1600 - dvb/adapter0/net0
lrwxrwxrwx 1 root root 17 Apr 24 12:56 /dev/dvb_pvr950q - dvb/adapter1/net0
How can I create symlinks to the frontend0 device rather than the
net0 device?
Cheers,
b.
[1] You might wonder why I would care given that they both do
quite the same thing and who cares which one is 0 and which
one is 1. But the reality is that while they might function
the same the HVR-1600 produces streams with glitches in them
(see my other message
Re: udev rules for persistent symlinks for adapter?/frontend0 devices
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
DEVPATH=/devices/pci:00/:00:14.4/:03:00.0/dvb/dvb0.frontend0
Perhaps this is the ultimate in persistence, but unfortunately is also
highly dependent on physical location in the machine (i.e. which PCI
slot even).
SUBSYSTEM=dvb
DEVNAME=dvb/adapter0/frontend0
AFAIU, the adapter0 is not representative of physical device
persistence but is rather dependent on probing order. IOW,
dvb/adapter0/frontend0 will always be the first DVB device found but
won't be a guarantee of which physical device it is. This is what I
currently have with /dev/dvb/adapter{0.1} which is unfortunately
unsuitable since it's so predictable.
I might end up having to bite the bullet and using DEVNAME. :-(
Thanks for the info though, much appreciated,
b.
signature.asc
Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
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. Started it at 20:30, sharp to coincide with the evening's recording from that card also starting at 20:30 sharp. Here's where it found anomalies: $ nl /var/tmp/femon.out | grep -v | ber | unc | So you can see, since femon prints an output line each second, the number on the left is the seconds since 20:30 and we are looking for any line showing a ber or unc that is non-zero: 1 FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) 67 status SCVYL | signal 013a | snr 013a | ber 0198 | unc 0198 | FE_HAS_LOCK 313 status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 457 status SCVYL | signal 013a | snr 013a | ber 026e | unc 026e | FE_HAS_LOCK 802 status SCVYL | signal 013c | snr 013c | ber 0265 | unc 0265 | FE_HAS_LOCK 1093 status SCVYL | signal 013a | snr 013a | ber 014b | unc 014b | FE_HAS_LOCK 1184 status SCVYL | signal 013a | snr 013a | ber 01ca | unc 01ca | FE_HAS_LOCK 1192 status SCVYL | signal 013a | snr 013a | ber 0267 | unc 0267 | FE_HAS_LOCK 1385 status SCVYL | signal 013c | snr 013c | ber 025d | unc 025d | FE_HAS_LOCK 1435 status SCVYL | signal 013c | snr 013c | ber 0268 | unc 0268 | FE_HAS_LOCK 1511 status SCVYL | signal 013c | snr 013c | ber 026c | unc 026c | FE_HAS_LOCK 1657 status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 1693 status SCVYL | signal 013a | snr 013c | ber 026f | unc 026f | FE_HAS_LOCK 1749 status SCVYL | signal 013c | snr 013c | ber 0184 | unc 0184 | FE_HAS_LOCK 1796 status SCVYL | signal 013a | snr 013a | ber 1a8b | unc 1a8b | FE_HAS_LOCK 1814 status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 2028 status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 2081 status SCVYL | signal 013c | snr 013c | ber 023a | unc 023a | FE_HAS_LOCK 2261 status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 2307 status SCVYL | signal 013c | snr 013c | ber 0279 | unc 0279 | FE_HAS_LOCK 2318 status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 2474 status SCVYL | signal 013a | snr 013a | ber 026f | unc 026f | FE_HAS_LOCK 2533 status SCVYL | signal 013c | snr 013c | ber 0098 | unc 0098 | FE_HAS_LOCK 2612 status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 2627 status SCVYL | signal 013c | snr 013c | ber 0108 | unc 0108 | FE_HAS_LOCK 2671 status SCVYL | signal 013c | snr 013c | ber 0196 | unc 0196 | FE_HAS_LOCK 2870 status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 3084 status SCVYL | signal 013c | snr 013c | ber 0274 | unc 0274 | FE_HAS_LOCK 3220 status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 3323 status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 3406 status SCVYL | signal 013c | snr 013c | ber 024f | unc 024f | FE_HAS_LOCK 3433 status SCVYL | signal 013c | snr 013a | ber 022a | unc 022a | FE_HAS_LOCK 3946 status SCVYL | signal 013c | snr 013c | ber 0270 | unc 0270 | FE_HAS_LOCK 4129 status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 4275 status SCVYL | signal 013c | snr 013c | ber 0273 | unc 0273 | FE_HAS_LOCK 4284 status SCVYL | signal 013c | snr 013c | ber 0267 | unc 0267 | FE_HAS_LOCK 4411 status SCVYL | signal 013c | snr 013c | ber 0270 | unc 0270 | FE_HAS_LOCK 4718 status SCVYL | signal 013c | snr 013c | ber 0204 | unc 0204 | FE_HAS_LOCK 4779 status SCVYL | signal 013c | snr 013c | ber 0181 | unc 0181 | FE_HAS_LOCK 4927 status SCVYL | signal 013c | snr 013c | ber 025e | unc 025e | FE_HAS_LOCK 4973 status SCVYL | signal 013c | snr 013c | ber 0157 | unc 0157 | FE_HAS_LOCK 5024 status SCVYL | signal 013c | snr 013c | ber 024c | unc 024c | FE_HAS_LOCK 5310 status SCVYL | signal 013c | snr 013c | ber 0190 | unc 0190 | FE_HAS_LOCK 5328 status SCVYL | signal 013c | snr 013c | ber 0277 | unc 0277 | FE_HAS_LOCK 5439 status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 5441 status SCVYL | signal 0138 | snr 0138 | ber 024f | unc 024f | FE_HAS_LOCK 5447 status SCVYL | signal 0138 | snr 0138 | ber 0266 | unc 0266 | FE_HAS_LOCK 5885 status SCVYL | signal 013a | snr 013a | ber 00b3 |
Re: HVR-1600: Skipped encoder MPEG, MDL 63, 62 times - it must have dropped out of rotation
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 device A; then it doesn't matter how fast your CPU is. Yes, quite true. I was forgetting about how nasty an irq handler can be on other hardware. You may wish to use perf or ftrace, or some other tool/method of measuring kernel interrupt handling latency to find out what causes any delays from the CX23418 raising its IRQ line to cx18_irq_handler() being called by the kernel. Excellent idea. I'm afraid I'm quite (read: very) green in the area of kernel performance profiling. But I'm smart. Looking around, it seems that with ftrace, I am looking for the irqsoff tracer, is that correct? Unfortunately my kernel doesn't have that one: # cat /sys/kernel/debug/tracing/available_tracers blk function_graph mmiotrace wakeup_rt wakeup function nop I can't seem to find any useful information on using perf to analyze ISR latency. Any pointers? Cheers, b. signature.asc Description: OpenPGP digital signature
HVR-1600: Skipped encoder MPEG, MDL 63, 62 times - it must have dropped out of rotation
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: [34705.375793] cx18-0: Skipped encoder IDX, MDL 415, 2 times - it must have dropped out of rotation Apr 19 20:12:45 pvr kernel: [34865.535784] cx18-0: Skipped encoder IDX, MDL 426, 2 times - it must have dropped out of rotation Apr 19 20:12:45 pvr kernel: [34865.609900] cx18-0: Skipped encoder IDX, MDL 430, 1 times - it must have dropped out of rotation Apr 19 20:12:45 pvr kernel: [34865.684180] cx18-0: Could not find MDL 426 for stream encoder IDX Apr 19 20:12:58 pvr kernel: [34878.912976] cx18-0: Could not find MDL 430 for stream encoder IDX Apr 19 20:13:00 pvr kernel: [34880.850172] cx18-0: Skipped encoder MPEG, MDL 53, 62 times - it must have dropped out of rotation Apr 19 20:15:25 pvr kernel: [35025.696747] cx18-0: Skipped encoder IDX, MDL 435, 2 times - it must have dropped out of rotation Apr 19 20:15:25 pvr kernel: [35025.771765] cx18-0: Skipped encoder IDX, MDL 439, 1 times - it must have dropped out of rotation Apr 19 20:15:25 pvr kernel: [35025.847732] cx18-0: Could not find MDL 435 for stream encoder IDX Apr 19 20:15:25 pvr kernel: [35025.901315] cx18-0: Skipped TS, MDL 82, 16 times - it must have dropped out of rotation Apr 19 20:15:32 pvr kernel: [35032.370364] cx18-0: Skipped encoder IDX, MDL 435, 2 times - it must have dropped out of rotation Apr 19 20:15:38 pvr kernel: [35039.074592] cx18-0: Could not find MDL 439 for stream encoder IDX Apr 19 20:15:40 pvr kernel: [35040.938552] cx18-0: Skipped encoder MPEG, MDL 29, 62 times - it must have dropped out of rotation Apr 19 20:18:05 pvr kernel: [35185.859652] cx18-0: Skipped encoder IDX, MDL 445, 2 times - it must have dropped out of rotation Apr 19 20:18:05 pvr kernel: [35185.933816] cx18-0: Skipped encoder IDX, MDL 449, 1 times - it must have dropped out of rotation Apr 19 20:18:05 pvr kernel: [35186.008176] cx18-0: Could not find MDL 445 for stream encoder IDX Apr 19 20:18:19 pvr kernel: [35199.237035] cx18-0: Could not find MDL 449 for stream encoder IDX Apr 19 20:18:19 pvr kernel: [35199.289870] cx18-0: Could not find MDL 49 for stream encoder MPEG Apr 19 20:18:25 pvr kernel: [35205.879310] cx18-0: Skipped encoder IDX, MDL 450, 2 times - it must have dropped out of rotation Apr 19 20:23:26 pvr kernel: [35506.147134] cx18-0: Skipped encoder IDX, MDL 402, 2 times - it must have dropped out of rotation Apr 19 20:24:19 pvr kernel: [35559.705155] cx18-0: Skipped encoder MPEG, MDL 16, 62 times - it must have dropped out of rotation IIRC I was told previously that it was due to interrupts not being serviced quickly enough. Am I recalling correctly? Could that really be a problem even with a dual core 3GHz P4? Also, are those messages related to the clearqam path or the MPEG2 hardware encoder path? i.e. are those digital recording messages or analog recording messages? Cheers, b. signature.asc Description: OpenPGP digital signature
HVR-950Q: (AssemblePSIP) Error: offset181, pes length current cannot be queried
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 reported: Apr 18 20:59:59 pvr mythbackend[1857]: W DeviceReadBuffer DeviceReadBuffer.cpp:525 (Poll) DevRdB(/dev/dvb/adapter0/frontend0): Poll took an unusually long time 1674946 ms The only messages on the kernel message buffering during that whole time were: Apr 18 20:00:00 pvr kernel: [ 1659.927835] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Apr 18 20:00:00 pvr kernel: [ 1659.938474] xc5000: firmware read 12401 bytes. Apr 18 20:00:00 pvr kernel: [ 1659.942973] xc5000: firmware uploading... Apr 18 20:00:07 pvr kernel: [ 1666.608017] xc5000: firmware upload complete... Apr 18 20:59:59 pvr kernel: [ 5259.143919] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Apr 18 20:59:59 pvr kernel: [ 5259.170733] xc5000: firmware read 12401 bytes. Apr 18 20:59:59 pvr kernel: [ 5259.175227] xc5000: firmware uploading... Apr 18 21:00:06 pvr kernel: [ 5265.872024] xc5000: firmware upload complete... I am using (Ubuntu) Linux kernel 3.2.0-18-generic Any ideas what happened? Cheers, b. signature.asc Description: OpenPGP digital signature
can't rmmod au0828; modprobe au0828 and have a working device
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 NTSC(M) ATSC/DVB Digital (eeprom 0x88) [44847.465471] tveeprom 0-0050: audio processor is AU8522 (idx 44) [44847.515481] tveeprom 0-0050: decoder processor is AU8522 (idx 42) [44847.567162] tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter [44847.630272] hauppauge_eeprom: hauppauge eeprom: model=72001 I cannot seem to get it to work after removing the au0828 xc5000 au8522 modules and then modprobing the au0828 module. If I physically remove the device and plug it back in, it will work fine, however using rmmod/modprobe it seems to fail on trying to read from it. For example: $ gnutv -adapter 0 -out stdout -channels chans 100-3 just yields a: Using frontend Auvitek AU8522 QAM/8VSB Frontend, type ATSC status | signal | snr | ber | unc | where the value to the right of the signal and snr toggles between and 0118 but no output is ever emitted. Why would I need to use rmmod and modprobe to remove and reinstall the driver you might ask? To be honest I'd prefer not to have to but with these drivers loaded suspend-to-ram hangs. This never used to be the case on previous (2.6.32ish) kernels but now with the 3.2 kernels that I have been using it is the case. So in fact, if the hanging-on-suspend problem could be fixed, this other issue with a failing device after rmmod/modprobe would be moot. Any ideas on either problem? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: gnutv should not ignore SIGPIPE
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/gnutv_data.c 2011-11-28
09:10:33.010407011 -0500
+++ linuxtv-dvb-apps-1.1.1+rev1273/util/gnutv/gnutv_data.c 2011-11-28
09:10:26.446258282 -0500
@@ -265,7 +265,10 @@
while(written size) {
int tmp = write(outfd, buf + written, size - written);
if (tmp == -1) {
- if (errno != EINTR) {
+ if (errno == EPIPE) {
+ fprintf(stderr, processing EPIPE\n);
+ return 0;
+ } else if (errno != EINTR) {
fprintf(stderr, Write error: %m\n);
break;
}
--- linuxtv-dvb-apps-1.1.1+rev1273~/util/gnutv/gnutv.c 2011-11-28
10:13:13.294445131 -0500
+++ linuxtv-dvb-apps-1.1.1+rev1273/util/gnutv/gnutv.c.new 2011-11-28
10:13:10.510492321 -0500
@@ -262,7 +262,7 @@
// setup any signals
signal(SIGINT, signal_handler);
- signal(SIGPIPE, SIG_IGN);
+ signal(SIGPIPE, signal_handler);
// start the CA stuff
gnutv_ca_params.adapter_id = adapter_id;
signature.asc
Description: OpenPGP digital signature
gnutv should not ignore SIGPIPE
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 above example) is killed. Is there a good reason I am not seeing why gnutv should be ignoring SIGPIPE? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: gnutv should not ignore SIGPIPE
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: OpenPGP digital signature
scan returns channels with no VID
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 121:58500:QAM_256:0:5846:77 122:58500:QAM_256:0:5848:936 123:58500:QAM_256:0:5850:958 These are all viewable channels. Any ideas why the VID is empty? At the same time, other channels have a VID but are not actually viewable/tunable: 108:55500:QAM_256:3691:3692:726 109:55500:QAM_256:3695:3696:728 110:55500:QAM_256:3693:3694:727 Any ideas? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: scan returns channels with no VID
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 actually be viewed without a Cablecard.
Understood.
Ultimately, I'm looking at the PID/AID values because mplayer/mencoder
doesn't seem to be able to find video on one of these known-functional
channels:
$ mencoder -v dvb://122 -o test.mpg -oac copy -ovc copy -dvbin
card=2:file=~/.mplayer/channels.conf.atsc
...
get_path('channels.conf.atsc') - '/home/brian/.mplayer/channels.conf.atsc'
CONFIG_READ FILE: /home/brian/.mplayer/channels.conf.atsc, type: 4
...
ATSC, NUM: 108, NUM_FIELDS: 4, NAME: 109, FREQ: 55500
PIDS: 3695 3696 0
ATSC, NUM: 109, NUM_FIELDS: 4, NAME: 110, FREQ: 55500
PIDS: 3693 3694 0
ATSC, NUM: 110, NUM_FIELDS: 4, NAME: 111, FREQ: 56100
PIDS: 7313 7315 0
...
ATSC, NUM: 119, NUM_FIELDS: 4, NAME: 120, FREQ: 58500
PIDS: 0 5842
ATSC, NUM: 120, NUM_FIELDS: 4, NAME: 121, FREQ: 58500
PIDS: 0 5846
ATSC, NUM: 121, NUM_FIELDS: 4, NAME: 122, FREQ: 58500
PIDS: 0 5848
ATSC, NUM: 122, NUM_FIELDS: 4, NAME: 123, FREQ: 58500
PIDS: 0 5850
ATSC, NUM: 123, NUM_FIELDS: 4, NAME: 124, FREQ: 58500
PIDS: 0 5844
...
DVB_CONFIG, can't open device /dev/dvb/adapter2/frontend0, skipping
DVB_CONFIG, can't open device /dev/dvb/adapter3/frontend0, skipping
OPEN_DVB: prog=122, card=2, type=4
dvb_streaming_start(PROG: 122, CARD: 2, FILE: ~/.mplayer/channels.conf.atsc)
PROGRAM NUMBER 121: name=122, freq=58500
DVB_OPEN_DEVICES(2)
OPEN(0), file /dev/dvb/adapter1/demux0: FD=4, CNT=0
OPEN(1), file /dev/dvb/adapter1/demux0: FD=5, CNT=1
DVB_SET_CHANNEL: new channel name=122, card: 1, channel 121
dvb_tune Freq: 58500
TUNE_IT, fd_frontend 3, fd_sec -1
freq 58500, srate 0, pol Using DVB card Samsung S5H1409 QAM/8VSB
Frontend
tuning ATSC to 58500, modulation=5
Getting frontend status
Bit error rate: 0
Signal strength: 316
SNR: 316
UNC: 0
FE_STATUS: FE_HAS_LOCK FE_HAS_SYNC
SET PES FILTER ON PID 0 to fd 4, RESULT: 0, ERRNO: 0
SET PES FILTER ON PID 5848 to fd 5, RESULT: 0, ERRNO: 0
SUCCESSFUL EXIT from dvb_streaming_start
STREAM: [dvbin] dvb://122
STREAM: Description: Dvb Input
STREAM: Author: Nico
STREAM: Comment: based on the code from ??? (probably Arpi)
success: format: 29 data: 0x0 - 0x0
Checking for MPEG-TS...
TRIED UP TO POSITION 0, FOUND 47, packet_size= 188, SEEMS A TS? 1
GOOD CC: 30, BAD CC: 0
TS file format detected.
DEMUX OPEN, AUDIO_ID: -1, VIDEO_ID: -1, SUBTITLE_ID: -1,
Checking for MPEG-TS...
TRIED UP TO POSITION 8272, FOUND 47, packet_size= 188, SEEMS A TS? 1
GOOD CC: 30, BAD CC: 0
PROBING UP TO 0, PROG: 0
COLLECT_SECTION, start: 64, size: 184, collected: 0
SKIP: 0+1, TID: 0, TLEN: 49, COLLECTED: 184
PARSE_PAT: section_len: 49, section 0/0
PROG: 11 (1-th of 10), PMT: 139
PROG: 77 (2-th of 10), PMT: 140
PROG: 936 (3-th of 10), PMT: 141
PROG: 958 (4-th of 10), PMT: 142
PROG: 19 (5-th of 10), PMT: 143
PROG: 24 (6-th of 10), PMT: 144
PROG: 51 (7-th of 10), PMT: 145
PROG: 85 (8-th of 10), PMT: 146
PROG: 522 (9-th of 10), PMT: 147
PROG: 521 (10-th of 10), PMT: 148
COLLECT_SECTION, start: 64, size: 184, collected: 184
SKIP: 0+1, TID: 0, TLEN: 49, COLLECTED: 184
PARSE_PAT: section_len: 49, section 0/0
PROG: 11 (1-th of 10), PMT: 139
PROG: 77 (2-th of 10), PMT: 140
PROG: 936 (3-th of 10), PMT: 141
PROG: 958 (4-th of 10), PMT: 142
PROG: 19 (5-th of 10), PMT: 143
PROG: 24 (6-th of 10), PMT: 144
PROG: 51 (7-th of 10), PMT: 145
PROG: 85 (8-th of 10), PMT: 146
PROG: 522 (9-th of 10), PMT: 147
PROG: 521 (10-th of 10), PMT: 148
...
NO VIDEO! AUDIO A52(pid=5848) NO SUBS (yet)! PROGRAM N. 0
== Found audio stream: 0
ADDED AUDIO PID 5848, type: 2000 stream n. 0
Opened TS demuxer, audio: 2000(pid 0), video: (pid
-1)...POS=18800, PROBE=0
demux_ts, switched to audio pid 5848, id: 0, sh: 0x9e74088
Video stream is mandatory!
Exiting...
Is this because the VID is 0 or is that unrelated to why this isn't working?
Cheers,
b.
signature.asc
Description: OpenPGP digital signature
AVerTV Hybrid Volar MAX (H826) wiki entry
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 AP Driver tab of that page (http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431tab=APDriver) there is a Linux driver which appears to have (granted, non-GPL) source included with it. But surely given source to a working driver, a cleanroom GPL driver could be developed and supported, yes? Maybe that source is just supporting source for a binary blob. I didn't look that closely. In any case, I am just wondering what the real supported status of that device is given that the wiki is incorrect about at least some details of the device. Even if it's not supported, somebody with more understanding of this device than I (I've just read a product page) ought to fix the wiki. In fixing it, I think it's only fair to point to the vendor supplied driver, even if it's not open source and/or not a compatible open source license. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: hvr950q stopped working: read of drv0 never returns
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. :-/
Primarily I use this device with Mythtv but have been forced into trying
to debug this as it's not working in Myth. I thought that using this
device was as simple as one of the PVR-{50,{1.2}5}0 devices and I could
just cat /dev/dvb/adapter0/dvr0 file.mpg.
Your reference to azap gave me something to research. Subsequently I
have done the following:
$ br...@pc:~$ w_scan -c US -x -A2 /tmp/initial-tuning-data.txt
$ mkdir ~/.azap
$ scan -A2 initial-tuning-data.txt ~/.azap/channels.conf
But now I can't get azap to do anything useful:
$ azap -r 291
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ERROR: could not find channel '291' in channel list
$ azap -r 145
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ERROR: error while parsing modulation (syntax error)
Not sure what to try next.
b.
signature.asc
Description: This is a digitally signed message part
hvr950q stopped working: read of drv0 never returns
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 from it never seems to return any data: read(0, [ process blocks waiting ] Nothing abnormal in dmesg: [916870.612154] usb 1-2: new high speed USB device using ehci_hcd and address 27 [916870.772818] usb 1-2: configuration #1 chosen from 1 choice [916876.064150] au0828 driver loaded [916876.424163] au0828: i2c bus registered [916876.747481] tveeprom 4-0050: Hauppauge model 72001, rev B3F0, serial# 6922999 [916876.747487] tveeprom 4-0050: MAC address is 00-0D-FE-69-A2-F7 [916876.747490] tveeprom 4-0050: tuner model is Xceive XC5000 (idx 150, type 76) [916876.747494] tveeprom 4-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [916876.747497] tveeprom 4-0050: audio processor is AU8522 (idx 44) [916876.747500] tveeprom 4-0050: decoder processor is AU8522 (idx 42) [916876.747503] tveeprom 4-0050: has no radio, has IR receiver, has no IR transmitter [916876.747506] hauppauge_eeprom: hauppauge eeprom: model=72001 [916876.798021] au8522 4-0047: creating new instance [916876.798025] au8522_decoder creating new instance... [916877.127635] tuner 4-0061: chip found @ 0xc2 (au0828) [916877.282505] xc5000 4-0061: creating new instance [916877.287331] xc5000: Successfully identified at address 0x61 [916877.287336] xc5000: Firmware has not been loaded previously [916877.287791] au8522 4-0047: attaching existing instance [916877.296083] xc5000 4-0061: attaching existing instance [916877.300826] xc5000: Successfully identified at address 0x61 [916877.300830] xc5000: Firmware has not been loaded previously [916877.300835] DVB: registering new adapter (au0828) [916877.300840] DVB: registering adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... [916877.301421] Registered device AU0828 [Hauppauge HVR950Q] [916877.302825] usbcore: registered new interface driver au0828 [916925.988585] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [916925.988595] usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw [916926.076234] xc5000: firmware read 12401 bytes. [916926.076238] xc5000: firmware uploading... [916934.265042] xc5000: firmware upload complete... [916934.972117] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [916934.972128] usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw [916934.994581] xc5000: firmware read 12401 bytes. [916934.994586] xc5000: firmware uploading... [916943.981063] xc5000: firmware upload complete... [917101.354372] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [917101.354388] usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw [917101.394161] xc5000: firmware read 12401 bytes. [917101.394165] xc5000: firmware uploading... [917110.813119] xc5000: firmware upload complete... This device was working just fine until I rebooted the machine it's usually connected to earlier today. Now I can't seem to get it working anywhere. I'm at a loss where to go from here in debugging. Any hints? Thanx, b. signature.asc Description: This is a digitally signed message part
page allocation failures with Hauppauge 950Q
[ 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: configuration #1 chosen from 1 choice au0828 driver loaded au0828: i2c bus registered tveeprom 5-0050: Hauppauge model 72001, rev B3F0, serial# 6922999 tveeprom 5-0050: MAC address is 00-0D-FE-69-A2-F7 tveeprom 5-0050: tuner model is Xceive XC5000 (idx 150, type 76) tveeprom 5-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) tveeprom 5-0050: audio processor is AU8522 (idx 44) tveeprom 5-0050: decoder processor is AU8522 (idx 42) tveeprom 5-0050: has no radio, has IR receiver, has no IR transmitter hauppauge_eeprom: hauppauge eeprom: model=72001 au8522 5-0047: creating new instance au8522_decoder creating new instance... tuner 5-0061: chip found @ 0xc2 (au0828) xc5000 5-0061: creating new instance xc5000: Successfully identified at address 0x61 xc5000: Firmware has not been loaded previously au8522 5-0047: attaching existing instance xc5000 5-0061: attaching existing instance xc5000: Successfully identified at address 0x61 xc5000: Firmware has not been loaded previously DVB: registering new adapter (au0828) DVB: registering adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... Registered device AU0828 [Hauppauge HVR950Q] usbcore: registered new interface driver au0828 xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... usb 1-4: firmware: requesting dvb-fe-xc5000-1.6.114.fw xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... mythbackend: page allocation failure. order:4, mode:0xc0d0 Pid: 15154, comm: mythbackend Tainted: P 2.6.32-22-generic #36-Ubuntu Call Trace: [c0588f92] ? printk+0x1d/0x23 [c01cf82e] __alloc_pages_slowpath+0x46e/0x4a0 [c01cf99a] __alloc_pages_nodemask+0x13a/0x170 [c01cf9ec] __get_free_pages+0x1c/0x30 [f87d6bdf] start_urb_transfer+0x7f/0x1e0 [au0828] [f87d6e03] au0828_dvb_start_feed+0xc3/0xe0 [au0828] [f877ec44] ? dmx_ts_feed_set+0x104/0x130 [dvb_core] [f877ecc8] dmx_ts_feed_start_filtering+0x58/0xe0 [dvb_core] [f877badb] dvb_dmxdev_start_feed+0xab/0x110 [dvb_core] [f877cf01] dvb_dmxdev_filter_start+0x2a1/0x380 [dvb_core] [c020b295] ? chrdev_open+0xf5/0x200 [f877d487] dvb_demux_do_ioctl+0x4a7/0x550 [dvb_core] [c0205f3f] ? __dentry_open+0x1af/0x290 [f877b926] dvb_usercopy+0x96/0x140 [dvb_core] [f877cfe0] ? dvb_demux_do_ioctl+0x0/0x550 [dvb_core] [c0201dd5] ? mem_cgroup_update_mapped_file_stat+0x35/0x90 [f877bfff] dvb_demux_ioctl+0x1f/0x30 [dvb_core] [f877cfe0] ? dvb_demux_do_ioctl+0x0/0x550 [dvb_core] [c021628b] vfs_ioctl+0x7b/0x90 [c0216519] do_vfs_ioctl+0x79/0x310 [c0216817] sys_ioctl+0x67/0x80 [c0205d4e] ? sys_open+0x2e/0x40 [c01033ec] syscall_call+0x7/0xb Mem-Info: DMA per-cpu: CPU0: hi:0, btch: 1 usd: 0 CPU1: hi:0, btch: 1 usd: 0 Normal per-cpu: CPU0: hi: 186, btch: 31 usd: 0 CPU1: hi: 186, btch: 31 usd: 0 HighMem per-cpu: CPU0: hi: 186, btch: 31 usd: 2 CPU1: hi: 186, btch: 31 usd: 0 active_anon:238741 inactive_anon:92054 isolated_anon:88 active_file:46091 inactive_file:47629 isolated_file:65 unevictable:35 dirty:18690 writeback:500 unstable:207 free:233580 slab_reclaimable:13718 slab_unreclaimable:10001 mapped:19061 shmem:3609 pagetables:4972 bounce:0 DMA free:3508kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:1904kB inactive_file:2024kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB mlocked:0kB dirty:96kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:44kB slab_unreclaimable:616kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 865 2777 2777 Normal free:410632kB min:3728kB low:4660kB high:5592kB active_anon:59376kB inactive_anon:61132kB active_file:80984kB inactive_file:84656kB unevictable:0kB isolated(anon):220kB isolated(file):236kB present:885944kB mlocked:0kB dirty:46268kB writeback:292kB mapped:5692kB shmem:348kB slab_reclaimable:54828kB slab_unreclaimable:39388kB kernel_stack:4856kB pagetables:1084kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 15295 15295 HighMem free:520180kB min:512kB low:2572kB high:4632kB active_anon:895588kB inactive_anon:307084kB active_file:101476kB inactive_file:103836kB unevictable:140kB isolated(anon):132kB isolated(file):24kB present:1957776kB mlocked:136kB dirty:28396kB writeback:1708kB mapped:70552kB shmem:14088kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:18804kB unstable:828kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 5*4kB 30*8kB 15*16kB 30*32kB 24*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB
