That is backwards. If anything, live should be more as it is
both recording and playing back.

My PVR-350 Athlon 1400 R5.5 system watches live SD tv at
2% to 3% CPU for mythfrontend and mythbackend combined.
You can seek around while it is live and after settling down the
CPU is back at 2% to 3% total.

Later when you watch the same show as a completed recording
it takes 15% to 20% CPU, with higher spikes. I can even do a
stop recording and immediately watch it and it jumps from the
2.5% of live to the 15% to 20% of recorded.

I am trying to get this as efficient as possible with an eye
toward playing more media without jerkiness.

I have transcoding turned off. That shouldn't matter anyway.
My recording profiles are all the same. That shouldn't matter
anyway.

I tried setting the "Video Playback Profile" to "CPU--" to see if
forcing it to use the ivtv driver would change it, but I basically
got the same results. This uses 12% live and 24% recorded. I
think it uses the ivtv driver regardless since I have told it to
use the PVR-350 decoder output and the numbers go higher
yet (37% live combined with about mfe=26 X=10 and mbe=2
50% recorded with about mfe=41% and X=9%) when I turn
PVR-350 decoder off.

Is this because it reads a recording as a file but the live
comes thru a network socket? If so the combination of
backend and frontend is more efficient that the frontend alone.
I have noticed this behavior while troubleshooting inability to
watch recorded shows, where I can watch live shows...
across a network connection where there was no user=mythtv
permission to read /myth. Doing a network mount of local
/myth to the backend /myth and giving read permission to
user=mythtv allowed it to watch recordings too. I also notice
that live uses about equal amounts of mythfrontend and
mythbackend, but recorded uses basically 0 mythbackend.)

Is this because it knows it can't skip commercials in live tv?

Of course this isn't a show stopper, but I would like to have
it running as efficiently as possible to avoid frame dropping
and jerkiness.

How does your "live" TV recording profile compare to the one used for your recordings? If they've got different resolutions I'd immediately suspect that is putting you into different playback modes.

I strongly recommend creating a custom playback profile with exactly one entry in in and set it to the same methods you were using in R5F27, and making that your default. This removes any ambiguity about what it's doing and lets you focus on finding a working set of playback parameters.

because I tested with the same clip.
Once as live and then again as a recording.

I have started watching live TV, checked the CPU, got out
of live TV and immediately gone over and watched the clip
as a recording. Watching the clip as a recording uses more
CPU than that exact clip did when live. I have transcoding
turned off and have verified that I am simply watching the
*.mpg file that was produced from the live watching.

Also: I would guess that this was happening in R5F27 too.

EDIT: I created a custom playback profile with PVR-350
decoder, ivtv renderer, no deinterlacing, and no filters
and I get the exact same results.

Thanks
Cliff

Is your storage local (not on a NFS or Samba mounted FS) and "fast" (PATA/SATA rather than USB)? What I'm think is that live TV might still be in the buffers when the FE tries to read it thus saving a round trip to slower storage.

Yes.

I had considered local buffering too. Seeking around in the live
stream (say a 5 minute clip) always seems to come back to
2.5% and immediately after determining that I can "stop
recording" and come back and play it as pre-recorded. It
seems that no matter what I do after that (like seek away and
seek back to where I just played) it is 20%. I will grant you
though that I have a gig of RAM and that (say the extra
512meg) could be buffering 15 minutes of my mpeg2.

This appears to be a known factoid. I found a setting that
enables you to force it to use the "efficient" way, so I at least
have the option of running it the more efficient way.

-> Setup
-> TV Settings
-> Playback
-> General Playback (1/9)
-> Always stream recordings from the back end

I will try this and see if it is "more efficient" like right after a
reboot and the first watching of a recording.

I have noted that there is a definite difference in the idle
percentage under top too, but I suppose it is possible that
there is more than one way of reading from the disk and that
one (say a non-blocking read) looks more efficient as it shows
up as idle rather than waiting.

Cliff

"Setup -> Always stream recordings from the back end"
did not help.

Another data point: Watch 1 minute of live TV and it averages
93% idle. Escape out and immediately go watch the same clip
in "Media Library -> Watch Recordings" and it averages 78%
idle. This is backwards two ways:
- it takes less CPU to record and playback than it does to just
play back
- if there is buffering going on it should be buffered the second
time and not the first

Another fact: It is always mythfrontend that uses the extra CPU.

I can imagine that writing could be implemented with less
waiting than reading and that the backend buffers better,
or perhaps it is a matter of the frontend knowing that it
can't commercial skip a live recording and so doesn't have
to keep track of absolute position in stream. I tried turning
off commercial skip and it didn't help either, even turning it
off in setup.

Thanks for your help TJC, but I think we have hit a dead end
and I don't think it is worth spending further time on it.

Cliff