Print

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

[marko]

OK, apparent bugs apart, I'm really not thrilled with this at all.

I really, really, do not want 'Stack' icons cluttering up my album thumbnail views just because the album happens to have tracks that have been sync'd to my iPod.

Please, please can this be turned off?

[Alex B]

I suppose the answer could be to disable stacking, but then you would not have a cache.


I copied my reports from the now locked 458 thread here:

10. Changed: Handheld Audio conversion stack options streamlined.  It is now on or off.
11. NEW: Stacked files created by the handheld conversion engine now have "stack tag" tagged with "HH Conversion".
12. Changed: Handheld conversion cache options have been removed from the app.  (conversion stacks is replacing it.)
13. Changed: Default for HH use conversion stack option is FALSE.

The new system creates dublicate cache files if more than one HH is configured to use the same stack location and the same conversion format. I tested this by creating two separate HHs in two disk locations and syncing manually a few files (dropped into AW> Sync Handheld). The stack options were set to be identical.

In addition, the sync process hangs at about 94-97%. "Cancel" can end this and the HHs seem to be OK despite the error.

EDIT

Added a screenshot of the "hang".



EDIT2

Actually, the apparent "hang" state may be caused by some overly slow process. After several additional minutes the sync process may end normally (but not always). CPU is maxed out during this time.


In addition, I tried to sync a single "FLAC converted to WMA" file that was already "stacked".

I started logging and dragged the file to AW>Sync. The progress indicator stopped at 87%. I went away for half an hour or so. When I came back it was still at 87%. I cancelled the sync. During the sync MC created a 15 MB log file. Nothing else was running.

The log is available here (260 kB in a rar package).

[marko]

There also seems to be a problem for albums that contain a colon in their title.

These files are not being placed in the cache, and MC is leaving links to mp3 files that no longer exist in the temp folder.

[DarkPenguin]

There also seems to be a problem for albums that contain a colon in their title.

These files are not being placed in the cache, and MC is leaving links to mp3 files that no longer exist in the temp folder.

Clearly my test cases suck bad.

The second one will be in the next build.  Still looking at the first one and Alex B's dueling handhelds.

[Alex B]

DarkPenguin,

You could configure the following test setup:

1. A small flash memory/phone/etc device, WMA or Ogg 64 kbps is preferred

2. A bigger HH that shows up as a drive, MP3 VBR HQ Portable is preferred

3. An iPod, MP3 VBR HQ Portable is preferred

The HHs #2 and #3 should use the same file cache. In the user options this should be possible simply by selecting indentical conversion options.
The #1 should use a separate cache. If the cache location is set to be different or the file format is different MC should transparently maintain a separate cache.

As the source files you should use various lossless and high bitrate lossy file types. Don't forget the possibility to convert WMA lossless to WMA lossy or high bitrate lossy to low bitrate lossy inside the same format (WMA/MP3/OGG/MPC).

[Alex B]

BTW, have you considered my suggestion in this thread:
Re: Sync with handheld: How to re-encode only files with high bit rates?

Jonas' problem is related if he prefers to use a file cache.

... Make possible to add the maximum allowed bitrate for each format in the "Supported Types" handheld option. This bitrate value would be taken into account when the "Convert Unsupported Formats and High Bitrates " option is selected.

For example, a list like

mp3(160);wma(191);m4a

would
- convert mp3 only if the bitrate is more than 160 kbps
- convert wma only if the bitrate is at least 192 kbps (this would be very useful it the user has lossy and lossless WMA files)
- not convert m4a

[Doof]

Something that occurred to me today re: stacks.

The Convert Format tool should have an option to stack the resultant file under the source file.
Likewise with the Rename File tool's Copy option.

I'm especially interested in #1 because then I could just tell MC to create lossy versions of all my lossless files without having to resort to a HH sync. I realize I could do this in 2 steps now, but why not let the app do it for me? Besides, I haven't had much luck getting the Autostack by name function to work...

[marko]

Here's another one....

The following smartlist should search for duplicate audio files using the [artist] and [name] fields.

