Crash when altering multiple MP3 tags

What I am trying to do is modify both "Encoded by:" and "Comment" via the Metadata Pane for multiple files in the same directory.
I select and modify both fields and the click on apply at the top of the Metadata Pane and all seems to be working, until I navigate away from the source folder.

DOPUS, then requests another confirmation for the modification and the displays the "DOPUS has crashed" message before restarting.

All the tags have been modified as desired before the crash, so there appears to be no data integrity issues.

I am using:

Directory Opus Pro 10.5.1.0 (4848) x64
OS 6.1 (B:7601 P:2 T:1) SP 1.0 "Service Pack 1"

Just a heads up.

Stu

I can't reproduce this so far.

How are you navigating away from the folder?

Is the Apply link still available (blue rather than grey), or are there any red triangles (indicating changed values) in the metadata list, after clicking Apply the first time?

Does it only happen with particular MP3 files?

Hi Leo,
Once again, I thank you for your speedy reply.

Once the fields have been modified, a dialog appears that displays each MP3 filename as it is modified. When the final file has been modified is when the error/restart message appears.
So far, it only seems to occur when I delete data to make the fields blank that the error message pops up.

The red arrows for each field are there after I modify the field and the Apply button turns grey after I click on it. As I said, all modifications seem to be applied with no data integrity issues that I am aware if. Dopus just seems to not like me doing it :confused:

I originally came upon this by deleting information placed in those fields by a 3rd party program. I was able to reproduce it by adding data to those fields and then trying to delete it afterwards from within Dopus its self. It only happens when I have more than 1 file selected .... the lowest group I have tried is 5 MP3 files, single files do not seem to be affected.

Thank you once again Leo for your help.

Stu.

What action is causing this? If I delete a bit of mp3 metadata from the metapane, then click Apply - it just saves the changes - I don't get any "dialogs" popping up for each file... The only time I get any dialog is if I click OUTSIDE the metapane after making changes without clicking apply. But then it's just a single dialog asking me to Save, Discard, or Cancel the changes.

Hi Steje,
A series of screen grabs will, I hope, fully explain my dilemma. As a side note, no error is produced when I add text to the fields in question.

Here we can see I have only MP3 files selected in the left pane, and both Encoded By and Comment fields have been modified to be empty. All is good. :smiley:


I have clicked the Apply button and this Progress Dialog appears ... maybe your computer is faster than mine Steje and it is not on screen long enough for you to see it. Again, all is good. :slight_smile:


I have just clicked on the right hand pane and oh oh! Where did you come from? :open_mouth: Of course I want to save the changes ..... :confused:


Hmm, clicking that Save button was a mistake. Why was I so foolish as to actually want to modify the metadata in the first place? :cry:


This, sadly, is 100% reproducable. I say that because I generated the above screen shots via the method outlined to gain these screen shots numerous times.

I hope this helps you home in on this pesky little gremlin.

Stu.

Ah, so this is different to what I was trying. You're not navigating away from the original folder (on the left), but activating the other file display (on the right).

Does it only happen if you click on the other file display while the progress dialog is still visible, or does it also happen if you wait until after the first application of changes has completed?

Well, my system has an SSD - so certainly, my quick tests save the updates near to instantly, and I never see a dialog. I'll try with a slower USB drive or maybe my NAS unit. Is "E:" a local drive or mapped network drive?

@Leo, I wonder if the time it's taking to save the metadata changes is causing Opus to start another / second thread trying to save the changes after he's clicked into the other file display while the first save attempt is still touching the files?

@Stu, is Leo right in assuming you are indeed clicking into the other file display while the progress dialog from hitting Apply is still active?

Hi Leo and Steje,

@Leo: The progress dialog only appears for 1 maybe 2 seconds, it took me a few attempts to grab that screen. But the crash occurs when I navigate away after I applied my changes and the progress dialog has closed.

@Steje: E: is local drive.

I hope this helps.

Stu.

Thanks.

But, just to make sure we're talking about the same thing, you're not actually navigating away, are you? That would mean changing folder within the active (left) file display.

From your description above, it looks like you're just activating the other (right) file display to trigger the crash, not changing folders. Is that correct, or have I misunderstood?

Hi Leo,

