[mythtv-users] Problem: LiveTV ok, recordings are crappy

Paolo Asioli paolo.asioli at libero.it
Sun Jun 22 06:56:33 UTC 2008


Hi, Nick and Brian.

I have two DVB-T Hauppauge USB Stick. They worked perfectly until a week 
or so ago I upgraded my Ubuntu and with it MythTV.

I think something happens when I record from a schedue instead of the 
recording from LiveTV.

    * I've just made this test: started watching a show on LiveTV
      (perfect) for 5 mins
    * stopped watching, copied the mpeg to my PC (plays perfectly on VLC)
    * started a recording on the same channel, same show
    * the scheduled recording shows the usual signs of "damage" (strips
      box shaped of green "noise")
    * if I copy the file to my PC the file shows the same corruption
      when payed in VLC

No error shows in the console where I launched the frontend where I 
launched mythfrontend and no errors show in the log or in dmesg.
Something strange happens when I launch the recording: when I watch 
LiveTV the load is fairly high but wait % is very low and stays most of 
the time to 0% and the mythbackend uses 15-20% of the CPU, while when 
recording from schedule mythbackend uses around 10% CPU and there's 
always a >0% of wait state processes.

It's like when the recording is scheduled the process recording gets a 
lower priority than when watching LiveTV and can't keep up with the MPE2 
stream coming from the DVB-T card.

Any ideas ?

Thank you all for the time and the support !

Best regards,
    Paolo

P.S.
Following there's the output from top in the two scenarios.

Output from top during LiveTV

top - 08:48:19 up 1 day,  8:20,  6 users,  load average: 2.15, 1.07, 0.63
Tasks: 137 total,   2 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s): 45.9%us, 29.6%sy,  0.0%ni, 14.0%id,  0.0%wa,  0.0%hi, 10.5%si,  0.0%st
Mem:    482600k total,   476840k used,     5760k free,     4596k buffers
Swap:  1951888k total,   132060k used,  1819828k free,   237216k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15598 paolo     20   0  332m  71m  27m S 63.7 15.2   1:14.45 mythfrontend
 6119 mythtv    15  -5  254m  50m 9824 S 14.7 10.7  30:17.42 mythbackend
15566 paolo     20   0 10376 3040 2312 S  7.0  0.6   0:07.32 smbd
15612 root      20   0  2208 1100  824 R  1.3  0.2   0:02.00 top
   41 root      15  -5     0    0    0 S  0.6  0.0   0:07.04 kblockd/0
  141 root      15  -5     0    0    0 S  0.6  0.0   0:52.56 kswapd0
 6583 root      20   0  167m  34m 8148 S  0.6  7.2  49:25.74 Xorg
 5575 mysql     20   0  127m  10m 3272 S  0.3  2.2   9:26.74 mysqld
    1 root      20   0  2752  520  464 S  0.0  0.1   0:06.22 init
    2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
    4 root      15  -5     0    0    0 S  0.0  0.0   0:00.48 ksoftirqd/0
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.04 watchdog/0
    6 root      15  -5     0    0    0 S  0.0  0.0   0:02.62 events/0
    7 root      15  -5     0    0    0 S  0.0  0.0   0:00.04 khelper
   44 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
   45 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kacpi_notify


Output from top during schduled recording

top - 08:53:12 up 1 day,  8:25,  6 users,  load average: 0.83, 1.21, 0.82
Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie
Cpu(s): 14.0%us,  9.4%sy,  0.0%ni, 74.7%id,  1.3%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:    482600k total,   477008k used,     5592k free,     8260k buffers
Swap:  1951888k total,   132064k used,  1819824k free,   216108k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6119 mythtv    15  -5  247m  51m 9824 S  9.1 11.0  31:04.43 mythbackend
15598 paolo     20   0  282m  67m  27m S  5.2 14.2   3:07.30 mythfrontend
 6583 root      20   0  164m  30m 4908 S  4.2  6.6  49:33.38 Xorg
 5254 root      15  -5     0    0    0 S  1.9  0.0   3:38.85 kondemand/0
15612 root      20   0  2208 1104  824 R  1.3  0.2   0:06.42 top
 5497 root      20   0  5808 1652 1348 S  0.6  0.3   0:38.11 cupsd
 5575 mysql     20   0  128m  10m 3276 S  0.6  2.2   9:30.84 mysqld
  141 root      15  -5     0    0    0 S  0.3  0.0   0:53.21 kswapd0
    1 root      20   0  2752  520  464 S  0.0  0.1   0:06.22 init
    2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
    4 root      15  -5     0    0    0 S  0.0  0.0   0:00.48 ksoftirqd/0
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.04 watchdog/0
    6 root      15  -5     0    0    0 S  0.0  0.0   0:02.64 events/0
    7 root      15  -5     0    0    0 S  0.0  0.0   0:00.04 khelper
   41 root      15  -5     0    0    0 S  0.0  0.0   0:07.28 kblockd/0
   44 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid






Nick Morrott ha scritto:
> On 21/06/2008, Paolo Asioli <paolo.asioli at libero.it> wrote:
>
>   
>>  I've tried yesterday evening to first watch some LiveTV (perfect) and then to record on the same channel. The recording was "damaged" and I didn't see any higher load on the machine during the recording. On the contrary, the machine was under higher CPU load during LiveTV since the frontend was playing back at the same time...
>>
>>  Do you know if any difference exists between recording for LiveTV ad recording for later view ?
>>     
>
> Paolo,
>
> What type(s) of capture card are you using? How many capture cards do
> you have in the machine? If you are using a DVB card, there is no
> difference between the recordings made in LiveTV and those made for
> scheduled recordings, as the recorded stream is already encoded into
> MPEG-2 when broadcast. For PVR-150/250/350/500 cards, and for bttv
> framegrabbers, you can choose the levels of compression/bitrate used
> in mythtv-setup for each recording profile.
>
> Do you see any errors in your mythbackend and mythfrontend logfiles
> (or console output) when playing back a damaged recording?
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080622/a3a13dd4/attachment.htm 


More information about the mythtv-users mailing list