[Media Type]="audio" -p=hidden,recycle,allowed ~dup=[artist],[name] ~sort=[Artist],[Name]

These new iPod 'stack' files are being roped into the results list, totally messing it up. The 'stacks' are collapsed, and only the original file is on view, unless I use the expand stacks option, at which point the mp3 'cache' files are exposed. Surely that's not meant to happen either, is it?

-marko.

[DarkPenguin]

In the next build the stacks are hidden a little more thoroughly.  The net of this is that if the stack is collapsed the smartlist should not find them.

Here's another one....

The following smartlist should search for duplicate audio files using the [artist] and [name] fields.

[Media Type]="audio" -p=hidden,recycle,allowed ~dup=[artist],[name] ~sort=[Artist],[Name]

These new iPod 'stack' files are being roped into the results list, totally messing it up. The 'stacks' are collapsed, and only the original file is on view, unless I use the expand stacks option, at which point the mp3 'cache' files are exposed. Surely that's not meant to happen either, is it?

-marko.

[marko]

DarkPenguin, thanks for the prompt replies and swift action. Build .459 has certainly been been one of the more interesting builds of recent times

[lalittle]

I asked the following questions in another thread before I noticed this one.  Sorry if some of these questions seem a bit basic, but I've just started investigating this feature, and I'm still unclear about some of the details of using stacks for the handheld cache.  .

First, how does/will MC treat these files when tagging?  If I change the tags of the "top" file in the stack (say a FLAC file) and have an mp3 stacked underneath it, will the tag changes apply to the other file/s in the stack?  What if I make changes to the "top" file's actual filename and/or path, or if I "Move" the file from within MC?  Will the matching mp3 automatically get these changes as well?  Are there any circumstances where I'll have to deal with the FLAC and it's corresponding mp3 files separately?

In other words, can I work with the file as if it's a single file and not ever worry about having to mess with the stacked mp3?

If I want to view the properties of the "hidden," stacked mp3s, do I have to do this for one file at a time, or is there a way to tell MC to display all the stacked mp3 files at once?  I'd like to be able to view and search the "hidden" mp3 files in order to check things like bitrate, etc.  Is there a simple way to do this without messing with the stack structure?

On a related note, will there be some way to utilize my existing mp3s if I decide to re-rip as FLAC files so that I won't have to re-convert all the FLAC files?  If so, how will MC deal with files that are named slightly differently, or have slightly different tags?  I often make various corrections when I re-rip albums, and some of my "older" rips used different file naming rules.  When I re-rip, some files will not have the same tags, filenames, or even paths as the older mp3 files.  Will MC offer a way to deal with this situation -- i.e. to say "this is the mp3 that goes with this FLAC -- make the mp3 match the FLAC file's tags and naming structure"?  This might also come into play if a file is accidentally edited while unstacked, resulting in a mismatch of some fields, or even the file's name or path. 

Also, will there be a way of creating the coverted files without going through the "handheld" window?  In other words, will there be a simple way to tell MC to take a group of my FLAC files, covert them to mp3s, and stack them with the corresponding FLAC files WITHOUT having to actually do a sync?  I'd like to be able to do this process in chunks given that the process will take a LOT of hours.

Similarly, will there be a way to have MC create the "conversion cache files" during the ripping process?  This seems like an ideal time to create the stacked mp3 files.

Finally, can I tell MC to "re-convert" the FLAC files and replace a current, lower bitrate mp3 with a newer, higher bitrate one, or do I have to manually delete the older mp3 files?

Thanks for helping me more fully understand the process,

Larry

[DarkPenguin]

When you tag the top file most of the fields get copied to the stacked files.  We try to honor name changes to move the files around but that only goes so far.  Right now if you move your files from where the hh stack has then the hh stack will likely make a new one and stuff it under the directory.  (These are the little things that make some of this more of an adventure than it should have been.)

You should be able to expand all stacks.  That will show you all the files.  I also intend to add something to show all the generated files.  Hmmm...  I could just make stacktag searchable.

