Tags: Not saving in (my) Opus 10

OK, I've searched the forum for a quick answer but I couldn't pin point a thread with similar situation as mine. So, that's why I open a new thread about it.
I've been a user of Tagged Frog and it works fine but once I upgraded to Opus 10 I wanted to stop using TF and do my tags in Opus but to my dismay, the feature refuse to work... at least on my PC.
Whether I choose to enter the tag through File--->Add Tags or choose a file and use the Metada Pane to enter it, the Tag I enter never save or appear in the file properties. Since I don't see anybody posting about it, then it must be an isolated situation on my setting of Opus? or something I'm missing generally on how Tags work in Opus?. I just thought I would be able to tag a file and recall it by sorting or through the search function, right?
As I try to show below: The orange indicator appear but after I press "Apply", the tag is not saved and appear nowhere.

Some help would be appreaciated.

Running Win 7 x64

Do you have dBpoweramp installed, by any chance?

If not, if you open RegEdit.exe and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers.mp3, what is the b[/b] value set to? (Don't change anything yet, just have a look.)

Yeah, I have dBpoweramp installed? It conflicts with Opus10 tag feature?

in .mp3 I have two fields:

Yeah, it's a conflict with dBpoweramp. (I have it installed as well with the same results.)

You can work around it by setting (Default) to have the same value as dBpowerampLAST (you might want to create a backup value with what (Default) used to have so you can restore it if needed.

FWIW I started a thread about it here, but need to look into it a bit more in light of the most recent reply (I need to check if it is saving the data but not loading it, or if it's just not saving it in the first place):

forum.dbpoweramp.com/showthread. ... post112258

OK, thanks. I'll follow up from the thread you opened then.

Just to make things a little more interesting, I have a similar issue where my tags sometimes refuse to be applied. And I do NOT have DbPoweramp installed, and I'm trying to tag .jpg's. Going via Explorer, tagging works fine. But when I add them via Dopus they do not.

Which tags are you setting?

Does it happen with all jpegs or just ones that have gone through certain programs or processes?

I'm setting the tags in "Extended Properties" via the Metadata pane, and I'm getting some very irregular behavior that makes this a nightmare to test. Will try to explain.
Every time I tag files via Explorer's Property window they show up in Dopus with now problems at all. Explorer always works.
The FIRST time I add tags in Dopus they always seems to work. But if I try to add another tag later, it USUALLY wont apply. When I click the Apply button in the Metadata pane, I can even see the new tag being removed. If I restart Dopus (not just the lister), then the tagging works initially again. And the same thing happens with ratings.

I just tried with several different Jpeg's with the same result. Some photos that has been organized in AcdSee (but with NO metadata saved to the files, and the current drive excluded from the database), some internet images, and some created in Photoshop. So I don't think it's the cause of any external program tampering with the files. If you have anything I can try, let me know. Would love to get tags working here, since my plan is to start organizing all our images with them.

It happens on two different computers, one running 10.0.1.0.4185, and one running the latest beta (10.0.1.1). All x64, windows 7.

Try my ShellExView suggestion (posted a moment ago) in case it's something similar. (It's a bit less likely if things are working in Explorer, but Opus and Explorer aren't doing exactly the same thing so it's possible a difference between the two is triggering a problem in a property/metadata handler you have installed.)

I tried ShellExView, but can't see anything special. Will keep on investigating...


The ShellExView output looks fine; thanks for trying that.

If you (successfully) tag a JPEG, then restart Opus (don't just close all the windows; fully exit via the File menu or taskbar jumplist), then try to tag the same JPEG again, does that work?

i.e. Is the problem tagging the same file twice in one session, or does something happen to the file itself that prevents it being tagged again?

If you attach a sample JPEG file and exact instructions on what to do (i.e. which tag is being set to which value), I'll see if I can reproduce what you're seeing here.

If I restart Dopus I can usually tag the same Jpeg multiple times without problems, AS LONG as I don't select any other jpeg in between. So, add one tag, deselect or select any other extension, then select the same jpeg and tag it works just fine. But if I simply select another jpeg in between, and then try to add a tag to the first jpeg, it won't apply, not to the original jpeg, nor any other jpeg after that.

Tagging .PNG files works all the time. Renaming .jpg to .png does NOT work, it has to be converted for real.

Another minor issue in the Metadata pane, if I click right after the last tag I get the ";" symbol and can add a new tag. But if I click as far as possible to the right in the entry box it doesn't show up, so I must add it manually or click again.

I cannot reproduce what you're describing, at least given the details here and with the random JPEGs I used to test with.

A fellow Dopus user at the office doesn't have any issues with tags on his computer here, but his home installation won't save tags. Will keep an eye on this and hopefully we can narrow it down.

I had problems with that too from time to time. Just recently I had a file where tags couldn't be set, but it worked for all other files in the same directory. So I started to track down the differences. All permissions have been exactly the same, but there was a difference in the ADS (Alternate data streams):

The affected file had an additional ADS chunk, called SummaryInformation that looked like this:

::clubs:SummaryInformation:$DATA 232
:OpusMetaInformation:$DATA 36
:{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA 0

while all other files only had the OpusMetaInformation chunk.

I deleted all ADS information with the streams64 tool
(>streams64 -d "Filename") and voilà, after this operation I could change my tags again in Opus.

My guess is Opus does not properly handle the ADS meta chunk when there are multiple chunks available. Hopefully this will help you guys fixing the issue.

It's 100% reproducible when you have a file with an additional ADS chunk before the dopus metadata chunk on you machine.

Thanks,
Kind regards,
Skeeve

I don't think this is true, at least in general.

Having additional ADS data is quite common.

Download a file using Internet Explorer and it will have an ADS chunk saying it came from the internet.

The file's label and tabs can be set without problems:

Which type of file(s) are you seeing the problem with?

What are the exact steps to reproduce the problem? (Starting with how to create or obtain the file and get the extra ADS data on it.)

Hi Leo,

I admit it's working with ADS zone data, but not with :clubs:SummaryInformation data which was in the specific file.

I'm seeing two differences:
1.) The sort order. zone is always sorted behind opusMetaInformation, which could indicate that the access only works properly when the metadata chunk comes first. Of course it's just a guess.
2.) There is a strange special character before the SummaryInformation name. Maybe this character causes the issue?

I'm not aware of a way to send you the affected file, without losing ADS info. If you know one, please let me know. I'm also not sure which application has created this ADS chunk, but I found several references that this comes from a microsoft component:

https://msdn.microsoft.com/de-de/library/windows/desktop/aa372456(v=vs.85).aspx

The bad thing is, I doubt you'll ever be able to reproduce this, without having a testfile with this special ADS, but from checking the forum there are many people who ran into this problem.

Hope that helps,
Kind regards,
Skeeve