hang / crash batch converting too many albums from FLAC to AAC-TVBR

[GoogleCodeExporter]

What steps will reproduce the problem?

1. configure as follows (all steps may not be necessary)
2. set output format to MPEG-4 AAC (True VBR, Max, Auto, Q95, add gapless, 
accurate bitrate, embed cue sheet)
3. set output directory different from input
4. maximum threads 3, priority normal (this is on a quad-core i7)
5. enable preserve directory structures
6. set subdirectory search depth to 0 (unlimited)
7. restrict files to .flac
8. automatically split file
9. open a directory with many sub-directories containing .flac+.cue

How about the reproducibility (always, sometimes, rarely, ...)?

This happens every time that I select "too many" sub-directories.  I haven't 
determined what that exact threshold is, but it seems to be somewhere between 
109 and 151 sub-directories.

What is the expected output? What do you see instead?

If I select just the 42 sub-directories that start with "A", or just the 109 
sub-directories that start with "B", the batch conversion proceeds as expected, 
splitting .cue+.flac from one directory into .m4a in another directory.  
However, if I select all 151 sub-directories that start with "A" or "B" the 
program hangs after starting to convert the first three tracks.  I waited a 
long time for a couple of the conversion attempts.  I'll attach a .hang file 
from /Library/Logs/DiagnosticReports that resulted from a relatively short hang 
(i.e., I killed the program after less than a minute).

What version of the product are you using? On what operating system?

I'm using XLD 20140504 (147.0) on OS X 10.9.5.

Please provide any additional information below.

I found a couple of bug reports like this in which the cause was thought to be 
a problem parsing some metadata.  However, that doesn't seem to explain what 
I'm seeing, in which I can convert A or B separately, but not A and B together 
in one batch.

Original issue reported on code.google.com by jon.will...@gmail.com on 29 Oct 2014 at 4:18

Attachments:

• XLD_2014-10-28-174414_iSpegel.hang

[GoogleCodeExporter]

I gave this another try with sub-directories "M" through "Z".  After hanging 
for about an hour, XLD proceeded to convert as expected.  There is no evidence 
of a crash, but XLD hangs, completely unresponsive, for a very long time.

Original comment by jon.will...@gmail.com on 30 Oct 2014 at 8:42

[GoogleCodeExporter]

Exact same issue here, file encoding freeze on some files at 99,9% for a long 
while then continues.
I tried to encode the same directory several times (144 Files), and it froze on 
different files each time.
The problem may be related to multithreading, on my iMac 2013 under Yosemite 
with 8 threads it starts freezing very quickly, with 3 thread freeze come later 
and are a lot shorter

Original comment by aleen.in...@gmail.com on 17 Jan 2015 at 9:06

[GoogleCodeExporter]

For those who have 99% hang issue, set XLDAlacOutputUseDiskCache 
(XLDAacOutputUseDiskCache) key to true in Info.plist of the plugin .bundle

Original comment by tmkkmac on 18 Jan 2015 at 2:51