You would have to move the existing mp3 to the stack directory and stack them with their associated flac file.  I do not copy tags over in that case but it is certainly an option I intend to add.

Right now the stacks are only wired into the hh engine.

You have to delete the old stacked mp3's to make new ones.  This will likely change.

I asked the following questions in another thread before I noticed this one.  Sorry if some of these questions seem a bit basic, but I've just started investigating this feature, and I'm still unclear about some of the details of using stacks for the handheld cache.  .

First, how does/will MC treat these files when tagging?  If I change the tags of the "top" file in the stack (say a FLAC file) and have an mp3 stacked underneath it, will the tag changes apply to the other file/s in the stack?  What if I make changes to the "top" file's actual filename and/or path, or if I "Move" the file from within MC?  Will the matching mp3 automatically get these changes as well?  Are there any circumstances where I'll have to deal with the FLAC and it's corresponding mp3 files separately?

In other words, can I work with the file as if it's a single file and not ever worry about having to mess with the stacked mp3?

If I want to view the properties of the "hidden," stacked mp3s, do I have to do this for one file at a time, or is there a way to tell MC to display all the stacked mp3 files at once?  I'd like to be able to view and search the "hidden" mp3 files in order to check things like bitrate, etc.  Is there a simple way to do this without messing with the stack structure?

On a related note, will there be some way to utilize my existing mp3s if I decide to re-rip as FLAC files so that I won't have to re-convert all the FLAC files?  If so, how will MC deal with files that are named slightly differently, or have slightly different tags?  I often make various corrections when I re-rip albums, and some of my "older" rips used different file naming rules.  When I re-rip, some files will not have the same tags, filenames, or even paths as the older mp3 files.  Will MC offer a way to deal with this situation -- i.e. to say "this is the mp3 that goes with this FLAC -- make the mp3 match the FLAC file's tags and naming structure"?  This might also come into play if a file is accidentally edited while unstacked, resulting in a mismatch of some fields, or even the file's name or path. 

Also, will there be a way of creating the coverted files without going through the "handheld" window?  In other words, will there be a simple way to tell MC to take a group of my FLAC files, covert them to mp3s, and stack them with the corresponding FLAC files WITHOUT having to actually do a sync?  I'd like to be able to do this process in chunks given that the process will take a LOT of hours.

Similarly, will there be a way to have MC create the "conversion cache files" during the ripping process?  This seems like an ideal time to create the stacked mp3 files.

Finally, can I tell MC to "re-convert" the FLAC files and replace a current, lower bitrate mp3 with a newer, higher bitrate one, or do I have to manually delete the older mp3 files?

Thanks for helping me more fully understand the process,

Larry

[DarkPenguin]

BTW, the way stacks are expanded and collapsed has changed.  One should do an expand stacks or collapse stacks on all the files to reset them.

[DarkPenguin]

If there is no appropriate file in the stack for a given conversion BUT there is already a file of appropriate type in the stack directory what should the HH engine do?

Should it just use the existing file and put it in a stack with the original OR should it do a new conversion and copy it along side the existing one and stack that?

[Doof]

If there is no appropriate file in the stack for a given conversion BUT there is already a file of appropriate type in the stack directory what should the HH engine do?

Should it just use the existing file and put it in a stack with the original OR should it do a new conversion and copy it along side the existing one and stack that?

One the one hand, I'd say it's logical to stack them, but on the other, if a user manually unstacked the files for whatever reason, it probably wouldn't go over to well to re-stack it on them.

