Print

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

[lalittle]

8. Fixed: Assorted Thumbnail database fields now tagged as file specific fields.  (IE stacks will not copy changes to all stack files.)

Could someone possibly clarify this?  In my usage, when I make any changes to tags, I want these changes to apply to ALL the files in the stack.  Is this change saying that changes to thumbnail-specific fields will NOT be carried over to the stacked files?  I'm wondering what the effect of this change will be to users who DO want "all" fields in a stack to be completely in sync -- i.e. for them to always have ALL the same tags.

For the sake of handheld cache users, is there a way to ensure that ANY tag changes made to the top file of a stack will always be applied to the stacked "cache" file as well?  Or, am I simply misunderstanding this change?

Thanks,

Larry

[DarkPenguin]

Could someone possibly clarify this?  In my usage, when I make any changes to tags, I want these changes to apply to ALL the files in the stack.  Is this change saying that changes to thumbnail-specific fields will NOT be carried over to the stacked files?  I'm wondering what the effect of this change will be to users who DO want "all" fields in a stack to be completely in sync -- i.e. for them to always have ALL the same tags.

For the sake of handheld cache users, is there a way to ensure that ANY tag changes made to the top file of a stack will always be applied to the stacked "cache" file as well?  Or, am I simply misunderstanding this change?

Thanks,

Larry

That is correct.  Thumbnail fields have been added to the existing list of fields that are not synced.

[lalittle]

That is correct.  Thumbnail fields have been added to the existing list of fields that are not synced.

I think I must be misunderstainding what "thumbnail fields" we're talking about here.  Could you tell me what specific fields are not carried over to the stacked file?  If I change album art on a file, it still carries over to the stacked files, correct?  My concern is that I'll have to seperately manage some fields in stacked files rather than being able to assume that "handheld cache" stacked files always remain in sync with the top file.

Thanks for clarification on this,

Larry

[marko]

A definitive list could certainly prove useful...

[lalittle]

Well, the internal stack db fields for one.  (That was a remarkably irritating infinite loop.)  File Type, Bit rate, media type, file size, duration, bookmark, thumbnail fields (most hidden), sample rate, channels, bit depth, compression, height, width, bad pixels, aperture, iso, shutter speed, focal length, flash, edit info, lattitude, longitude, altitude, direction, dimensions, album gain, protection, and a bunch of hidden fields.

If there are some that should not be shared or some that should, let me know.

Coverart info and the image field appear to be shared.

Thanks.

I had assumed that the non-editable tags that display the file's attributes would not be carried over.  What I'm wondering is if any "editable" fields are not carried over to the stacked files.  To get back to the original question, will we still be able to essentially "ignore" stacked handheld cache files and assume that changes made to the top file will automatically apply to the compressed cache file, or are there some user-editable fields where we'll need to remember to individually edit both the top file AND the stacked file?  Fields like File Type, Bookmark, Bitrate, etc. are of course not a problem in this regard, but I'm a bit unclear if there might be some fields where this may be a consideration.

I guess part of the problem is that I'm unclear what "thumbnail" tags actually are.

Thanks again,

Larry

[DarkPenguin]

Thumbnail fields are internal.  Don't worry about them.  They only come up when the stack engine does something with them that it shouldn't.

[lalittle]

Thumbnail fields are internal.  Don't worry about them.  They only come up when the stack engine does something with them that it shouldn't.

Thanks -- that's what I wanted to know.

Larry

[rpalmer68]

I have just finished building my HH cache and have started to update the last few albums that don't currently have album art.

My cache is using stacks and I have the stacks collapsed in my views.

If I select the .ape fiese for an album and add the cover art, the stacked mp3 files are not getting the cover art applied to them.

Shouldn't the cache upadate too?

I'm running .504.

Cheers
Richard

[DarkPenguin]

If the stacks are collapsed the cover art for all stack members is cleared and the new cover art is applied to all stack members.  The thumbnailer, however, only runs on the stack top and not on the rest of stack members until the thumb is needed.

If the stacks are expanded the cover art of stack members is untouched when changes are made to the top file.

Is this the behavior you are seeing?

[lalittle]

If the stacks are collapsed the cover art for all stack members is cleared and the new cover art is applied to all stack members.  The thumbnailer, however, only runs on the stack top and not on the rest of stack members until the thumb is needed.

If the stacks are expanded the cover art of stack members is untouched when changes are made to the top file.

I can understand the thinking behind this, but this is definitely not the behavior I would intuitively expect for HH Cache files.  To me, the concept of the stack in "handheld use" would be to ALWAYS apply the cover art to all the files in a stack regardless of whether it's expanded or collapsed.  I don't want to have to worry about whether or not I remembered to "collapse all stacks," which would be needed to in order to ensure that this doesn't become an issue.  I want to be able to completely forget about "managing" the stacks, and just have them always be kept completely in sync with the top file.  Might there be some setting that could alleviate this -- a setting that would "always" sync the stacked files with the top file in all the necessary ways, inlcuding cover art?

Thanks,

