Print

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

[Matchbox]

How can I select a file, and remove all files in that stack?

When I delete a file now, I delete it, and then I see the files in my handheld cache and then I have to delete those.

Can it be done in one step?

[DarkPenguin]

I think I killed that functionality after it bit me.  Feels like a right click menu option.

[Matchbox]

I think I killed that functionality after it bit me.  Feels like a right click menu option.

A right click option may work.... at least better than what we have now.

I only use stacks for my handheld cache and when I delete top level audio file, there is no reason to have the mp3 versions ever.

Prior to stacks, the cache delete was done automatically, or at least I was not aware it was leftover if it was.

Now I delete the top level file, and then suddenly see mp3 versions of same file remaining. 

An automated way to do this for cache stacks was great and would be welcomed again.  Thanks.

[lalittle]

I think I killed that functionality after it bit me.  Feels like a right click menu option.

This concept keeps popping up in different areas -- i.e. the idea that people who use stacks for the handheld cache expect to be able to continue to treat files as "single files."  Managing a library quickly gets more complex and confusing if you suddenly have to take "companion files" into consideration.  When I delete a song that has a companion file stacked with it, I expect the entire stack to be deleted along with the original.  If I have to use any sort of "special means" to simply delete a file (like a special right click command), it will quickly become frustrating.  The same commands that work for "regular" users should work for handheld cache users.

I think the problem might be that using stacks for the handheld cache has somewhat different priorities compared to using stacks for other purposes, such as for images.  This appears to have lead to compromises with trying to make a single, overall behavior paradigm that works for ALL situations.  In other words, in order to make stacking work well for image use, it makes things confusing for people who only use stacks for handheld use, and at this moment, it seems like the "handheld cache only" users are losing out.

I like the idea of using stacks for the handheld cache, but shouldn't the idea be for it to work as effortlessly as the handheld cache USED to work prior to using stacks?

As Matchbox said,

Prior to stacks, the cache delete was done automatically.

I think that this idea is CRUCIAL in order to have stacks work effectively for handheld use -- i.e. that things just work automatically behind the scenes without the user having to even be aware of what's going on.  I strongly feel that people who use stacks for handheld caches shouldn't have to take any special considerations when managing their libraries.

One possilbe thought:  Would it work to have MC automatically treat a stack as a "single file" as long as it was collapsed?

Thanks,

Larry

[Matchbox]

And I have yet to understand what stacks are really for...

I just added the "stacks icon" to my view.  When I click on the stack icon, the top item in the stack icon turns red from blue.  Another click on the stack icon and the red turns back to blue.

Did anything else happen when I turned the icon from red to blue and back?  Nothing happened that I could see.

I think the color change indicated expand vs collapse, but again what do those terms mean in what I see?  I could see no change other than the color icon change.

[lalittle]

And I have yet to understand what stacks are really for...

The basic concept is to allow you to have different "versions" of any given file, with one of them being the "primary" version.  The idea is to only display the "primary" one, but to still have the others available.  The typical example of this (other than the handheld cache scenario) would be with photos.  You keep the original, raw camera file untouched, and generate a copy for your cropped, color corrected, "edited" version of the file.  You then use the edited version of the file as the "top" file in the stack -- i.e. the one that is actually displayed in your library.  If you want to re-edit the file in a different way, the original is still right there next to the edited version -- it's just "hidden" behind it until you expand the stack.

This works well for handheld caches since there are now two files for each "song" in the library, but only a single file is normally displayed (the uncompressed one.)  The assumption for handheld cache users is that each "song" is still treated as a single file.  Problems, as you've noticed, occur when other considerations are taken into account for OTHER types of stack use.  Hopefully, the feature can be tweaked so that everything will be "under the hood" for handheld cache users.  These users should be able to use and manage their libraries without ever having to think about the fact that each song is actually two files -- this fact should essentially be "invisible" to them if they want.  For all practical intents and purposes, the mp3 should behave like a "sidecar" file to the main, uncompressed file.

Larry

[Matchbox]

The basic concept is to allow you to have different "versions" of any given file, with one of them being the "primary" version.  The idea is to only display the "primary" one, but to still have the others available.

