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/ |