<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi, Nick and Brian.<br>
<br>
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.<br>
<br>
I think something happens when I record from a schedue instead of the
recording from LiveTV. <br>
<ul>
<li>I've just made this test: started watching a show on LiveTV
(perfect) for 5 mins</li>
<li>stopped watching, copied the mpeg to my PC (plays perfectly on
VLC)</li>
<li>started a recording on the same channel, same show</li>
<li>the scheduled recording shows the usual signs of "damage" (strips
box shaped of green "noise")</li>
<li>if I copy the file to my PC the file shows the same corruption
when payed in VLC</li>
</ul>
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.<br>
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.<br>
<br>
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.<br>
<br>
Any ideas ?<br>
<br>
Thank you all for the time and the support !<br>
<br>
Best regards,<br>
Paolo<br>
<br>
P.S.<br>
Following there's the output from top in the two scenarios.<br>
<br>
Output from top during LiveTV<br>
<pre>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
</pre>
Output from top during schduled recording<br>
<pre>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
</pre>
<br>
<br>
<br>
<br>
Nick Morrott ha scritto:
<blockquote
cite="mid:5387cd30806211403vc0f61cak16d80905691a65ab@mail.gmail.com"
type="cite">
<pre wrap="">On 21/06/2008, Paolo Asioli <a class="moz-txt-link-rfc2396E" href="mailto:paolo.asioli@libero.it"><paolo.asioli@libero.it></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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 ?
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
</blockquote>
<br>
</body>
</html>