That's what I figured, but how would get to the non-primary stacked files?

Can you explain the stack icon and the red/blue thing and what is mean to be red or blue?

[lalittle]

That's what I figured, but how would get to the non-primary stacked files?

You just "Expand" the stack, which is otherwise (normally) "Collapsed."  For handheld cache users, the mp3 file can essentially be "hidden" unless you specifically want to see it.

Can you explain the stack icon and the red/blue thing and what is mean to be red or blue?

The icon shows three little "pages" in a stack.  When they're all blue, the stack is collapsed, meaning that ONLY the top file in the stack is actually showing, while and files stacked "under" this file are hidden.  When you click on the icon, something actually DOES happen -- the stack expands showing you ALL the files in the stack, and you'll see red in the icon -- i.e. red = stack expanded.  When the top "page" in the icon is red, this is the "top" file in the stack.  When the red "page" in the icon is covered by a blue page on top of it, this is NOT the top file, so it will be hidden when the stack is collapsed.  Clicking on any of the stack icons re-collapses the stack.

Larry

[Matchbox]

You just "Expand" the stack, which is otherwise (normally) "Collapsed."  For handheld cache users, the mp3 file can essentially be "hidden" unless you specifically want to see it.

Sorry, I am missing somethat that must be obvious.

I can make the stacks icon turn blue or red but that is all I see.  When you say

When you click on the icon, something actually DOES happen -- the stack expands showing you ALL the files in the stack

What does that mean?  Where is the stack expanded?  What should I see?  Where?

For example, a track has the top level primary track and the handheld mp3 file.  How would I ever see or be able to access the mp3 version?

[lalittle]

Sorry, I am missing somethat that must be obvious.

I can make the stacks icon turn blue or red but that is all I see.  When you say

What does that mean?  Where is the stack expanded?  What should I see?  Where?

I'm not very familiar with stacking yet, so there are parts of this I'm not clear on, but I'm referring to the file list -- i.e. the list with all the columns showing the name, stack icon, size, date, etc.  When a stack is expanded, any files stacked with the top file (in this case the mp3) should show up directly under the original file -- i.e. the "expanded" file should be the next one in the list.

Just to make sure we're on the same page here, the little icon with a stack of three pages is ALL blue to start with, and you click on it.  The "top" page of the little icon should turn red at this point.  Is this what you're seeing?  If so, what icon is next to the very next song in the list?  It "should" be a similar icon, except that the red "page" will instead be in between two blue pages (i.e. the red "page" in the icon will be mostly covered by a blue page on top of it.)  Are you not seeing this?  Are you saying that when you click on the all blue icon, the top part turns red, but you don't see the mp3 right below it?

For example, a track has the top level primary track and the handheld mp3 file.  How would I ever see or be able to access the mp3 version?

I "thought" that you should be able to see it simply by clicking on the icon and "Expanding" the stack (or by right clicking and selecting "Stacks > Expand Stacks.")  If the icon turns red, this should indicate that it's expanded, so I don't know why you aren't seeing the mp3 right below the original file.  Maybe MC behaves differently when the stacked file was created for the handheld cache.  I read in another thread that the "Stack Tag" will be "HH Conversion" for stacked files, so maybe MC is designed to permanently hide these files.  If this was the case, however, I don't know why it wouldn't ALSO delete the "HH Conversion" file when deleting the master.

What version of MC are you using?  What happens when you right click on the file and select Stacks > Expand Stacks?

Larry

[marko]

My HHCache files show up if I expand the stack, which, for the HHCache, is something I've only ever done when testing something. I am 110% with you Larry when you say that the HHCache should take care of itself, period.
My Handheld stack files go into a seperate directory and I just don't wish to think about it, ever. MC should take care of the cache for me, including removing the stack files of any parents I might delete.
I will be testing this, because if doesn't happen, I'd consider that a bug.

Matchbox, are there any view scheme defining "Step 4" rules that might filter out the unstacked files? Something like a filetype restriction or a filename restriction would give the appearance that nothing happened as they might cause the expanded files to be filtered out of the current view.

Does THIS post I made back in April help clear the mud at all?