Actually it doesn't seem to matter which method is used, both cause Dopus to turn up its toes.
If I activate the right lister, pow, down it goes. If I use the up arrow in the already active listers title, bam, down it goes as well.
I can see where my poor recounting of what was happening has given rise to your doubts. Seeing as both methods cause the same result, I have foolishly mixed and matched my descriptions.

So in a nutshell, after I have deleted the data and pressed apply:

  1. Activating the second lister (right one in my screen shot) the "You have modified the metadata" dialog appears and pressing save causes Dopus to crash
  2. Pressing the any of the arrows in the active listers title bar the "You have modified the metadata" dialog appears and pressing save causes Dopus to crash

The 3rd party program that I am using is Tag & Rename and until last week modifying the tags within Dopus have not been an issue.

Hope that helps.

Is Tag & Rename a factor? Does this only happen with files that were modified by T&R and then modified in Opus?

Maybe it'd make sense to send us some example MP3 files along with exact steps (e.g. "select all 5 files, then set tag X to value Y, then click button A...") so we can try to reproduce what you're seeing. If you want to do that you can email them to leo@gpsoft.com.au

Hi Leo,

You were correct in reasoning that Tag & Rename was factor.The files had originally be tagged by a earlier trial version, which had inserted its own data into Comment and Encoded By fields. So when I came to clean up these tracks last week, that is when the errors occurred. The newest version I have does not seem to cause this to happen, so I'm guessing there was a glitch in the way metadata was written to the MP3 files in the trial version.

Your insight has once again solved a problem that would have had me stumped for weeks.

Thank you Leo.

Do you still have any of the problematic files? It would be good if we could take a look at them to prevent whatever was causing the crash.

Even if the fault is partially in the old version of T&R tagging the files incorrectly, incorrectly tagged files should still not cause a crash, so we'd like to fix that.

Hi Leo,

Sadly, I have now modified all the files that had been tagged by Tag & Rename.

BUT ... this error is reproducable with out the need for for T&R as I have just found out. I just ripped a new CD and this is what happened.

  1. Select 5 or more files, 4 or less and nothing happens ... odd I know
  2. Add text to both "Encoded By" and "Comments" and click on Apply ... I have not tried any other combination of fields, but these two most certainly make life tricky for me
  3. Navigate away or make another lister active ... nothing bad happens
  4. Select the same files again and delete the text from BOTH fields and click Apply ... if you do just one or the other, nothing bad happens. It has to be both. Again, odd.
  5. Navigate away or make another lister active
  6. The "Do you wish to Save Discard Cancel" dialog appears, click on save
  7. Boom! my new friend the Crash Bug appears

This works on MP3s I have ripped and MP3s from other sources ... so I dunno
I hope that my description helps you replicate what happens.

Thank you Leo.

Hi Leo,

Just a quick note, I have just installed the latest Beta:
Directory Opus Pro 10.5.1.2 (4874) x64... and this issue is still there.

I reproduced the error by following the steps listed in the post above on another batch of freshly ripped MP3s.

All the best Leo,
Stu.

Thanks for the extra details!

We haven't been able to reproduce the crash but we did manage to reproduce the extra Save / Discard / Cancel dialog and we've made a change to prevent that from happening, so hopefully that will also prevent the crash. That will be in the next beta update.

Love your work Leo and Jon.
Your quick replies and speedy fixes of code are truly remarkable. I look forward to the next release.

Thank you very much,
Stu.

Hi Leo,

Is there a size limit to files that can be attached to PM's? I have just come across an old folder of MP3s that happily cause me greif, so I rar'd them up to send to you, but I have repeatedly gotten a 404 message after the upload had completed. The size of the rar is 21mb ... I can certainly take out a few files, but I'm not sure if that would minimise your ability to reproduce what I do and where I end up.

Stu.

There's a 5MB limit on each file attachment in private messages.

If you want, you can email the file to me: leo@gpsoft.com.au

Thanks!

Hi Leo,
I think I have got this uploading thingy worked out. :slight_smile:

If you don't get the error, just repeat the steps I have outlined ... as in:

  1. Select all the files and modify the data for "Encoded by:" and "Comment"
  2. Click Apply and navigate away or make another lister active
  3. Re-select the original files and delete the data within those fields
  4. Click Apply and navigate away or make another lister active
  5. Select save and BAM! see the error .. oddly as of late you may need to reproduce steps 1-4 ... sometimes I error first time, sometimes I error 3 times ... and yes, I do typo that often

Hope that helps,
Stu