Larry

[rpalmer68]

If the stacks are collapsed the cover art for all stack members is cleared and the new cover art is applied to all stack members.  The thumbnailer, however, only runs on the stack top and not on the rest of stack members until the thumb is needed.

If the stacks are expanded the cover art of stack members is untouched when changes are made to the top file.

Is this the behavior you are seeing?

Um... no.

My stacks were collapsed when I added new cover art to the .ape files.  When I expanded the stack, the .mp3 file had no cover art.

I also tend to agree with Larry, for cache files we shouldn't have to think about them they should jsut get updated at all times.

Richard

[DarkPenguin]

Um... no.

My stacks were collapsed when I added new cover art to the .ape files.  When I expanded the stack, the .mp3 file had no cover art.

I also tend to agree with Larry, for cache files we shouldn't have to think about them they should jsut get updated at all times.

Richard

That was my test case.  I added cover art to a stack and both files updated.  I delete the cover art and both are deleted.  How are you adding cover art?

Now if the audio stacks are expanded the that indicates that one IS thinking about them and possibly using them for other purposes and automatically doing things to them might be an issue.  The problem is you don't want a lot of stack related conditionals deep in the DB or the app will crawl.  As that is where most of the stack set code is handled that is a problem.  Maybe I'll add a thread after the fact to update the stacked audio files.

[rpalmer68]

That was my test case.  I added cover art to a stack and both files updated.  I delete the cover art and both are deleted.  How are you adding cover art?

I selected a group of files and added cover art from scanner.

Now just in case it matters these cache stack was built with our favourite Build cache function

Richard

[rpalmer68]

That was my test case.  I added cover art to a stack and both files updated.  I delete the cover art and both are deleted.  How are you adding cover art?

Just tried on my test DB and got some interesting results.

I started with both ape and stacked mp3 having cover art.

I collapsed the stack and then removed cover art, adn as should be expected the ape and mp3 files had their cover art removed when I expanded the stack.

I then collapsed the stack and added cover art from file (using a different image that I had originally used).

The ape files had the selected cover art, BUT when expanded the mp3s didn't.

The first mp3 file in the list had it's ORIGINAL cover art thumbnail back, and all the other mp3's had no cover art.

Richard

[DarkPenguin]

What are your cover art settings?

[rpalmer68]

It's set to store "In the same folder as the file (Folder.jpg)" and to "Also store image in files tag".


Richard

[rpalmer68]

Just tried with " in specified folder" instead.


If I collapsed the stack, added coverart to the top files (ape)  and let MC copy it to the folder.

When I expand the stack only the ape files have coverart.

The mp3 coverart tag says "failed to load from inside file"

Richard

[rpalmer68]

I just want to confirm this is still in issue for me in .507.

Cheers
Richard

[lalittle]

Just tried with " in specified folder" instead.


If I collapsed the stack, added coverart to the top files (ape)  and let MC copy it to the folder.

When I expand the stack only the ape files have coverart.

The mp3 coverart tag says "failed to load from inside file"

Richard

Just to add to this, I'm seeing the same "failed to load from inside file" cover art message on mp3 files once in a while even WTIHOUT using stacks.  It just seems to happen on a random mp3 file every few days.  I posted about this in one or two of the build threads, noting that I solved the issue in a couple different ways, including 1) "removing" the art from the file and then doing a quick find, and 2) doing a "get from internet" on the file.

I just wanted to mention this to point out that the "failed to load" message might not be related to stacks, but may in fact be a separate bug that is showing up in different situations.

Larry

[DarkPenguin]

We blow away the art but only refill the top file.  Depending on your settings that may or may not filter down to the stack members.  So looking into that.

The second error ("failed to load from inside file") I haven't looked at.

[DarkPenguin]

We blow away the art but only refill the top file.  Depending on your settings that may or may not filter down to the stack members.  So looking into that.

The second error ("failed to load from inside file") I haven't looked at.

Never saw the second error.  The first one should be fixed in the next build.

[lalittle]

Never saw the second error.  The first one should be fixed in the next build.

Should I send you a file the next time I notice the "failed to load from inside file" message?  If so, where should I send it?

Thanks,

Larry

[lalittle]

Never saw the second error.  The first one should be fixed in the next build.

DarkPenguin,

I discovered a whole bunch of aa files that consistently exhibit the "failed to load from inside file" issue, which is the "second error" you referred to here (which you said you haven't seen.)  These files refuse to show their embedded art, and they will not allow art to be linked to them.  Can I send you one of these files?

Thanks,

Larry

[DarkPenguin]

Is this a stack related error?  If not you might want a new thread.

[lalittle]

Is this a stack related error?  If not you might want a new thread.

It's not really a stacks related issue per se, but the specific error in question was brought up in this thread, so I thought the files could be helpful.

I already started a thread specific to this issue last week in the regular MC12 forum, but the thread hasn't received any responses yet.  Here is the link:

http://yabb.jriver.com/interact/index.php?topic=46857.msg321147#msg321147

Thanks,

Larry