Larry's question about your MC version number is also rather important as many stack related issues have been dealt with over the past few months.
They are working remarkably well right now in the current builds.

-marko.

[Matchbox]

Matchbox, are there any view scheme defining "Step 4" rules that might filter out the unstacked files? Something like a filetype restriction or a filename restriction would give the appearance that nothing happened as they might cause the expanded files to be filtered out of the current view.

Okay, I had a filter in place to NOT show any files in the cache directory, now the expanded stacks are working ALMOST as I would expect.

So now the stacked files expand SOMETIMES.  Right now I am looking at the file list with about 10 files with the stack icon showing red, some are expanded (meaning I can see the additional files in the stack) and others only show the top file.

If I right click on the AUDIO view scheme and then select "edit view scheme" and then just click Okay, then all the expanded files will actually expand.

Also some show the top level file first and others show the sibling files first.

I'm using 5.04, let me install the latest and retry (can't do it without rebooting and then I'd lost this text)
NOT FIXED WITH 5.12.  Not ALL files expand unless I do the "edit view scheme" and just click okay, then they all expand, but not with the top level file first.


Any other ideas on what I may be doing wrong?

Thanks Larry and Marko for the help !

[Matchbox]

Now back to the original SUBJECT.

There should be some easy AUTOMATIC way to delete the whole stack.

I think that if the stack is not EXPANDED, deleting the top level file should delete the whole stack.
If the stack is EXPANDED, then any file in the stack that is delete should be the only file deleted.

The EXISTING deletion warning message could have an additional STACK DELETE warning message line in the same dialog.

Does anyone that uses stacks for anything other than as a handheld cache have any issues or comments on the suggestion above?

[marko]

I agree with you that deleting a top level file of a collapsed stack should delete the entire stack.

I also think that that is potentially devastating behaviour for MC newcomers, or anyone for anyone, experienced or otherwise, using the option to hide the stack indicator.

I think that there should be a warning prompt that the file about to be deleted will cause the entire stack of files to be deleted, and if that's not desired, to cancel and expand the stack first.

