(Yet another) The iTunes Library file cannot be saved

Thanks for the reply tt2. Firstly, I forgot to include that the error was the good old 'An unknown error occurred(-50).

I'd disabled my AV and malware programs and also turned off search indexing - I'd read a lot of the previous posts on the topic from over the last few years, so I'd started with the usual suspects.

I'd kinda done the 'wait element' by stopping it and the restarting manually a short time later, once I'd selected another batch (so a good 30-40 seconds delay for the system to settle) - see my note about doing two batches of 1200 (I didn't explicitly state that I didn't shut iTunes down between these two - sorry).

I had a mere 2090 songs left to update, so I selected those and set Windows ProcMon running again, also watching the Resource Monitor. When it inevitably crashed, I could see from the Resource monitor that it was only reading from the Music library - not an exact science, as it averages out read/write load, but it does however help us humans not to miss things :-) .

Nothing jumped out of the Windows system/error logging either.

I then set about scouring the ProcMon logs, to see if any needle jumped out of the haystack, and I spotted one potential issue that appeared to happen just around the time it threw the error (iTunes continued to write events, so it was a bit of guesswork at the exact second). If I filtered to the 'Process Profiling' operation, I spotted that the memory use (?) had suddenly peaked (for iTunes.exe) with it jumping from a normal max of around 'Private Bytes: 1,010,106,368' to 'Private Bytes: 1,595,568,128'. I was actually hoping to see an overly large .tmp file being created, but it never seemed to 'get out of hand' (for want of a more technical expression).

This was the last few minutes (of a 30 minute or so run) before it threw the error:

Now, I can honestly say that a) I may be clutching at straws, and b) I don't really know what those figures relate to without doing some reading (see below*), but they do stand out to me, but I will try some more testing to prove my gut feeling that iTunes throws a wobbly internally if given too many successive changes without a break.

*Private Bytes refer to the amount of memory that the process executable has asked for - not necessarily the amount it is actually using.

They are "private" because they (usually) exclude memory-mapped files (i.e. shared DLLs). But - here's the catch - they don't necessarily exclude memory allocated by those files. There is no way to tell whether a change in private bytes was due to the executable itself, or due to a linked library. Private bytes are also not

exclusively physical memory; they can be paged to disk or in the standby page list (i.e. no longer in use, but not paged yet either)

...

Private Bytes are a reasonable approximation of the amount of memory your executable is using and can be used to help narrow down a list of potential candidates for a memory leak; if you see the number

growing and growing constantly and endlessly, you would want to check that process for a leak. This cannot, however, prove that there is or is not a leak.

turingtest2 wrote:

Do you have any third party security software? This can disrupt the way that iTunes saves the library. Can you add some wait elements in your script to allow iTunes to do some housekeeping before you fire another batch of requests at it?

tt2