Print

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

[aaronshaw]

v16.0.141

I found a bug where if I make a stack (like, part 1 and 2 of a movie), collapse the stack, then choose Rename, move & copy, only the first file in the stack will be processed. The other files in the stack are deleted from the library and have to be reimported.

[marko]

Really? I need to go check this one... My experience has always been that only the top file gets moved, the rest of the stack stays where it is, and the stack stays intact... brb...

[marko]

OK, I'm back. I'm not seeing the file deletion you mention. A few quick words about stacks and their behaviour might help...

Since their inception, if you wish to perform file commands on all files in a stack, you must first expand the stack, select all the members, then run your commands on that selection.

When you 'stack' files in MC, the file at the top of the stack remains visible while the rest of the files are removed from view and tracked in a background database. If you move the top file without first expanding the stack, then only the top file will be moved. The rest of the stack, or 'other file' in your case remains where it is on the hard drive, and your stack in MC remains intact.

After moving, navigate to this top file using MC, right click on it, choose "Stacks > Expand stack" and your 'deleted' file will reappear in the main library. You can then apply the same 'move' command to this second file to have it moved over beside its partner.

I don't think that this is a very practical use of the stacking system as in order to play both parts of the movie, you would need to expand the stack first.

A couple of other approaches you might consider that are more friendly is combining both movie files into a single mkv file using mkvmerge, or set them up in MC with the same [name] and give them track numbers to ensure they play in the right order.

If you find that your stacks have gotten a little untidy, and viewing what's going on with them is difficult, see if this earlier post of mine helps. If it makes sense to you, you will be able to build a view in MC that groups all stacked files on a 'per stack' basis, and shows all files in a stack, regardless of the expanded or collapsed state of the stack. If you need any help setting it up or understanding it, just shout.

-marko

[aaronshaw]

Thanks for the great feedback!
Turns out I had an issue with my network when I was moving the files in question and it resulted in the library files not being written, so the extra stack files were lost from the library. I agree that the current implementation of stack files isn't very practical or intuitive, if I edit a stack I want ALL files to be included not just the top; hopefully this will change in a future version.

Big thanks for pointing me to mkvmerge, brilliant little program, I'm currently converting all my multi-part movies to single files.

Thanks again, you've been a huge help.

[marko]

I'm pleased to hear that you're off and running again, thanks for taking the time to say so.

I agree that the current implementation of stack files isn't very practical or intuitive, if I edit a stack I want ALL files to be included not just the top; hopefully this will change in a future version.

I didn't mean to imply that that was my opinion. It's not!!

I use stacks heavily in my image library. You know, when you've taken 30 shots of something, all slightly different, and want to keep them all? Makes for a very boring slideshow indeed!! Stack 'em up, picking one to be the top file, and that takes care of it. To me, that's brilliant and indispensable. After selecting the files to be stacked, the one you right click upon to access the 'stack' command is the one that is set as the top file. I have not made any use of the 'auto stacking' feature, so am not familiar with its inner workings, but I believe that this is mainly for use in stacking audio files.

I also make heavy use of the handheld conversion cache, where MC keeps an mp3 encoded copy of lossless files for use in subsequent syncs. I have mine set to use a common cache directory rather than the 'beside original file' option. The stacks are created automatically.

If I perform file operations on my audio files, I most definitely do not want my cache files being dragged around too, I want them to stay where they are.

There will be other cases, other users, all able to provide equally strong arguments about what should happen by default, and it would boil down to 3 choices...

• Treat all stack members equally during file operations
• Only work on visible and selected files during file operations
• Ask the user every time

Right now, the only place we see this choice is when deleting a 'top of stack' file, the option is there to delete the entire stack, or not (selected by default if the stack is collapsed). For me, and the way I use them, the current implementation is fine.

The problem that I think some people could run into, especially me, is that when you expand a stack, and the stack members are in different locations, if the current view is excluding that location, the stack will expand, but you won't see them. There is a "view stack files" option in the right click menu, but that takes you out of your current view, and I find that can be quite limiting.