Or perhaps there should be different behaviour between image stacks and HHCache stacks?
HHCache stacks delete the entire stack silently (which is what I'd expect to happen anyway)
Image stacks just delete the top file, unstacking the rest in the process

-marko.

[lalittle]

Or perhaps there should be different behaviour between image stacks and HHCache stacks?
HHCache stacks delete the entire stack silently (which is what I'd expect to happen anyway)
Image stacks just delete the top file, unstacking the rest in the process

-marko.

This is what I was thinking.  When MC creates HH Cache files, doesn't it set the "Stack Tag" as "HH Conversion"?  Couldn't MC be made to treat THIS type of stack as a single file as long as it is collapsed, and therefore delete both files without extra warnings?  Other "HH Cache" considerations could also be used for these types of stack files, such as keeping all tags in sync with the parent file (although this may already happen -- I'm not entirely clear on this.)

Thanks,

Larry

[Matchbox]

So now the stacked files expand SOMETIMES.  Right now I am looking at the file list with about 10 files with the stack icon showing red, some are expanded (meaning I can see the additional files in the stack) and others only show the top file.

If I right click on the AUDIO view scheme and then select "edit view scheme" and then just click Okay, then all the expanded files will actually expand.

Also some show the top level file first and others show the sibling files first.

I'm using 5.04, let me install the latest and retry (can't do it without rebooting and then I'd lost this text)
NOT FIXED WITH 5.12.  Not ALL files expand unless I do the "edit view scheme" and just click okay, then they all expand, but not with the top level file first.

Can anyone duplicate this behavior?

[Matchbox]

Bump - can anyone duplicate the problem described in my post right about this one?

[DarkPenguin]

Have you tried error checking your stacks?  There have been some teething pains.

[Matchbox]

Have you tried error checking your stacks?  There have been some teething pains.

A stack check on the entire library found no errors.

Stacks are not working right or consistent in my system as described above. 

If I click the stack icon, it does turn the top level red, BUT THE STACK DOES NOT EXPAND.

I must right click on the AUDIO scheme and select edit view scheme and then just click OKAY, nothing else to get the stack to expand, and even then, the top file in the stack is not first.

Is this right?  Am I doing something wrong?

[DarkPenguin]

Is your view excluding some databases?

[lalittle]

Bump - can anyone duplicate the problem described in my post right about this one?

I'm only playing with some very basic stack situations, but in my tests, "expanded" stacks always properly expand to show all the files in that stack.  Do you notice any different behavior when you right click the stack and select "Stacks > Expand Stack" instead of just clicking on the stack icon?

and even then, the top file in the stack is not first.

I may know what you're seeing in this case.  Being the "top" file only means that this is the single file that will display for this stack when the stack is collapsed.  It does NOT, however, change the sort order of the files once the stack is expanded.  In other words, once a stack is expanded, the files will still sort according to the normal sort options set for this view.  The "top" file will only sort at the top of the expanded group if this is where it would "normally" sort.

Also note that you can choose which file is the "top" or "parent" file for a stack by using the right-click stack options, and that the file that you initially right click on when you first stack the files will be assigned the "top" spot.  For example, let's say I highlight the first 5 songs of an album (i.e. tracks 1 through 5).  I then right click on Track 3 and select "Stacks > Stack" from the menu.  The 5 files now collapse to a single stack, and since I right clicked on Track 3 when I selected the stack command, this is the file that's displayed for this stack.  When I expand the stack, I now see all 5 files again, which still sort from Track 1 to Track 5, with Track 3 right in the middle of the group.  Note that when the stack is expanded, the icon for Track 3 will be different from the other four -- it will be the "red-on-top" icon, which indicates that it is the "top" file for this stack.  The other four files -- Tracks 1, 2, 4, and 5 -- will show the "red-in-the-middle" stack icon.  I can right click on any of the other four files and change it to the "top" file for this stack.

Does this answer that part of your question, or did I misunderstand what you were saying?

Thanks,

Larry

[Matchbox]

Is your view excluding some databases?

Nope, I have full access to all databases.

[Matchbox]

I'm only playing with some very basic stack situations, but in my tests, "expanded" stacks always properly expand to show all the files in that stack.  Do you notice any different behavior when you right click the stack and select "Stacks > Expand Stack" instead of just clicking on the stack icon?

No difference that I can see between the two methods.  Each makes the top level icon red but nothing else.  Then I have to right click on AUDIO, select "edit view scheme" and then do nothing more than click Okay to get the stacks expanded.

I may know what you're seeing in this case.  Being the "top" file only means that this is the single file that will display for this stack when the stack is collapsed.  It does NOT, however, change the sort order of the files once the stack is expanded.  In other words, once a stack is expanded, the files will still sort according to the normal sort options set for this view.  The "top" file will only sort at the top of the expanded group if this is where it would "normally" sort.

That might be it, but again, it's silly to not have the top file on top....

Do you know what was the last MC version before stacks?  I'd like to revert until all the kinks are worked out.

To delete a file now, I have to delete the visible files, then "remember" what I deleted so I can go look for the mp3 versions from my cache and delete them too.  My library is a mess of leftover mp3 cache files and  so many duplicates, I may have to delete everything and reimport.

[lalittle]

That might be it, but again, it's silly to not have the top file on top....

I agree with you -- it makes sense for the "top" file to always be first (including when the stack is expanded) since all the other files could be considered "sub versions" of this file.  On the other hand, once the stack is expanded, there is something to be said for simply letting the existing sort order take place, which may place the "top" file in the middle of the group.  I guess that different needs result in different preferences.  It would be nice if there was a sort parameter based on the "top" file in a stack.  You could place this rule after "track number" in the sort list in order get the behavior you're looking for.

Do you know what was the last MC version before stacks?  I'd like to revert until all the kinks are worked out.

Stacks have been used for the handheld cache for quite a while not.  I have a feeling that if you revert that far in MC, you might run into problems with using current handhelds.  I can't comment on beta builds, but I would recommend that instead of reverting, you should wait for the next build.

Larry

[DarkPenguin]

You can sort the stack column.

[lalittle]

You can sort the stack column.

When I click on the stack column, it changes it to the FIRST sort level, but I can't figure out how to add the "stack column" to the list of sort parameters.  In other words, how do you get MC to sort by other parameters first, and THEN by stack column within each album?  The only "Stack" item I see in the selection of sort parameters is "Stack Tag," which is something different.

Thanks,

Larry

[marko]

You need to sort by [stack top]

It's not available in the list of fields, but you can force it in by adding a 'custom' line to step 4 of a view scheme: ~sort=[stack top]-d

Now add the other sort items as usual and use the up/down buttons to arrange them.

=========
Why is there no 'import/export' button in the 'step 4' wizard like there is in the smartlist wizard?

-marko.

[Matchbox]

Stacks have been used for the handheld cache for quite a while not.  I have a feeling that if you revert that far in MC, you might run into problems with using current handhelds.  I can't comment on beta builds, but I would recommend that instead of reverting, you should wait for the next build.

To the best of my knowledge, there is no indication that these stack issues will be resolved in the next build or are even being worked on.  The way handhelds are managed by stacks is a huge step backwards from the prior pre-stack method IMHO, but that does not mean the MC developers agree.

My library is a huge mess, extra mp3 cache versions all over the place and so many duplicates (which may or may not be related to the stack problems).

When I reorder an album and then rename the files, the old cache files are not cleaned up from the cache dir, so I have a bunch of extra files left over cluttering up my hard drive in the cache dir.  It's a mess.

[lalittle]

You need to sort by [stack top]

It's not available in the list of fields, but you can force it in by adding a 'custom' line to step 4 of a view scheme: ~sort=[stack top]-d

Now add the other sort items as usual and use the up/down buttons to arrange them.

=========
Why is there no 'import/export' button in the 'step 4' wizard like there is in the smartlist wizard?

-marko.

Do you know if there are plans to add [stack top] to the actual selection list so that we can utilize it via the normal routine?  I just don't have any room left in my brain to remember more of these types of settings.

Thanks,

Larry

[lalittle]

To the best of my knowledge, there is no indication that these stack issues will be resolved in the next build or are even being worked on.

The developers have indicated that the delete paradigm for stacks is a valid concern.  Again, I'd recommend waiting for the next build if possible.

The way handhelds are managed by stacks is a huge step backwards from the prior pre-stack method IMHO, but that does not mean the MC developers agree.

I don't agree.  I think that as long as some issues are addressed, stacks are actually a much better way to deal with the handheld cache files.  Before, a new file had to be created if ANY changes were made to the original, and I'm not sure that the first cache file was even deleted in this situation.  Both these issues are resolved with the new stack system.

I think that you're seeing some growing pains.  Once these are worked out (and JR has been addressing these issues lately), I think you'll find that the new system has some definite advantages over the previous one.

Larry

[Matchbox]

The developers have indicated that the delete paradigm for stacks is a valid concern.  Again, I'd recommend waiting for the next build if possible.

Thanks for the tip, I'll wait, much better than trying to find the old non-stack version and getting it reconfigured.

I don't agree.  I think that as long as some issues are addressed, stacks are actually a much better way to deal with the handheld cache files.  Before, a new file had to be created if ANY changes were made to the original, and I'm not sure that the first cache file was even deleted in this situation.  Both these issues are resolved with the new stack system.

I think that you're seeing some growing pains.  Once these are worked out (and JR has been addressing these issues lately), I think you'll find that the new system has some definite advantages over the previous one.

I don't have a problem with stacks being used for the handheld cache in principle at all.  But as it's working right now, it's a step backwards.  Once the growing pains are past, then I'd have no opinion, as long as it works as well as, or better than the old method.

But as of right now, my library is a mess because of the stack actual implementation for handhelds using stacks.

[Matchbox]

You need to sort by [stack top]

It's not available in the list of fields, but you can force it in by adding a 'custom' line to step 4 of a view scheme: ~sort=[stack top]-d

Now add the other sort items as usual and use the up/down buttons to arrange them.

Marko, how would I edit an existing view scheme to add this sort item?

I can't figure out how to add a custom line.

[marko]

I can't figure out how to add a custom line.

Edit the view scheme (I've assumed you know how, just ask if I've assumed too much, it won't be a problem) then click on the 'add rule' button, then type your rule into the field without selecting anything from the drop down on the left. Like so:


-------

If I've understood correctly, you're stacks are a mess, which is one problem, plus you have deleted files that were in stacks which has left debris behind.

Perhaps it might be an idea to start over...

If you specified a single directory for your cache conversion files, then the simplest option is to go there using windows explorer and delete that directory. MC's auto import will then take care of the housekeeping and tidy up your library.

If the files are 'beside the originals', there's a bit more work to do...

Make your custom rule: -[stack top]=-1 ~sort=[name],[stack top]-d
This will ensure that you're only dealing with files that are currently in stacks, and that when expanded, the stacks will stay together in the list.
When you're done with that, make sure you are in panes view up top, and details view down below.
Make sure the following columns are on view in the file list: "Stack Icon", "Stack Tag", "Name" and "Filename".
If any are missing, right click a column header in the file list and hover over columns. From the flyout list, click those that are missing to add them.
You can then drag and drop the column headers so as to place the four columns beside each other.

Now, with nothing selected, hover your mouse over the header where it says 'Pane' and a menu will show. Choose Options > Expand Stacks
All your stacks should now be expanded and you should be looking at a list full of something like this:


The "HH Conversion" files are mp3s in the ipod cache folder, the other two are the original flac files.
Try one or two first, but you should be able to select the HH Conversion files and delete them permanently.
Once you're happy, click on the "Stack Tag" column header to sort by it, select all the HH Conversion files and nuke 'em.
Don't freak out if you're left with an empty file list.
Remember, you specified -[stack top]=-1 in the view scheme rules, and if MC has done its job correctly, there won't be any stacks left in your library, so the list should be empty.

Next time you connect your hand held player, go to options and set some rules for it.
I personally think it makes a lot more sense to have the cache files in their own directory out of the way somewhere. If you agree with me, tell MC where to put them, adding any library fields you need.
For example, mine go to: D:\iPod Cache\[media type]\[album artist (auto)]\[album]
Once set, you should have the same seamless functionality as the old style cache, with the big difference being, if you expand the stacks, all the cache mp3 files will become visible in your library just like any other files.

---------

If you need to track down any other 'orphan' mp3 cache files that have been left behind, you will need to think about your filing structure and library structure and work out some logical way to get MC to list the orphans.

Ideally, you're library is 100% flac files, therefore any mp3's can be deleted, so you would get MC to show you all mp3 files and then delete them.
If it's not as simple as that, what do you have to work with?
If needed, I can help you with any search rule you might need, but would need more information regarding your file system habits etc.

-marko.

[DarkPenguin]

To answer the original question "How (to) delete a whole stack?" there is a new check box on the delete confirmation dialog.  If there are stack files in there, collapsed OR expanded (it doesn't matter), the option to delete all files in any stacks found is provided.

This option shows if you select ANY stack file.  Top file or member.  If ALL the stack files in the selection are collapsed the option defaults to checked.  Otherwise it is unchecked.  If checked all files in a stack will be whacked even if the file being deleted is a stack member.

So, be careful out there.

I think I put it in 513.

[marko]

I think I put it in 513.

You did.
It works as advertised.

[lalittle]

Edit the view scheme (I've assumed you know how, just ask if I've assumed too much, it won't be a problem) then click on the 'add rule' button, then type your rule into the field without selecting anything from the drop down on the left. Like so:

When I do this, it wipes out all my previous sort parameters, which I then have to add back again.  Is this expected behavior?

This would be a lot easier if the [stack top] field was available from the list of sort optoions.  Is this just an oversight at the moment?

Thanks,

Larry

[Matchbox]

If I've understood correctly, you're stacks are a mess, which is one problem, plus you have deleted files that were in stacks which has left debris behind.

Perhaps it might be an idea to start over...

Marko thanks.  I plan on waiting for the next build and then starting over, I'll delete all my cached files and rebuild.

If that does not solve the problem, I plan on reverting to a pre-stack version of MC until all the kinks are worked out.

I have this fear that I'm losing music files somehow when my library gets messed up, and I may not notice for a long time, too long to get back up files from my backups.