LinHES Forums
http://forum.linhes.org/

DVD creation SLOW, only using 5% CPU (Workaround found)
http://forum.linhes.org/viewtopic.php?f=6&t=16832
Page 1 of 1

Author:  cliffsjunk [ Tue Oct 02, 2007 4:01 pm ]
Post subject:  DVD creation SLOW, only using 5% CPU (Workaround found)

While creating a DVD, mytharchive and ffmpeg combined don't take more
than 4-5% of the CPU, leaving about 95% idle (it is not 'waiting', it
is 'idle').

I am trying to move some old recordings off to DVD (the stand alone
player kind of DVD, not the native archive kind). I'm guessing these
recordings were made under R5E50 from their dates.

I loaded and edited the cutlists with R5F27. I started up Mytharchive to
burn them to a DVD. I ssh'ed in and viewed the processes with top.

I haven't seen this problem under R5F1, although R5F1 had mytharchive
problems with both the cutlist and the "jacked up" recording profile I use.

What would make the DVD creation process avoid using 100% of the CPU?

Edit: I notice that mythtranscode is continually allocating memory. Top
says it is up to 1300m (1.3 gig?) virtual memory and continuously
allocates at a rate between 0.3 and 1.0 meg per second.

Edit: Something funny is going on. Mythtranscode virtual memory is up to
2000m, but the growth is not being reflected in the swap file usage.

Cliff

Author:  cecil [ Tue Oct 02, 2007 8:19 pm ]
Post subject: 

If you suspect an issue, then reporting the bug on svn.mythtv.org. Check the docs for details on bug submission.

Author:  mogator88 [ Tue Oct 02, 2007 8:26 pm ]
Post subject: 

run top and check the "NI" column. This is the "nice" setting. Negative numbers mean more CPU time, higher numbers means less CPU time. The range is -15 to 19. Login as root and run the command:

renice -10 PID

Where PID is the process ID from the first column. You should see CPU % go up. Post back with how it affects your burning.

Author:  cliffsjunk [ Tue Oct 02, 2007 9:01 pm ]
Post subject: 

"Try renice'ing it to a higher (lower numerically) priority."

I had already tried that and besides, the CPU is 95% idle. Even very low
priority tasks get to run if there is nothing else wanting to run...

Cliff

Author:  tjc [ Tue Oct 02, 2007 9:04 pm ]
Post subject: 

If the CPU isn't busy then most likely it's IO bound. Have you checked the DMA on the drives?

Author:  cliffsjunk [ Wed Oct 03, 2007 7:52 am ]
Post subject: 

tjc wrote:
If the CPU isn't busy then most likely it's IO bound. Have you checked the DMA on the drives?


I believe if that were the case then the CPU would be "waiting" as
opposed to "idle".

Just for grins I ran hdparm on all the hard drives and indeed they are
all using dma, so that isn't the problem.

In the mean time I have tried:
- other recordings from the same channel and week. About half have this issue and half don't.
- changing mythtv-setup to allow more processes and High cpu usage.
- mythcommflag -f file --rebuild (rebuild the seek table).
- no fifos.

Is it even OK to record straight to MPEG4 without a transcode step as I do?

Cliff

Author:  cliffsjunk [ Sat Oct 20, 2007 9:11 pm ]
Post subject:  Work around found...

I believe that I have a work around for my problems. Two things need to
be fixed:

The fps value that /usr/share/mythtv/mytharchive/scripts/mythburn.py
calculates is wrong. Sometimes it is the reciprocal of what it should be.
Sometimes it is double what it should be (for programmers listening it is
possible it was half the reciprocal since the fix I was running at the time
simply took the reciprocal of the fps value if the fps looked bad).

in the aforementioned mytyburn.py replace this code:
Code:
    fps = video.attributes["fps"].value

    return (videores, fps, aspect_ratio)


with this code:
Code:
    #fps = video.attributes["fps"].value

    """cliff added this to fix bad fps value"""
    """fps is correct sometimes"""
    """fps is sometimes the reciprocal"""
    """fps is sometimes double or possibly half the reciprocal"""
    """fps may need to be 25.00 something else outside the USA"""
    fps = 29.97

    return (videores, fps, aspect_ratio)


The lines starting with """ are just comments. I put my name in there
so I could find the lines in the future.

I believe that the fps value is the fps of the display device that the DVD
will be played on, so PAL systems will probably need 25.00 or 23.976 or
some other strange value.

It appears that this bad fps value (when it is twice what it should be) is
what causes ffmpeg to only use 3% of the CPU, which causes it to take
maybe 30 times longer than it should to create the DVD files before
burning the DVD.

Secondly and very important (since you are using cutlists in your burn) is
to make sure that each recording starts with a cut.

Not starting each recording with a cut appears to be a cause of the DVD
creation stopping with an error before even burning.

Cliff

Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/