Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ProblemChild]

This is the 3rd time I've tried to resync my 80G iPod and had MC hang up. The only changes are the upgrade to .380 and having upgraded iTunes after MC notified me about it. This last time I killed every non-necessary process and watched over most of the 40-hour process (I was moving/redoing my cache and most of my files are .ape(high); I'm using MC's option to convert unsupported/high bitrate files to mp3/vbr/extreme) - I had set a max of 3 simultaneous conversions. Everything looked fine until last night when around 8 hours were left - I looked via Process Explorer and saw MC w/only 2 lame processes. Then 1, later on. Now this morning the 'sync' is doing nothing but counting upward, telling me that more and more time remains. The detail reads that a single file is "converting..." but nothing is happening and process explorer shows nothing (ie it shows MC w/zero lame processes). MC hadn't hung up but still gave me no choice but to 'end' the sync.

After restarting MC it looks like most of 10000 files are there and I started to sync the remaining 300 (according to MC's list). Again, MC starts off spawning 3 lame processes and everything looks fine. This time it just hangs up.
Start still again, after starting to log. This time after 30-40 minutes it's going well then suddenly loses one of the lame processes again. MC keeps chugging along but only using 2. I *think* it's stuck on the same song as it was previously.

Is anyone else experiencing strangeness since upgrading either iTunes or MC.380?
Any ideas would be appreciated.

[ProblemChild]

Can someone tell me what filelength restrictions MC and/or lame have?
Could excessively-long filenames be causing this? I did change my formula for auto-filenaming recently
and some of the names could be pretty long,

[JimH]

The file length is probably not a problem unless there are some files that Quicktime is required for.  It has a 64 character limit, including the path.

Try a smaller synch.  See if you can isolate a file or group of files that cause a problem.

I don't understand the extreme part.  VBR should be enough.  Try other encoding formats. 128Kbps, for example.

Also using the Ape High setting is overkill.  High just means slightly better compression (1 or 2%) but it takes a lot more CPU.

One conversion at a time might also help.

[ProblemChild]

Not sure I understand about doing 1 conversion at a time.
The ripped cd files are already in .ape's high format but I will set that down a notch in the future.
It does take a huge amount of time and I've wondered about the benefit.
The VBR 'extreme' setting, from my understanding is the setting for highest quality, least compression,
or at least that's how it was explained to me. How can I have MC do 1 compression at a time during
syncing?
Last, the files causing "ERROR" messages are all from 1 album. Is there anything I can learn from the log
file? Just wondering why I'm losing conversion processes 1-at-a-time. At this point it looks like my final sync
is going to finish ok using 2 of the 3 it began with, though, so I'll start trying smaller syncs and maybe just reinstall
iTunes again for good measure.

[SwellGuy]

For testing purposes, remove any playlist, podcast, etc. syncing rules in Options for the iPod. Also make sure 'Delete files not in sync' is not checked. Click on Sync Handheld in the action window and drag and drop an individual file and click Transfer.

What is the final encoding of the files you are transferring to the iPod?

[ProblemChild]

I convert the files to .mp3 from .ape; based on the suggestion I'm using mp3/normal and ape/normal from now on.
Dropping a single file as you suggested works fine - no problems.

It seems that all the files from a single album (and one from a second album) were yielding an "ERROR" result
during syncing, so I re-ripped that CD and tried again - everything seems to work ok now so far, so I assume the
problem was some error with these files. But the fact that MC kept either hanging or dropping lame processes/threads
one at a time rather than catching the problem, reporting it and continuing was what bothered me.
The files I replaced had played and sounded ok before re-ripping them.

[Matt]

Good find.  Sometimes if the external process dies, it can leave MC stuck on that file during upload.

We're working on a fix.

[Matt]

Fixed in build 390 and later.

[JustinChase]

Fixed in build 390 and later.

Fixed meaning it won't hang any more, or that if/when it does hang it will give a useful error (hopefully pointing out the offending file), and will continue to finish with the rest of the file.

When might we see this version in the public builds?  I'm not on the beta team this time around.

thanks!