[linux-dvb] HVR-4000 and analogue tv

[linux-dvb] HVR-4000 and analogue tv

[Anders Semb Hermansen]

Hello all,

I put a HVR-4000 in my mythtv box, I'm only going to use it for  
analogue TV right now.

I have used dvb/v4l drivers from mercirual from yesterday and sfe-8969- 
untested.diff from http://dev.kewl.org/hauppauge/ to get HVR-4000  
support.

The system is Debian GNU/Linux lenny with latest packages and kernel  
updated yesterday. Mythtv and multimedia packages are from debian- 
multimedia.

I also get the same error described below when using dvb/v4l driver  
from http://linuxtv.org/hg/~stoth/s2-mfe

I added it as a v4l capture card in mythtv (/dev/video0 and sound  
from /dev/dsp2) and scanned for channels. Everything OK so far :)

When I use mythtv and go into "Watch TV" I get snow on the screen (and  
some green). If I change channel the picture comes up fine. So I  
always have to change channel after pressing "Watch TV". This will  
make recodings only show snow, because I cannot do the channel change  
"trick".

I got strange audio, but read somewhere else that I needed to change  
audo samplerate to 48000. That fixed that problem.

I get some errors from the kernel.

These come a lot:
Sep 24 16:37:57 xpc kernel: [  656.419808] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 16:37:57 xpc kernel: [  656.419816] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 16:37:57 xpc kernel: [  656.419825] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*

And also this:
Sep 24 16:37:57 xpc kernel: [  656.420004] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 16:37:57 xpc kernel: [  656.420011] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 16:37:57 xpc last message repeated 7 times
Sep 24 16:37:57 xpc kernel: [  656.420011] cx88[0]/1: IRQ loop  
detected, disabling interrupts
Sep 24 16:37:57 xpc kernel: [  656.428111] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 16:38:07 xpc kernel: [  666.548868] cx88[0]: irq aud [0x201101]  
dn_risci1* dnf_of dn_sync* mchg_irq
Sep 24 16:38:07 xpc kernel: [  666.588442] cx88[0]: irq aud [0x1101]  
dn_risci1* dnf_of dn_sync*

