Beiträge von iampivot

Using the original noSignal16x9.mpg file from the xine plugin fixes this, as well as just using the noSignal16x9-completelyBlack.mpg instead.

Would be nice to have the default yavdr nosignal image in a 16x9 version though.

I am experiencing some weird stuttering with my 0.5.0-alpha1 installation. When watching TV, there's a sudden pause in the update of the picture, then less than half a second later, there's pixelisation, as if there's an error in the received DVB stream. It's almost as if the CPU has been busy with a non-maskable IRQ, and thus it has had no time to keep up with the DVB stream causing a buffer overrun.

It can disappear for several hours, then reappear, with a stutter every 21 or 42 seconds or so. I see it with 0.5.0-alpha1, but have also seen it with 0.3.2 and 0.4.0, and on different hardware (pentium-m on 0.4.0 32bit w nova-t 500 cards), thus indicating it might be caused by something external. It's also independent of frontend, as I've seen it with both the xine plugin, xineliboutput and softhddevice.

In the logs I only get any indication something is wrong when using the xine output plugin, as xineliboutput doesn't report anything about it. I've attached a sample of syslog output.

Am thus looking at how to proceed to find the cause of this?

Maybe a clue can be that it seems to appear at intervals with a multiple of 21 seconds? Can it be any software that is causing this, eg. something related to clock drift? I don't see any such stuttering if I use the built in tuner of my panasonic plasma, which is connected to the same antenna signal splitter as my two external dual-tuner boxes.

Hardware; ASUS AT5IONT-I + 2 sony playtv tuners, mceusb sensor, 2x WD green drives w/ headpark timeout set at 5 minutes.

Just installed 0.5.0-alpha1, and changed to use the xine frontend.

Even if I change config to select 16x9 video format in Setup/DVB, the image shown during channel change is a 4x3 image, which also results in the OSD changing to a 4x3 format when using OSD blending. It's pretty annoying these days with virtually all material being 16x9.

Is there an easy fix for this, or a config setting somewhere I've overlooked?

Looks like there's an output plugin for the hardware in some linux based pvrs, eg the Atevio 7500. See eg.

http://aaf-board.com/forum/showthread.php?76593-VDR-duckbox&p=789387&mode=linear
http://gitorious.org/open-duck….22/PLUGINS/src/dvbufs9xx

Does anyone here have any experience running yavdr on such hardware?

[Blockierte Grafik: http://digitalt.tv/wp-content/gallery/atevio7700hdd/atevio_hdd_open.jpg]

Zitat von seahawk1986

What protocols are supported by this card?

Code

sudo ir-keytable

root@htpc2:~# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event2) with:
Driver budget_ci, table rc-tt-1500
Supported protocols:
Enabled protocols:
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event3) with:
Driver (null), table rc-dib0700-rc5
Supported protocols: NEC RC-5 RC-6
Enabled protocols: RC-5
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event4) with:
Driver (null), table rc-dib0700-rc5
Supported protocols: NEC RC-5 RC-6
Enabled protocols: RC-5
Repeat delay = 500 ms, repeat period = 125 ms

Probably relevant as well; https://lists.linux-foundation…/2010-October/025769.html

Zitat von seahawk1986

Hi,
I found this thread yavdr 4.0; grey hauppauge remote on nova-t 500
Probably you were absolutely right it's a driver related issue - but it seems it existed with v4l-dvb-dkms already.
Are there any hints within the output of dmesg if there is a problem loading the firmware?

It appears that the only significant difference is the line "dib0700: rc submit urb failed"

A google search turns up a few other people with the same problem, but no apparent solution. Am wondering if some recent dib0700 cleanups would possibly fix the issue? See eg. http://patchwork.linuxtv.org/patch/9858/

I assume there's no way to run more recent kernels except using the test repositories?

Zitat von seahawk1986

There are two other recognized IR-receivers attached to your VDR - probably you could use them, too.

Well, there's one additional nova-t 500 card with the same problem, and the driver for the other, a c1501 dvb-c card doesn't implement generic RC-5 reception as the nova-t 500 does.

Output of cat /proc/bus/input/device is attached. The output is the same for both cold and warm boot.

I'm having problem with the remote sensor on my Nova-T 500 not working after warm-start. It works ok from cold-start. Is this a known problem with these drivers?

My question was really about playback only. The cause for zero length recordings are probably worth a topic by itself.

Just confirming; Playback of zero length recordings work ok with vdr from this repository here as well.

Looks like kernel 3.2.10 will contain a workaround for the ASM108x chipsets with PCI IRQ deassert bugs.

https://bugzilla.redhat.com/show_bug.cgi?id=755956

Do you have any indication about which patch might be causing this?

Vanilla VDR runs ok.

Sure, I can help test.

Well, basic error seeking procedure is to replace one piece at a time to find the piece that is not working.

I'll just compile it myself.

Ok, is there a yavdr package that provides plain vanilla unpatched VDR?

Here's an empty recording tar file

The empty recordings are caused by tuning issues with nova-t 500 cards. There shouldn't be empty recordings in a perfect world of course, but then vanilla VDR doesn't choke on them either.

What is the double XX plugin? I don't have any custom plugins running.

I will dig more into this when the VDR system is available for debugging, later today.

Here's a run without extrecmenu. Will create a tar file as well.