Acually, the more I think about it, the more logical it would seem to just sync the existing file and that's it. Don't create a new file (wouldn't that just be a duplicate on the handheld anyway?), and don't stack it.

[DarkPenguin]

If there is MP3 in the stack but it is not in the stack directory for that handheld should I use it?  Seems like.

[lalittle]

I'm actually more confused now than I was before.  Forgive me, but I just don't understand what this means:

Right now if you move your files from where the hh stack has then the hh stack will likely make a new one and stuff it under the directory.

Did this sentence get typed correctly?  Grammatically, this part doesn't seem to make sense:  "if you move your files from where the hh stack has then the hh stack will..."

Also, people keep referring to the "stack directory."  Does this mean that both files in a hh conversion stack can be located in different folders?  If so, what is the default folder -- i.e. when the hh sync routine creates a converted file, where does it put it?

The way I pictured this working up to now was that the converted file (let's say an mp3) is treated the same way that a RAW image thumbnail file is treated in various RAW file converters like Photoshop or Lightroom -- i.e. the small thumbnail file is considered to be "part" of the original file.  It's therefore "attached" to the original file so that when the original is moved, the thumbnail is moved with it (I assume that MC works the same way, but I am still using PS and LR for my image files).  Is a similar approach be used for hh conversion files?  It seems like the same paradigm would apply since the hh mp3 file is essentially "part" of the original, and as such, ALL manipulations of the original file should be done to the mp3 as well, including any movement, renaming, etc.

Once we start treating the hh mp3 as it's own file, it seems like things get WAY too complicated, with all sorts of scenarios arising that confuse the situation.  The potential arises for new files to be created without the user ever knowing it, and one must suddenly take extra precautions when manipulating the files.  It seems to me that if this is going to work, it needs to just happen automatically behind the scenes, with the mp3 being located next to the original and treated as "part" of the original file without any extra thought needed.  We should be able to view the traits of the hh mp3 file and listen to it if desired, but we should not have to worry about making sure it "stays" with the original.  It should almost be as if the mp3 is a viewable, playable file that is "embedded" in the original.

Larry

[DarkPenguin]

There also seems to be a problem for albums that contain a colon in their title.

Finally remembered this one.  Next build.

[marko]

Something not good going on with my iPod 5G video:

1. Plug it in, MC treats it as a new iPod that's never been sync'd.
2. Check in options and find that all the options have been reset for the iPod too.
3. Images want to re-sync over and over.
4. Having set sync'd images to be converted to 640 x 480, I see that the converted images are being saved in the cache directory.
In an effort to maintain some form of order, I changed the conversion directory rule from "[Album Artist (auto)]\[Album]" to "[Media Type]\[Album Artist (auto)]\[Album]". Figuring that MC would now check this new location for existing cache files, I moved all of the audio files into an \Audio\ directory, and deleted all of the existing image files from the cache directory. MC is not liking this at all! Nothing is being saved to the stack directory at all, and the stacks are all broken.

In an effort to help MC out a little, I selected all audio files, right clicked, stacks > expand stacks
I then filtered by [filename (path)]=iPod and received a list of all files MC believed were in "\stack directory\album artist (auto)\Album" and deleted them all.
MC told me changes had been made to the [stack file] tag of 4000+ files. I said fine and MC deleted the files.
Surely, all the 'stack' icons should now be gone?
They are still there. I select all files and the "unstack" option is available. As there should not be any stack files left in the library, I choose the 'unstack' option.
Nothing happens except for that 'unstack' option now being greyed out, but all the album covers in the library browser are still showing these infernal stack icons!!

For audio the stack icons are nothing but an eyesore, in my very humble opinion, that serve only to indicate to me that there may be some files from any given album on my iPod. Information I have no need for, and had to explain to everyone that they meant nothing at all, "please just ignore them"

For images, I would stack files for archival purposes and general library tidiness. To this end, I need to be able to determine which files are stacked and which are not. iPod related stacks are just getting in the way of this. Again, I do not need any notification that an image file also exists on my iPod.

I'm reaching the point where I am going to have to disable the caching of my handheld files in the name of simplicity. It's sad because the old HHCache system worked so seamlessly and invisibly well.

-marko.

[ADDiCT]

In a perfect world, JRiver would rollback to the "old" hh cache functionality, and develop the stacks stuff in a parallel version of MC, until it's stable and useful enough to implement it into the "real" MC version.

[JimH]

A Stacks tutorial is on the way.

[JimH]

Here it is:
http://yabb.jriver.com/interact/index.php?topic=45819.0