I also got this (belive this was with s2-mfe driver):
Sep 23 23:07:43 xpc kernel: [   89.399157] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 23 23:07:53 xpc kernel: [   99.528009] cx88[0]: irq aud [0x201101]  
dn_risci1* dnf_of dn_sync* mchg_irq
Sep 23 23:07:53 xpc kernel: [   99.528009] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 23 23:07:53 xpc last message repeated 48 times
Sep 23 23:07:53 xpc kernel: [   99.528009] cx88[0]/1: IRQ loop  
detected, disabling interrupts
Sep 23 23:07:53 xpc kernel: [   99.539066] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 23 23:15:34 xpc kernel: [  561.012009] cx88[0]: video y / packed -  
dma channel status dump
Sep 23 23:15:34 xpc kernel: [  561.012022] cx88[0]:   cmds: initial  
risc: 0x12f1c000
Sep 23 23:15:34 xpc kernel: [  561.012027] cx88[0]:   cmds: cdt  
base    : 0x00180440
Sep 23 23:15:34 xpc kernel: [  561.012031] cx88[0]:   cmds: cdt  
size    : 0x0000000c
Sep 23 23:15:34 xpc kernel: [  561.012035] cx88[0]:   cmds: iq  
base     : 0x00180400
Sep 23 23:15:34 xpc kernel: [  561.012039] cx88[0]:   cmds: iq  
size     : 0x00000010
Sep 23 23:15:34 xpc kernel: [  561.012042] cx88[0]:   cmds: risc  
pc     : 0x132aa998
Sep 23 23:15:34 xpc kernel: [  561.012046] cx88[0]:   cmds: iq wr  
ptr   : 0x00000100
Sep 23 23:15:34 xpc kernel: [  561.012050] cx88[0]:   cmds: iq rd  
ptr   : 0x00000104
Sep 23 23:15:34 xpc kernel: [  561.012054] cx88[0]:   cmds: cdt  
current : 0x00000458
Sep 23 23:15:34 xpc kernel: [  561.012058] cx88[0]:   cmds: pci  
target  : 0x132a9b00
Sep 23 23:15:34 xpc kernel: [  561.012061] cx88[0]:   cmds: line /  
byte : 0x00f00000
Sep 23 23:15:34 xpc kernel: [  561.012067] cx88[0]:   risc0:  
0x80008200 [ sync resync count=512 ]
Sep 23 23:15:34 xpc kernel: [  561.012074] cx88[0]:   risc1:  
0x1c000500 [ write sol eol count=1280 ]
Sep 23 23:15:34 xpc kernel: [  561.012080] cx88[0]:   risc2:  
0x12f02500 [ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012084] cx88[0]:   risc3:  
0x18000100 [ write sol count=256 ]
Sep 23 23:15:34 xpc kernel: [  561.012090] cx88[0]:   iq 0: 0x132a9000  
[ write irq2 irq1 21 19 cnt1 resync 12 count=0 ]
Sep 23 23:15:34 xpc kernel: [  561.012099] cx88[0]:   iq 1: 0x1c000500  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012103] cx88[0]:   iq 2: 0x132a9600  
[ write irq2 irq1 21 19 cnt1 resync 12 count=1536 ]
Sep 23 23:15:34 xpc kernel: [  561.012111] cx88[0]:   iq 3: 0x80008200  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012115] cx88[0]:   iq 4: 0x1c000500  
[ write sol eol count=1280 ]
Sep 23 23:15:34 xpc kernel: [  561.012121] cx88[0]:   iq 5: 0x12f02500  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012125] cx88[0]:   iq 6: 0x18000100  
[ write sol count=256 ]
Sep 23 23:15:34 xpc kernel: [  561.012131] cx88[0]:   iq 7: 0x12f02f00  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012134] cx88[0]:   iq 8: 0x14000400  
[ write eol count=1024 ]
Sep 23 23:15:34 xpc kernel: [  561.012140] cx88[0]:   iq 9: 0x12f03000  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012144] cx88[0]:   iq a: 0x1c000500  
[ write sol eol count=1280 ]
Sep 23 23:15:34 xpc kernel: [  561.012150] cx88[0]:   iq b: 0x12f03900  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012154] cx88[0]:   iq c: 0x1c000500  
[ write sol eol count=1280 ]
Sep 23 23:15:34 xpc kernel: [  561.012160] cx88[0]:   iq d: 0x12f04300  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012163] cx88[0]:   iq e: 0x18000300  
[ write sol count=768 ]
Sep 23 23:15:34 xpc kernel: [  561.012169] cx88[0]:   iq f: 0x12f04d00  
[ arg #1 ]
Sep 23 23:15:34 xpc kernel: [  561.012172] cx88[0]: fifo: 0x00180c00 - 
 > 0x183400
Sep 23 23:15:34 xpc kernel: [  561.012175] cx88[0]: ctrl: 0x00180400 - 
 > 0x180460
Sep 23 23:15:34 xpc kernel: [  561.012178] cx88[0]:   ptr1_reg:  
0x00182000
Sep 23 23:15:34 xpc kernel: [  561.012182] cx88[0]:   ptr2_reg:  
0x00180488
Sep 23 23:15:34 xpc kernel: [  561.012185] cx88[0]:   cnt1_reg:  
0x00000004
Sep 23 23:15:34 xpc kernel: [  561.012189] cx88[0]:   cnt2_reg:  
0x00000000
Sep 23 23:15:34 xpc kernel: [  561.012198] cx88[0]/0: [de9049e0/1]  
timeout - dma=0x132aa000
Sep 23 23:15:34 xpc kernel: [  561.012201] cx88[0]/0: [de904320/2]  
timeout - dma=0x13388000
Sep 23 23:15:34 xpc kernel: [  561.012205] cx88[0]/0: [de9043e0/3]  
timeout - dma=0x104fc000
Sep 23 23:15:34 xpc kernel: [  561.012208] cx88[0]/0: [de9044a0/4]  
timeout - dma=0x107ba000
Sep 23 23:15:34 xpc kernel: [  561.012211] cx88[0]/0: [de904920/0]  
timeout - dma=0x12f1c000

Mythtv complains about unable to read:
008-09-24 17:07:02.587 NVR(/dev/video0) Error: Only read -1 bytes of  
4096 bytes from '/dev/dsp2
read audio: Input/output error
strange error flushing buffer ...


Where do I go from here?
Is this an error with the HVR-4000 driver or in mythtv?
It seems to work fine once I have changed channel.


Thanks for any help,
Anders


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Darron Broad]

