TMPGenc 4.0 Express Stalling Halfway thru 2nd Pass AVCHD to MPEG2 Conversion

[BassPig]

We're stuck on Adobe Premiere CS3 because CS4 would not run smoothly on our editing boxes. We have a need for an ultra small camera that fits in a tiny nook in the orchestra shell, so we've been using a small AVCHD-based camera, a Canon HF-S200 for a fixed medium shot of the conductor. The rest are XDCam EX format cameras, which are no problem.

In November, we discovered that TMPGenc 4 would convert the 12 or so AVCHD (.MTS) files in about 2 hours, to MPEG2 that edits nicely in CS3. We used it for November, December and March concerts without a problem.
However, with the footage we shot last night, TMPGenc 4 runs normally through the first pass, then starts the 2nd pass and at some point in the 2nd pass, the CPU usage drops to 25%, down from 100% and further progress in transcoding stops. 12 hours later, it's still working on the same 11 minute clip as it started. The program's priority drops to "lowest" in Task Manager (Win XP). Even if I change it to Normal, or even Realtime, it bumps back to Lowest after a minute. Encoding speed and CPU utilization never budges above 25%.

Before we try reinstalling the program, I thought I'd toss out the problem and see if anyone has any obvious solutions.. maybe the template that always worked before has somehow become corrupted? I don't know. What could be slowing it down?

[setarip_old]

Hi!

You might want to check to see if your system is overheating (and might be in need of cleaning) and/or whether you may have developed bad RAM.

As an experiment, shut down your system for an hour or so, cold reboot and try the same job...

[BassPig]

Interesting point.. although the system was vacuumed out 2 weeks ago during a routine cleaning. However, it was 65°F during the winter months and now it is 67°F here in April. The CPUs are floor-mounted, so it may have been even cooler than that in January.

I did some exploring of the parameters and did find one thing that was suspicious--½-pixel motion search was checked. I unchecked that option and was able to render one of the AVCHD clips in about 23 minutes. However, another clip is taking 1h28m and still processing. All clips are the same length--all FAT32-limited segments written to SD card. There are 12 of them in all for the 2 hr concert. The CPU cooling fan speed is temperature controlled. It slowed down to idle speeds when TMPGenc slowed down its processing. When the clip first started processing, CPU usage was 100% and the fan was revving at high speed. It is easy to hear it revving up and down with CPU load.

Normally, a 2 hr batch of clips would convert in about 4 hrs time. But this is now 27 hours later and I'm not even halfway through. :(

[BassPig]

20 more frames encoded in the past 20 minutes.. frame 14387 of 15214 frames, file one of 12. At this rate, it will take about 1400 years to encode the whole 2 hour segment. I keep bumping the priority up and 5-10 seconds later, it's bumped down to low, 7 levels below the highest. I didn't know programs had the authority to set the thread priority. Odd.

[BassPig]

Have installed TMPGenc 4 on another identical quad core workstation. Started batch encode with same parameters.. first two files encoded in 16 minutes.. then, 58% through the third file, I heard the CPU fan drop to idle speed. Task manager shows the CPU utilation dropped from 100 to 25%. No further frames have been encoded, even though 15 minutes have passed since the slowdown. Task priority went from Normal to Low in Task manager. Even if I bump it up to Realtime, transcoding doesn't go any faster. It seems to have ground to a halt--just like with workstation #2 above. The odd thing is there is still a flickering disc I/O LED. But after 18 hours of disc activity, it could have written many terabytes of data, but it's written nearly nothing. This is baffling.

[setarip_old]

written to SD cardPerhaps a/the card is damaged or contains corrupted data?

Have you confirmed that your source material (cards and/or data) isn't problematic?

[BassPig]

Good point, but would ALL 12 clips be corrupted? I can try playing them in VLC Media Player and see if they're good.. the camera has always written good files before.
Workstation #2 is 11 hours into the first clip and TMPGenc estimates over 6 more hours til that 11 minute clip is transcoded.
Workstation #1 finished the last 3% of the clip it was working on since yesterday afternoon and is now in the second pass of the clip following it.
Both workstations are showing heavy disc access on their RAID0 arrays, which is odd for a program that's doing nearly nothing. I haven't seen this kind of disc activity outside of moving 30GB XDCam file from one drive to another. But in 11 hours, with that much writing, all of the discs on the system would be filled to capacity. CPU is idle, but disc I/O is off the wall crazy now. Since Saturday night, I've managed to transcode six 11-minute AVCHD clips to MPEG2. Coming up on 38 hours of total encoder run time ON TWO MACHINES. Actually 49 hours of machine time when one takes the second machine into account.

Besides playing the original clips in VLC, how else can I confirm whether or not they're corrupted.. and.. all 12 of them corrupted equally? That seems unlikely.

[setarip_old]

Started batch encode with same parameters..And if you DON'T batch process the files, do you get the same problematic results? - Or, perhaps, does only one file/card prove to be a problem?

[BassPig]

I fired up a third machine, and fed TMPGenc one file at a time on that machine and it completed each conversion in about 16-20 minutes. However, that machine has over 500GB free space. The other two machines only have 58GB and 47GB free space on the temp drives, respectively. Maybe 58GB is not enough space for TMPGenc to work efficiently? I noticed a lot of heavy disc access this afternoon on both of the "slow" machines, during the last half of the 2nd pass. It seems absurd that 58GB would not be enough space to work in, but disc space is really the only advantage that workstation #3 has.. it has half the RAM but 10X the free space.

[setarip_old]

Whether you think "it seems aburd" or not, you seem to be ignoring the distinct possibility that I have pointed you toward:

Use one file at a time on each of the systems with small drives - and if they don't slow down, you have your answer ;>}

[BassPig]

Think perhaps that TMPGenc is not releasing the memory for each transcode session in the batch and is cumulatively using more memory/disk?
Still unsolved is why it worked (batch mode) for almost identical jobs from November to March.
Although the job is complete now, I will test one at a time encoding just to try and isolate the issue. That it was working just a month ago still is unsettling though. Not much change in disk space since then.

[mpucoder]

Graphics programs use a lot of large temporary memory blocks, usually more than can fit in physical memory. What you describe sounds like virtual memory thrashing - reading and writing data to rearrange it in physical memory and on a limited swap file. It doesn't take a very big change in available disk space to throw off the virtual memory system. All it takes is one file allocated in the wrong spot to inhibit growing the swap file. Try defragmenting the disk that holds the swap file. Also make sure that Windows is allowed to manage the swap file, and that it is not locked to a specific size or device.

[Emulgator]

Almost all has been mentioned.

If an application works on an empty HDD, but stalls on an almost full HDD,
still simple defragging comes into my mind.

Maybe the last successful defrag has been more than a year ago,
Gigabyte chunks of video will suffer from heavy fragmentation when one repeatedly reaches 70..80% HDD fullness.
Those 58 GB may well be available in very small portions only already after 10..20 cycles of repeated writing.
Heavy positioning noise will tell how often a distant sector had to be accessed.

What I have to do every 3 months on at least half of my video HDDs:
Moving all files to some other HDDs, to free the source HDDs, doing a full erase and reformat there,
then playing files back in single chunks.

Or freeing at least half of each HDD, then running something like MyDefrag (free) or O&O Defrag ($)