I would only consider using MC stacks in my image library if there was a means for me to be able to manage them easily. For example, Elements had an option to view "All stacked files". MC does not come with a 'stack manager', but it is possible to create one.

In the post I linked to above, I try to describe how I managed that, and was able to move all my image management (except RAW files) into MC and leave Elements behind forever. Once I learned how to read the stack icons, I actually find the stacking feature to be very practical indeed. I might concede that they're maybe not instantly intuitive, but my perception there is clouded as I feel I have a good grasp on how they work as I got right in about them as they were being developed.

My stack manager view is, imvho, of course, highly functional, but if setting one up, it is very important to understand how to read the icons, as they will tell you about the expanded/collapsed state of any given stack, and also which is the top file, two things which can critically alter any tagging behaviour...

When setting up a viewscheme as I have described, you see all the files in a stack, even though the stack may be collapsed. The above tagging rules still apply.
You can tag stack members exclusively even though the stack is in a collapsed state, but remember, even though you can see the individual files, if, as far as MC is concerned, the stack is collapsed, then any tagging on the top file will be propogated through the stack. If you don't want that, remember to expand the stack first.

For thumbnails, the icons look like so:

Note that regardless of the collapsed/expanded state, the member icons remain the same, only the 'top file' icon changes. The string to produce the thumbnail text goes like so: if(isequal([stack files],),,if(isempty([stack view]),Top Image /(Expanded/),Top Image /(Collapsed/))) Also note that if desired, thumbnail stack overlays can be turned off via the the option in the thumbnail section of the view header menu.

In a detailed file list, the icons look like so:

These are the same files as above. Note the very subtle difference between the expanded and collapsed icons.

Happy stacking!!

-marko

[aaronshaw]

But don't you find it odd/unintuitive that tagging operations are propagated through a collapsed stack, but move/rename operations are not? This is what confused me and caused me to make this post (through my ignorance of stack handling). I concur that it would be better to have a user-set option to: (as you said)
> Treat all stack members equally during file operations
> Only work on visible and selected files during file operations
> Ask the user every time

Preferably in the user options to set permanently, or a checkbox in the pop-up-window to 'remember my choice'.

As an aside, this is the smallest of issues I've found since using MC over six years ago.

[marko]

Not really, no. For me, that's 'just the way stacks work' and it's never really bothered me.

There are some holes in my stacks knowledge that bother me (just a little bit) more, and I might set some time aside to address that. For example, tags propagating through the stack... I'm aware that some will, and some won't, but cannot be any more specific than that!!

A quick skim over the wiki page for stacks reveals some things that lend more credence to your original post. Things such as:

• Stacks are simply groupings of files that can be displayed and manipulated like single files.

  Each stack has one file that is the top. This is the file that is displayed in the Content Pane and used to represent and manipulate the underlying stack members.

  These two opening sentences would certainly have me expecting my entire collapsed stack to move with the top file if I were to move it.
  

• When the top of a collapsed stack is moved, the stack members are moved provided the stacked files have any commonality [ambiguous].

  I've no idea what this means. It's certainly not my experience, and certainly not yours either. This needs to be understood and either better explained, or removed!
  
  These statements also need to be investigated, and corrected or expanded upon as required:
  
  

• When the top of a collapsed stack is deleted, all stack members are deleted. If the stack top of an expanded stack is deleted, the top will be removed and a new top will be selected.

  As I mentioned already, this depends upon how the user applies the "Apply selection to all stack members" option on the 'delete' dialogue. The default setting for this option changes depending on the collapsed / expanded state of the stack.
  

• When creating a stack, the top of stack starts out somewhat random. The application picks the largest file as the top for non images. For images it picks the largest dimension file of type jpeg.

  Perhaps this applies to the auto-stacking feature. It's certainly not the way it works for manual stacks. The file you right click on to access the stack command is the file that is set as the top file.
  
• The "Stack Icons" section talks of stars. None of the icons contain stars.

I'll keep these here for my own reference, with the intention of getting that page up to date sometime in the near future.

-marko.