In message <953A45C4-975B-4A05-8B41-AE8A486D0CA6@ginandtonic.no>, Anders Semb Hermansen wrote:
>Hello all,

hi.

>I put a HVR-4000 in my mythtv box, I'm only going to use it for  
>analogue TV right now.
>
>I have used dvb/v4l drivers from mercirual from yesterday and sfe-8969- 
>untested.diff from http://dev.kewl.org/hauppauge/ to get HVR-4000  
>support.
>
>The system is Debian GNU/Linux lenny with latest packages and kernel  
>updated yesterday. Mythtv and multimedia packages are from debian- 
>multimedia.
>
>I also get the same error described below when using dvb/v4l driver  
>from http://linuxtv.org/hg/~stoth/s2-mfe
>
>I added it as a v4l capture card in mythtv (/dev/video0 and sound  
>from /dev/dsp2) and scanned for channels. Everything OK so far :)
>
>When I use mythtv and go into "Watch TV" I get snow on the screen (and  
>some green). If I change channel the picture comes up fine. So I  
>always have to change channel after pressing "Watch TV". This will  
>make recodings only show snow, because I cannot do the channel change  
>"trick".
>
>I got strange audio, but read somewhere else that I needed to change  
>audo samplerate to 48000. That fixed that problem.
>
>I get some errors from the kernel.
<snip>

I haven't tested analogue in mythtv, only dvb-s. My only testing has been
done with TVTIME for analogue. What happens when you try that?

cya.


--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Anders Semb Hermansen]

Den 24. sep.. 2008 kl. 18.18 skrev Darron Broad:
<snip>
> I haven't tested analogue in mythtv, only dvb-s. My only testing has  
> been
> done with TVTIME for analogue. What happens when you try that?

It seems to work ok. I struggeld a bit to get sound. Need to run this  
also:
arecord -f dat -D hw:2,0 | aplay -f dat -

I saw this in my logs, but it seems to work okay (maybe these came  
when I was trying difference sox and arecord/aplay commands):

Sep 24 18:53:46 xpc kernel: [  769.020260] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020269] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020277] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020286] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020294] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020310] cx88[0]: irq aud [0x1000]  
dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020318] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020327] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020335] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020343] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020352] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020362] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020375] cx88[0]: irq aud [0x1000]  
dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020382] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020391] cx88[0]: irq aud [0x1000]  
dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020399] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020407] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020416] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020424] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020439] cx88[0]: irq aud [0x1000]  
dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020447] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020456] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020464] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020473] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*
Sep 24 18:53:46 xpc kernel: [  769.020481] cx88[0]: irq aud [0x1001]  
dn_risci1* dn_sync*


Does this mean that mythtv is doing something weird or maybe just  
using the v4l api in a different way which the driver cannot handle?


Thanks for your response,
Anders


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Darron Broad]

In message <F70AC72F-8DF3-4A9A-BFA1-A4FED9D3EABC@ginandtonic.no>, Anders Semb Hermansen wrote:

hi.

>Den 24. sep.. 2008 kl. 18.18 skrev Darron Broad:
><snip>
>> I haven't tested analogue in mythtv, only dvb-s. My only testing has  
>> been
>> done with TVTIME for analogue. What happens when you try that?
>
>It seems to work ok. I struggeld a bit to get sound. Need to run this  
>also:
>arecord -f dat -D hw:2,0 | aplay -f dat -

This is how i test also.

>I saw this in my logs, but it seems to work okay (maybe these came  
>when I was trying difference sox and arecord/aplay commands):
>
>Sep 24 18:53:46 xpc kernel: [  769.020260] cx88[0]: irq aud [0x1001]  
>dn_risci1* dn_sync*

