I think there's something amiss here; suddenly I have a load average
of 3! This happens occasionally to me, and can be cleared by stopping
the player with Esc and watching something else.
I'm watching a prerecorded show, and it's supposed to be recording
something (I dunno what, there are always lots of things at 7pm), too:
19:29:03 up 2 days, 17:59, 1 user, load average: 2.95, 2.85, 2.44
CPU states: 98.4% user, 1.6% system, 0.0% nice, 0.0% idle
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
17085 tv 20 0 62228 52M 1892 R 29.7 21.0 7:08 mythfrontend
17124 tv 19 0 62228 52M 1892 R 29.7 21.0 4:16 mythfrontend
17128 tv 20 0 62228 52M 1892 R 29.7 21.0 11:52 mythfrontend
17087 tv 10 0 62228 52M 1892 S 5.7 21.0 1:17 mythfrontend
17127 tv 9 0 62228 52M 1892 S 2.3 21.0 0:52 mythfrontend
That "top" output is radically different from what it looks like when
I'm watching live TV. Then, there are several threads with distinctly
different CPU%, totalling right about 80%.
Similarly, when recording only, there is just one substantive thread,
and the total CPU% is right at 45%.
The actual picture (and no doubt the recording being made) is
unpleasantly jittery, not surprising given a load of 3.
It would be really nice if the threads had unique argv0's that
reflected what they're up to, then we could tell them apart in top.
I'm not sure where top gets argv0 from, and I dunno if clone'd threads
can even have distinct argv0 strings, but it would still be nice ;)
Looks like the tasks also share fd arrays. Hmm. I was hoping to
identify threads that way.
Here's a curiosity:
- There is one fd open on the thing being recorded right now.
- There are *TWO* fd's open on the old show being viewed. This seems
odd. Maybe it's decoding twice?
- There are four sockets and four pipes, which seems like more than
necessary to operate the X server and speak to the database.
Now, my wife stopped watching that, and started watching something
new; the recording has continued undisturbed. Now, it looks like this:
19:52:15 up 2 days, 18:22, 1 user, load average: 0.77, 0.82, 1.49
CPU states: 61.0% user, 1.8% system, 0.0% nice, 37.2% idle
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
17128 tv 19 0 45728 36M 3008 R 56.0 14.6 21:31 mythfrontend
17127 tv 10 0 45728 36M 3008 S 5.5 14.6 1:44 mythfrontend
17438 root 12 0 988 988 776 R 0.5 0.3 0:00 top
17407 tv 9 0 45728 36M 3008 S 0.1 14.6 0:01 mythfrontend
17408 tv 9 0 45728 36M 3008 S 0.1 14.6 0:00 mythfrontend
PIDs 17085 and 17124 are totally gone; they were evidently part of
the old player.
It's hovering around 35% idle, which isn't too far off from Isacc's
assertion that watching one thing while recording something else is
"easier" than watching live tv (for ~20% idle on my box). The old
show is playing nicely on screen, and the new recording file is
growing at a plausible rate. I can easily buy the 10% effort to play
appearance of the top two threads here...
Now with the new show, there are also a sensible two *.nuv fd's: one
each for the recording and playing shows.
--
Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/
of 3! This happens occasionally to me, and can be cleared by stopping
the player with Esc and watching something else.
I'm watching a prerecorded show, and it's supposed to be recording
something (I dunno what, there are always lots of things at 7pm), too:
19:29:03 up 2 days, 17:59, 1 user, load average: 2.95, 2.85, 2.44
CPU states: 98.4% user, 1.6% system, 0.0% nice, 0.0% idle
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
17085 tv 20 0 62228 52M 1892 R 29.7 21.0 7:08 mythfrontend
17124 tv 19 0 62228 52M 1892 R 29.7 21.0 4:16 mythfrontend
17128 tv 20 0 62228 52M 1892 R 29.7 21.0 11:52 mythfrontend
17087 tv 10 0 62228 52M 1892 S 5.7 21.0 1:17 mythfrontend
17127 tv 9 0 62228 52M 1892 S 2.3 21.0 0:52 mythfrontend
That "top" output is radically different from what it looks like when
I'm watching live TV. Then, there are several threads with distinctly
different CPU%, totalling right about 80%.
Similarly, when recording only, there is just one substantive thread,
and the total CPU% is right at 45%.
The actual picture (and no doubt the recording being made) is
unpleasantly jittery, not surprising given a load of 3.
It would be really nice if the threads had unique argv0's that
reflected what they're up to, then we could tell them apart in top.
I'm not sure where top gets argv0 from, and I dunno if clone'd threads
can even have distinct argv0 strings, but it would still be nice ;)
Looks like the tasks also share fd arrays. Hmm. I was hoping to
identify threads that way.
Here's a curiosity:
- There is one fd open on the thing being recorded right now.
- There are *TWO* fd's open on the old show being viewed. This seems
odd. Maybe it's decoding twice?
- There are four sockets and four pipes, which seems like more than
necessary to operate the X server and speak to the database.
Now, my wife stopped watching that, and started watching something
new; the recording has continued undisturbed. Now, it looks like this:
19:52:15 up 2 days, 18:22, 1 user, load average: 0.77, 0.82, 1.49
CPU states: 61.0% user, 1.8% system, 0.0% nice, 37.2% idle
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
17128 tv 19 0 45728 36M 3008 R 56.0 14.6 21:31 mythfrontend
17127 tv 10 0 45728 36M 3008 S 5.5 14.6 1:44 mythfrontend
17438 root 12 0 988 988 776 R 0.5 0.3 0:00 top
17407 tv 9 0 45728 36M 3008 S 0.1 14.6 0:01 mythfrontend
17408 tv 9 0 45728 36M 3008 S 0.1 14.6 0:00 mythfrontend
PIDs 17085 and 17124 are totally gone; they were evidently part of
the old player.
It's hovering around 35% idle, which isn't too far off from Isacc's
assertion that watching one thing while recording something else is
"easier" than watching live tv (for ~20% idle on my box). The old
show is playing nicely on screen, and the new recording file is
growing at a plausible rate. I can easily buy the 10% effort to play
appearance of the top two threads here...
Now with the new show, there are also a sensible two *.nuv fd's: one
each for the recording and playing shows.
--
Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/