If WMP thinks it's feeding a real sound card, it will probably itself be running at an elevated priority, perhaps even "Realtime" priority. So if Tunebite's transcoder is running at a lower priority, it will get starved out completely in the case of too many WMPs, its buffers will overflow and the audio will go glitchy.
I am pretty sure I have found the root of the problem.
After five failures night before last, in which the program started feeding all 18 threads simultaneously into the speakers even though it was supposedly muted, I noticed that every time this happened it was right at the point where one thread had finished a file and was loading up the next one. A little bit of experimenting showed that if the total job contained no more files than the total number of allowed streams, there were no failures, no corrupted files. This afternoon I experimented with a 28-file, 28-stream job (28 being the maximum number of streams that the program will allow) and it went off without a hitch.
Surprisingly, CPU usage was the same as if I were running just 15 streams -- about 37%. Memory usage was way up, holding steady about 80%.
So, it looks like the way to make this work is to run 28-file batches, and reload every hour and a quarter, rather than create a batch of 150 files and let Tunebite work its way through them. It is apparently the transition from completed file to the next file in line that is causing the problem.
tanstaafl.
Previous Topic
Index