It looks like `dn_sync' is triggering that log. I don't know
anything about this but docs suggest it's a buffer underrun.
I am sure someone else can explain in full.

<snip>
>
>Does this mean that mythtv is doing something weird or maybe just  
>using the v4l api in a different way which the driver cannot handle?

This is feasable. I will take a look if I get the time but this
is more than likely to be when I have other reasons to look
at mythtv so don't expect an immediate response :-)

cya

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Anders Semb Hermansen]

Den 24. sep.. 2008 kl. 19.20 skrev Darron Broad:

<snip>

> <snip>
>>
>> Does this mean that mythtv is doing something weird or maybe just
>> using the v4l api in a different way which the driver cannot handle?
>
> This is feasable. I will take a look if I get the time but this
> is more than likely to be when I have other reasons to look
> at mythtv so don't expect an immediate response :-)
>

I did some more investigating.

I thought maybe this had something to do with the tuner, since I got  
snow. So I enabled debugging for the tuner module (debug=1). What I  
saw was that when I started watching TV in myth, there was a  
TUNER_SET_STANDBY after frequency and other things was set. This  
TUNER_SET_STANDBY did not appear when I was just changing channel (and  
picture worked).

So I searched the driver for TUNER_STANDBY and found one which I  
tried. Here is what I did:

diff -r e5ca4534b543 linux/drivers/media/video/cx88/cx88-video.c
--- a/linux/drivers/media/video/cx88/cx88-video.c       Tue Sep 09  
08:29:56 2008 -0700
+++ b/linux/drivers/media/video/cx88/cx88-video.c       Wed Sep 24  
20:35:46 2008 +0200
@@ -1152,7 +1152,8 @@
         file->private_data = NULL;
         kfree(fh);

-       cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
+       printk("Don't set standby mode! TUNER_SET_STANDBY NO SIR!");
+       //cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);

         return 0;
  }


This fixed it!!

I don't know what side effects this will have. Or if this is caused by  
wrong use of v4l by mythtv, or driver not implementing it correctly.  
Those who know the codebase can maybe answer that and come up with a  
better permanent solution.


Best regards,
Anders


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Darron Broad]

In message <8C08530B-BAD7-4E83-B1CA-6AB66EE9F53F@ginandtonic.no>, Anders Semb Hermansen wrote:

lo

>Den 24. sep.. 2008 kl. 19.20 skrev Darron Broad:
>
><snip>
>
>> <snip>
>>>
>>> Does this mean that mythtv is doing something weird or maybe just
>>> using the v4l api in a different way which the driver cannot handle?
>>
>> This is feasable. I will take a look if I get the time but this
>> is more than likely to be when I have other reasons to look
>> at mythtv so don't expect an immediate response :-)
>>
>
>I did some more investigating.
>
>I thought maybe this had something to do with the tuner, since I got  
>snow. So I enabled debugging for the tuner module (debug=1). What I  
>saw was that when I started watching TV in myth, there was a  
>TUNER_SET_STANDBY after frequency and other things was set. This  
>TUNER_SET_STANDBY did not appear when I was just changing channel (and  
>picture worked).
>
>So I searched the driver for TUNER_STANDBY and found one which I  
>tried. Here is what I did:
>
>diff -r e5ca4534b543 linux/drivers/media/video/cx88/cx88-video.c
>--- a/linux/drivers/media/video/cx88/cx88-video.c       Tue Sep 09  
>08:29:56 2008 -0700
>+++ b/linux/drivers/media/video/cx88/cx88-video.c       Wed Sep 24  
>20:35:46 2008 +0200
>@@ -1152,7 +1152,8 @@
>         file->private_data = NULL;
>         kfree(fh);
>
>-       cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
>+       printk("Don't set standby mode! TUNER_SET_STANDBY NO SIR!");
>+       //cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
>
>         return 0;
>  }
>
>
>This fixed it!!
>
>I don't know what side effects this will have. Or if this is caused by  
>wrong use of v4l by mythtv, or driver not implementing it correctly.  
>Those who know the codebase can maybe answer that and come up with a  
>better permanent solution.

I admit I found your fix interesting. In fact, you can reproduce
this using tvtime and cat.

Eg.

> tvtime -d /dev/video0 &
> cat /dev/video0

The problem in mythtv appears to be in OpenV4L2DeviceAsInput(void)
where is opens the video device twice although I have no confirmed it.

cya

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Steven Toth]

Anders Semb Hermansen wrote:
> Den 24. sep.. 2008 kl. 19.20 skrev Darron Broad:
> 
> <snip>
> 
>> <snip>
>>> Does this mean that mythtv is doing something weird or maybe just
>>> using the v4l api in a different way which the driver cannot handle?
>> This is feasable. I will take a look if I get the time but this
>> is more than likely to be when I have other reasons to look
>> at mythtv so don't expect an immediate response :-)
>>
> 
> I did some more investigating.
> 
> I thought maybe this had something to do with the tuner, since I got  
> snow. So I enabled debugging for the tuner module (debug=1). What I  
> saw was that when I started watching TV in myth, there was a  
> TUNER_SET_STANDBY after frequency and other things was set. This  
> TUNER_SET_STANDBY did not appear when I was just changing channel (and  
> picture worked).
> 
> So I searched the driver for TUNER_STANDBY and found one which I  
> tried. Here is what I did:
> 
> diff -r e5ca4534b543 linux/drivers/media/video/cx88/cx88-video.c
> --- a/linux/drivers/media/video/cx88/cx88-video.c       Tue Sep 09  
> 08:29:56 2008 -0700
> +++ b/linux/drivers/media/video/cx88/cx88-video.c       Wed Sep 24  
> 20:35:46 2008 +0200
> @@ -1152,7 +1152,8 @@
>          file->private_data = NULL;
>          kfree(fh);
> 
> -       cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
> +       printk("Don't set standby mode! TUNER_SET_STANDBY NO SIR!");
> +       //cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
> 
>          return 0;
>   }
> 
> 
> This fixed it!!
> 
> I don't know what side effects this will have. Or if this is caused by  
> wrong use of v4l by mythtv, or driver not implementing it correctly.  
> Those who know the codebase can maybe answer that and come up with a  
> better permanent solution.

Anders, thanks for helping debug this. :)

This will have odd side effects for other boards. It's an interesting 
fix and it points us to the real issue, but we need to find a better way 
to clean this up, before we submit for merge.

The HVR4000 is a very strange board, we need to be careful when adding 
generic changes into cx88-*.c that are not conditioned based on (board 
== HVR4000)

I welcome your patches, if you find anything else that's odd/strange 
then let's discuss those also. Your help is very much appreciated.

Regards,

- Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Anders Semb Hermansen]

Den 24. sep.. 2008 kl. 21.09 skrev Darron Broad:

<snip>

>> I did some more investigating.
>>
>> I thought maybe this had something to do with the tuner, since I got
>> snow. So I enabled debugging for the tuner module (debug=1). What I
>> saw was that when I started watching TV in myth, there was a
>> TUNER_SET_STANDBY after frequency and other things was set. This
>> TUNER_SET_STANDBY did not appear when I was just changing channel  
>> (and
>> picture worked).
>>
>> So I searched the driver for TUNER_STANDBY and found one which I
>> tried. Here is what I did:
>>
>> diff -r e5ca4534b543 linux/drivers/media/video/cx88/cx88-video.c
>> --- a/linux/drivers/media/video/cx88/cx88-video.c       Tue Sep 09
>> 08:29:56 2008 -0700
>> +++ b/linux/drivers/media/video/cx88/cx88-video.c       Wed Sep 24
>> 20:35:46 2008 +0200
>> @@ -1152,7 +1152,8 @@
>>        file->private_data = NULL;
>>        kfree(fh);
>>
>> -       cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
>> +       printk("Don't set standby mode! TUNER_SET_STANDBY NO SIR!");
>> +       //cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
>>
>>        return 0;
>> }
>>
>>
>> This fixed it!!
>>
>> I don't know what side effects this will have. Or if this is caused  
>> by
>> wrong use of v4l by mythtv, or driver not implementing it correctly.
>> Those who know the codebase can maybe answer that and come up with a
>> better permanent solution.
>
> I admit I found your fix interesting. In fact, you can reproduce
> this using tvtime and cat.
>
> Eg.
>
>> tvtime -d /dev/video0 &
>> cat /dev/video0

It's a big hack yes. It was easier to change and test the driver  
instead of mythtv. Smaller code base and easier to compile and install.

> The problem in mythtv appears to be in OpenV4L2DeviceAsInput(void)
> where is opens the video device twice although I have no confirmed it.

A ticket in mythtv someone else had with open twice:
http://svn.mythtv.org/trac/ticket/5711
It was closed because it was a feature request without a patch.

I don't know if it's related to my problem or not.


Anders


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Janne Grunau]

On Wednesday 24 September 2008 21:09:42 Darron Broad wrote:
> The problem in mythtv appears to be in OpenV4L2DeviceAsInput(void)
> where is opens the video device twice although I have no confirmed
> it.

If that's the case and the tvtime && cat test supports it it's more a 
driver issue than an issue in mythtv. Using different fd for 
controlling (ioctl) and data transfer (read) is fine and works with 
other drivers.

Janne

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Darron Broad]

In message <200809242204.09153.janne-dvb@grunau.be>, Janne Grunau wrote:

lo

>On Wednesday 24 September 2008 21:09:42 Darron Broad wrote:
>> The problem in mythtv appears to be in OpenV4L2DeviceAsInput(void)
>> where is opens the video device twice although I have no confirmed
>> it.
>
>If that's the case and the tvtime && cat test supports it it's more a 
>driver issue than an issue in mythtv. Using different fd for 
>controlling (ioctl) and data transfer (read) is fine and works with 
>other drivers.

What we are seeing here is in cx88-video and doesn't seem specific
to any cx88 card as such but I don't have any other card to test
therefore there is no evidence either way that this is a hvr-4000
only problem as yet, but more tests ought to be done.

As far as that function is concerned, my point is that it
appears to be raising the fault.

When testing tvtime & cat /dev/video0 what occurs is an
an open, EBUSY read, then a release. The release here
always puts the tuner in standby whether the previous
read was valid or not. This seems to be the bug as previously
pointed out.

cya!

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Darron Broad]

In message <48DA94F7.1090005@linuxtv.org>, Steven Toth wrote:

Hi guys

>Anders Semb Hermansen wrote:
>> Den 24. sep.. 2008 kl. 19.20 skrev Darron Broad:
>> 
>> <snip>
>> 
>>> <snip>
>>>> Does this mean that mythtv is doing something weird or maybe just
>>>> using the v4l api in a different way which the driver cannot handle?
>>> This is feasable. I will take a look if I get the time but this
>>> is more than likely to be when I have other reasons to look
>>> at mythtv so don't expect an immediate response :-)
>>>
>> 
>> I did some more investigating.
>> 
>> I thought maybe this had something to do with the tuner, since I got  
>> snow. So I enabled debugging for the tuner module (debug=1). What I  
>> saw was that when I started watching TV in myth, there was a  
>> TUNER_SET_STANDBY after frequency and other things was set. This  
>> TUNER_SET_STANDBY did not appear when I was just changing channel (and  
>> picture worked).
>> 
>> So I searched the driver for TUNER_STANDBY and found one which I  
>> tried. Here is what I did:
>> 
>> diff -r e5ca4534b543 linux/drivers/media/video/cx88/cx88-video.c
>> --- a/linux/drivers/media/video/cx88/cx88-video.c       Tue Sep 09  
>> 08:29:56 2008 -0700
>> +++ b/linux/drivers/media/video/cx88/cx88-video.c       Wed Sep 24  
>> 20:35:46 2008 +0200
>> @@ -1152,7 +1152,8 @@
>>          file->private_data = NULL;
>>          kfree(fh);
>> 
>> -       cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
>> +       printk("Don't set standby mode! TUNER_SET_STANDBY NO SIR!");
>> +       //cx88_call_i2c_clients (dev->core, TUNER_SET_STANDBY, NULL);
>> 
>>          return 0;
>>   }
>> 
>> 
>> This fixed it!!
>> 
>> I don't know what side effects this will have. Or if this is caused by  
>> wrong use of v4l by mythtv, or driver not implementing it correctly.  
>> Those who know the codebase can maybe answer that and come up with a  
>> better permanent solution.
>
>Anders, thanks for helping debug this. :)
>
>This will have odd side effects for other boards. It's an interesting 
>fix and it points us to the real issue, but we need to find a better way 
>to clean this up, before we submit for merge.
>
>The HVR4000 is a very strange board, we need to be careful when adding 
>generic changes into cx88-*.c that are not conditioned based on (board 
>== HVR4000)
>
>I welcome your patches, if you find anything else that's odd/strange 
>then let's discuss those also. Your help is very much appreciated.

Two issues have been found with what's been highlighted here.

One has been discovered in cx88-video and another in mythtv.

You will be happy to know that both are fixed.

You can find the mythtv fix here:
	http://dev.kewl.org/v4l-dvb/TVRec_TuningNewRecorder_mythtv-0.21-fixes-18432.diff

The cx88-video fix is also available in the same directory:
	http://dev.kewl.org/v4l-dvb/v4l-dvb-cx88-atomic-9029.diff

>From what I can see, only the former is necessary in your case but
you can apply the latter if you wish.

cya!

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Anders Semb Hermansen]

Darron Broad wrote:
> Two issues have been found with what's been highlighted here.
> 
> One has been discovered in cx88-video and another in mythtv.
> 
> You will be happy to know that both are fixed.
> 
> You can find the mythtv fix here:
> 	http://dev.kewl.org/v4l-dvb/TVRec_TuningNewRecorder_mythtv-0.21-fixes-18432.diff
> 
> The cx88-video fix is also available in the same directory:
> 	http://dev.kewl.org/v4l-dvb/v4l-dvb-cx88-atomic-9029.diff
> 
> From what I can see, only the former is necessary in your case but
> you can apply the latter if you wish.

Thanks Darron. I'll guess I wait and see what happens with:
http://svn.mythtv.org/trac/ticket/5744

With working analogue I can look forward to November 11th when DVB-T 
broadcast begins in my area in Norway.


Thanks again,
Anders

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Jens.Peder.Terjesen]

>Anders Semb Hermansen wrote:
>Thanks Darron. I'll guess I wait and see what happens with:
>http://svn.mythtv.org/trac/ticket/5744
>
>With working analogue I can look forward to November 11th when DVB-T
>broadcast begins in my area in Norway.
>
>
>Thanks again,
>Anders

I thought that the analogue and DVB-T on this card was quite separate
parts?

The DVB-T broadcast has probably already begun. At least it has in my part
of Norway where the official date is also November 11th.

Jens


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Anders Semb Hermansen]

Jens.Peder.Terjesen@devoteam.com wrote:
> I thought that the analogue and DVB-T on this card was quite separate
> parts?

I think so yes.

> The DVB-T broadcast has probably already begun. At least it has in my part
> of Norway where the official date is also November 11th.

I used w_scan yesterday and it returned results. I used scan to get a 
channels.conf which looks ok (don't have it here, I'm at work). But I 
could not manage to get it to play. I don't know if this is because of 
software not supporting frontend1 (DVB-T is on 
/dev/dvb/adapter0/frontend1), frontend0 is DVB-S or if it does not 
support the digital standard in norway yet. I tried to play using 
mplayer directly, and dvbstream with a pipe to mplayer (seems mplayer 
does not cope with different frontend).

Any suggestion on how to go forward from here is appreceated.


Anders

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] HVR-4000 and analogue tv

[Jens.Peder.Terjesen]

-----linux-dvb-bounces@linuxtv.org wrote: -----

>To: Jens.Peder.Terjesen@devoteam.com
>From: Anders Semb Hermansen <anders@ginandtonic.no>
>Sent by: linux-dvb-bounces@linuxtv.org
>Date: 29-09-2008 11:40
>cc: linux-dvb@linuxtv.org
>Subject: Re: [linux-dvb] HVR-4000 and analogue tv
>
>Jens.Peder.Terjesen@devoteam.com wrote:
>> I thought that the analogue and DVB-T on this card was quite
>separate
>> parts?
>
>I think so yes.
>
>> The DVB-T broadcast has probably already begun. At least it has in
>my part
>> of Norway where the official date is also November 11th.
>
>I used w_scan yesterday and it returned results. I used scan to get a
>
>channels.conf which looks ok (don't have it here, I'm at work). But I
>
>could not manage to get it to play. I don't know if this is because
>of
>software not supporting frontend1 (DVB-T is on
>/dev/dvb/adapter0/frontend1), frontend0 is DVB-S or if it does not
>support the digital standard in norway yet. I tried to play using
>mplayer directly, and dvbstream with a pipe to mplayer (seems mplayer
>
>does not cope with different frontend).
>
>Any suggestion on how to go forward from here is appreceated.

This is about as far as I have come too.

I know that Kaffeine handles multiple frontends, but not sure about the
support for Norwegian DVB-T.
When I scanned with Kaffeine a few weeks ago it found only one of 24
channels, but there was no picture or sound. Not sure if this was because
the one channel it found is one of the encrypted ones.

I later patched and compiled DVB-apps, and this version of scan seemed to
be outputting correct information, but I am not sure if this can be used by
Kaffeine.

Jens


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb