Rusty,

Thanks for the reply. After toggling the the advanced settings in the synch config I noticed that the "Destination" defaults to <Path> when selecting a location node. I simply changed that value to "Default" and it appropriately transferred according to the output mask on "Synchronization Options" tab. MM is working as intended. Hope that clarifies -- while tactfully avoiding highlighting my own user error ;)

James

James,

Re. your comment: "MM defaults to copying the same path from the source files to the device, which directly explains #2."

This should not be the case! i.e. MM should always use the mask that is configured in the device options panel. Can you generate a log that shows what happens when you synch? I'd like to see what is causing this behavior.

Thx.

-Rusty

To close the loop for those interested in iRiver synching, issues #1 and #2 were caused by my changing the synch approach to selected items from the Location node rather than syncing the entire Library (one directory has my MP3s and another directory has DRM-protected subscription WMA files). MM defaults to copying the same path from the source files to the device, which directly explains #2. This same issue resulted in exceptionally long files names for my MP3s, which caused issue #1 (and has been fixed in Beta 4).

Thanks to jiri for his quick response and help!

-James

Re. 1, could you e-mail me your 'My Music\MediaMonkey\MediaMonkey.mdb' file so that I could see what's on synchronization list and what's causing problems?

Jiri

Wanted to give some feedback on synching with an iRiver H340 in 2.5.1.921. I'm running WinXP Pro SP2 on a Thinkpad T43 with 512MB RAM.

1. Non-MTP Synch Crashing

When synching non-DRM tracks to an iRiver H340 connected to its USB2 "Data" port, MM 2.5.1.921 starts the "preparing tracks" process then aborts then the MM application simply ends (the debug log is below). I then used WinXP Safely Remove Hardware to unmount the iRiver device but received an Application Error that read "Exception EOLEException in module d_iRiverH.dll at 00019536".

The synch feature worked fine before so I rolled back to 2.4.2 but it now exhibits the same behavior. The MTP synch process is still working in Beta 3 however.


2. Synch Destination

My subscription music is stored in c:\My Yahoo! Music\<artist>\<album>\. In the d_WMDM.dll configuration I chose the entire c:\My Yahoo! Music directory and the synch mask of "\Music\<Artist>\<Album>\<Title>" but the tracks ended up in "\\Music\My Yahoo! Music\<artist>\<album>\<title>".


3. MTP Synch Exceptions

Is there a way to get an exception report of DRM tracks that did not synchronize? I've been using WMP10 (unfortunately) to synch my subscription music and it shows the tracks that copied and the tracks that didn't for licensing issues, etc. In MM problem tracks just don't show up and there is no indication that they didn't copy.


I am a huge MM fan and I'm looking forward to dumping WMP and managing all my music in one place!

-James

--------------------------------------------------------
New exception:
Exception code: 3221225477
Exception flags: 2
Number of parameters: 2
(no debug info) Find error: 7C9122BA
call stack - 0 : (no debug info) Find error: 7C912233
call stack - 1 : (no debug info) Find error: 774FD01F
call stack - 2 : (no debug info) Find error: 77124B4E
call stack - 3 : (no debug info) Find error: 77124B86
call stack - 4 : Routine @NewWideString Find error: 00405C20
call stack - 5 : Module Devices.pas(no debug info) Line 1991 Find error: 006381FC
call stack - 6 : Module Devices.pas Routine SynchronizeDevice_Var Line 1619 Find error: 00637320
call stack - 7 : Module GenThread.pas Routine @TGenThread@Execute Line 519 Find error: 0051AD59
call stack - 8 : Module Classes.pas Routine ThreadProc Line 9475 Find error: 0042BC0A
call stack - 9 : Routine ThreadWrapper Find error: 0040540E
call stack - 10 : (no debug info) Find error: 7C80B507
call stack - 11 : (no debug info) Find error: FFFFFFFC