Print

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

[BartMan01]

Syncing files with MC13 (for the first time).  The files had been previously synced with MC12 and the stacked handheld conversion files exist.  The sync is reconverting EVERY SINGLE file.  It is not adding a new stacked handheld conversion file, it is just replacing it with the new one.  Is this expected behavior?

Also every few minutes it is giving me the message "Unable to stack file"  "The stack drive is low on space.".  The stacks are set to keep with original, the originals are on a network share, and the drive they are on has over 100GB free at the moment.

[BartMan01]

It appears that if there already is a stacked file, it goes through the 'conversion' process anyway.
If there is NOT already a stacked file, it goes through the conversion process, gives me the 'unable to stack' file error and leaves me with no stacked file.

I can go in to the folders on the shared drive in explorer and create/delete/modify files so it is not a permissions issue.

[BartMan01]

And to make matters even more fun, MC keeps crashing during the sync and upon re-sync MC does not 'see' any of the files on the 'device' and wants to re-convert/re-sync them all again.

Files that don't need to be converted are seen as 'on-device'.  The APE files that need to be MP3 on the device all show as "In Queue" even if they just synced over with the previous (failed due to crash) attempt.

[BartMan01]

Just deleted EVERYTHING on the 'handheld'.  Now MC is at least seeing the new stuff transferred as 'on device', but it is still doing the conversion on each and every .ape file and not stacking the results if needed (I turned off the error message).

'Conversion' set as follows:
Audio:
Mode: Convert unsupported formats
Encoder:  MP3 Encoder
Encoder Settings... (Normal Quality)
Cover Art:  No Change

Image:  No Conversion
Video: No Conversion

Conversion Cache:
Cache converted file (via a stack):  Checked
Stack Location:  With Original

[Alex B]

Do you use mapped drive letters?

On our LAN the shared network folders do not report the available space at all when they are accessed through the Windows network shares directly. (i.e. by using paths like \\PC X\Share Y\ )

When a share is mapped to a drive letter the available space is reported in Windows Explorer correctly.

I have XP on the server and on the clients.

EDIT

Did you test if it would work when the stack location is set to a local drive?

EDIT 2

I have disabled TCP/IP for Windows networking for security reasons. I use the old good unroutable NetBEUI protocol instead. I don't know if this has any effect to the available information.

[BartMan01]

No mapped drives.
Music files live at:  \\hostname\...dirs...\filename.ape
I really don't want to have to starting mapping drives, does MC HAVE to check for free space before saving a cache stack file? And why is it converting files that already have a stacked HH cache file?

Stacks were originally built as local before I finally gave up on trying to run MC on my primary system (too many things that I had to have loaded on my main system like iTunes 8/Nero/etc that MC just doesn't play nice with).  MC runs on a VM with the actual files on a drive on the physical machine.  I don't have enough space on the VM (nor do I want) to store the library files there and things are just easier if the stacked files stay with the original.

[Alex B]

Could you just test if it works with a local file cache (with a few files)? If it works then it would be obvious that the cache location is the cause of the problem and the problem would be easier to fix. Perhaps the developers could add an manual option to not check the available space or change it to automatically ignore the check results when no information is available.

[Alex B]

Personally, I don't think the development of the stack feature was properly finished. When it was introduced I suggested several things and filed some bug reports, but the issues were never fully addressed.

At some stage I stopped experimenting with the stacks feature and chose to use an alternative method which works for me.

I have created a virtual handheld on a local hard drive. I sync MC with that handheld without creating a conversion cache. (i.e. without stacking the converted files.)

For syncing the actual handhelds and burning MP3 CDs I use Media Jukebox 12. I have set its auto-importer to monitor only the virtual handheld location.

[BartMan01]

Handheld to C:\test
Cache to C:\tempcache

It is still re-converting items with stacks.  Now for the odd part:
The files that are already in a hh stack cache are NOT writing a new file to C:\tempcache even though they are going through the conversion process.
The files that did not have a hh stack cache are creating a file in C:\tempcache.

If I clear the 'handheld'
Files that have the oritinal HH stack item are STILL converting as if they have no stack item.
Files that created an item at c:\tempcache are NOT having to re-convert (using the stack).

So two issues with HH stacks:
HH stack items appear not to work with UNC paths - you must physically map a drive.
If you create HH stack items and then move your library and MC install, the system only half sees the stacked items.  It sees them enough to not create new ones but wont use them.

[BartMan01]

OK, final update (I think):
Went to delete the stack files completely so that they would be forced to start from scratch.
It appears that (because the files were 'stacked') when I did my universal find/replace on filename path it did not 'see' the stacked items and left them on the old (now non-existent) location.

So we still have an issue with the HH Conversion not allowing UNC pathing and requiring a mapped drive.
Another issue is that if you move your library, a full find/replace does not see the stacked items - and then the HH Stack process chokes when the stack exists in the library but the file is no longer 'there'.