Print

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

[EnglishTiger]

As with the tracks each PC has its own library and ancillary files

[EnglishTiger]

Do you think there's any chance it's something about your library?  You could send a backup to matt at jriver and I could see?

Matt since I'm not the only person to encounter this "odd behaviour" I doubt if it could be a "Library Problem".

However, since they may provide some clues, I am about to send you a MC29 Library Backup from the Mac and a MC30 Backup from my older Win10 PC.

[bob]

I suspect it's a uninitialized variable but that's just a guess.
It sure would be good to be able to reproduce it consistently, otherwise it's going to be nearly impossible to find.

[blgentry]

Here's one way to reproduce it 100% of the time.

* Open the Tag Action Window
* Click on some piece of media to select it
* In the Tag Action Window, click on a field.  It will become editable.
* Click back on the exact same piece of media.  Now the selected field will blank out the field value turning it to a different color.

I don't think that behavior is intentional.  I think it's a manifestation of the problem in this thread.

Brian.

[bob]

Here's one way to reproduce it 100% of the time.

* Open the Tag Action Window
* Click on some piece of media to select it
* In the Tag Action Window, click on a field.  It will become editable.
* Click back on the exact same piece of media.  Now the selected field will blank out the field value turning it to a different color.

I don't think that behavior is intentional.  I think it's a manifestation of the problem in this thread.

Brian.

Not sure that's the same, the edit box control closes then.
Isn't the issue that the edit box is open and you can't see the text in the field?

[bob]

Actually for that case I see what's going on.
Tested it for windows and it doesn't close the box.
It turns out the box isn't actually closed, the focus change (clicking on the track with the edit box open) makes the UI come to the front.
The edit box is still there. It's below the UI. You can see it by moving the UI to the right or left to uncover the underlying edit box.

This particular case is due to the fact the windows automatically stacks the windows whereas linux doesn't do that at all and Mac does it differently.

[aliciaviola]

"I suspect it's a uninitialized variable but that's just a guess.
It sure would be good to be able to reproduce it consistently, otherwise it's going to be nearly impossible to find."

It's consistently. Every time I am working with tags on my Mac (newest software, newest MC build). And that's every day
a hundred times.
It really can't be that this is only reproducible for a handful (two?) people.

[bob]

"I suspect it's a uninitialized variable but that's just a guess.
It sure would be good to be able to reproduce it consistently, otherwise it's going to be nearly impossible to find."

It's consistently. Every time I am working with tags on my Mac (newest software, newest MC build). And that's every day
a hundred times.
It really can't be that this is only reproducible for a handful (two?) people.

It certainly can be!

Like I said in my last message above, we did reproduce that specific case.
It involves the order in a sequence of clicking (and is triggered by the shortcut of leaving the field edit control open allowing switching of tracks to simplfy editing a group of files).
That particular one involved a focus change and window ordering change that only happened when the same line that the tags were being edited on was clicked with the edit open. This is non-windows only for sure.
We seem to have figured that one out. Whether or not it will apply to the other use cases is not clear.

[blgentry]

Not sure that's the same, the edit box control closes then.
Isn't the issue that the edit box is open and you can't see the text in the field?

When the bug occurs, the field goes to a background color and the text is hidden.  This is what happens with my procedure above and every other time I've seen this happen.

See this video that was posted earlier in the thread:

https://www.dropbox.com/s/3fhkx6f4196ytda/Screen%20Recording%202022-09-10%20at%2008.01.15.mov?dl=0

See how the field becomes a different color and the text "disappears"?

Thanks,
Brian.

[EnglishTiger]

blgentry - Thanks for reposting the link to the video showing The Tag Window misbehaving.

Since I was intent on getting MC to misbehave there is something in that video that I dd not notice until I revisited it via your link

When creating a skin a skin creator provides 3 Textures:- Group, FieldLabel and Field for the Modern Tag Window

"Group" is the one used for the "Section Headings" in the Modern Tag Window, "FieldLabel" is the one behind the Field/Tag Names and "Field" is a 2-Part Image where the 1st Part provides the background for the Field Content when he field/tag is in i's closed state with the 2nd part provides the background when it is in its Open/Editable state.

In that Skin:- "Group" is the darker of the 3, incidentally it is also a 2-part image, part 1 for when the Group/Section is collapsed and part 2 for when it is expanded.
"FieldLabel" is the slightly lighter one while "Field" is the even lighter one. If you carefully watch the video when MC behaves itself when opening a tag to edit it, the background correctly looks similar/identical to the FieldLabel background. But when it misbehaves the user gets to see an empty field with a darker grey background.

Since that skin was created by me, I have been able to Identify which Image/Texture could be providing that Darker Grey background; hopefully this may give Matt & Bob some more clues to what's going on, of the 3 Textures used by the Advanced Tag Window the one that uses that Darker Grey is the "Group" one!!

I am basing my assumption on the simple fact that it is the only Darker Grey Image the Skin uses which, like the empty box that appears when MC is misbehaving, does not have any borders as a part of the image.

[bob]

When the bug occurs, the field goes to a background color and the text is hidden.  This is what happens with my procedure above and every other time I've seen this happen.

See this video that was posted earlier in the thread:

https://www.dropbox.com/s/3fhkx6f4196ytda/Screen%20Recording%202022-09-10%20at%2008.01.15.mov?dl=0

See how the field becomes a different color and the text "disappears"?

Thanks,
Brian.

When the text "disappears" try grabbing the UI and move it to the side to see if the text box underneath.

[blgentry]

I tried "moving" the tag window; it appears fixed in place.  So I grabbed the title bar of the main MC window and moved it.  Everything stayed together.  There was nothing underneath. 

But I run MC maximized all the time.  It's in a window, but that window is in some special state.  (I know it's "special" because MC toggles between maximized and windowed when you double click the title bar.  Or when you drag it from a maximized state, it goes windowed.) 

So I got it to a window (not maximized) and tried again.  ...and again and again.  It took me quite a few tries because when you rapidly move the MC window, it wants to maximize again.

But I finally got it to happen.  Bob is correct!  In my particular sequence of events, the editing dialog is behind the main MC window.  Disembodied like a floating finger or arm or something.  All by itself.  So weird.

I have trouble reproducing this bug in the "normal" way like English Tiger does. ...and I always run maximized so I'm unlikely to be able to move the window when it happens.  Hopefully someone else can have it happen and move the window.

Or perhaps we can get a MC release sometime soon with the fix that you've implemented?  Then we can test that one to see if it happens.

Thanks,
Brian.

[EnglishTiger]

Bob - when I tried to move the UI to the side, like blgentry the only place I could grab hold of the UI was at/or close to the top of the UI. Every time I did that, I spotted that the open tag closed and dragging the UI to the side resulted in it reducing down to the minimum size specified in the skin.xml plus that was the only window visible/present on the desktop.

[bob]

Bob - when I tried to move the UI to the side, like blgentry the only place I could grab hold of the UI was at/or close to the top of the UI. Every time I did that, I spotted that the open tag closed and dragging the UI to the side resulted in it reducing down to the minimum size specified in the skin.xml plus that was the only window visible/present on the desktop.

Grabbing by the header is the normal way to move the window so that's fine.
The time to move it is when the problem has been generated. The easiest way to do that is to get into tagging mode for a track, click on a field to bring up the edit box, then click on the same track in the track list again. Where the edit box was then goes blank. Move the UI and you should see the edit box underneath.

[HaWi]

Grabbing by the header is the normal way to move the window so that's fine.
The time to move it is when the problem has been generated. The easiest way to do that is to get into tagging mode for a track, click on a field to bring up the edit box, then click on the same track in the track list again. Where the edit box was then goes blank. Move the UI and you should see the edit box underneath.

Bob, I think I got it on my iMac

[HaWi]

I foolishly quit MC while the window was moved so now, when I open it, I cannot move it back. Is there anything I can do to get it back centered?
many thanks

[JimH]

Try ctrl 1, 2, 3, 4, 5.  I know Apple calls the ctrl key something else.

[HaWi]

Try ctrl 1, 2, 3, 4, 5.  I know Apple calls the ctrl key something else.

Thanks Jim, that would be cmd in Apple speak. I played around with different views and got it fixed.

[bob]

I don't think you should be able to get it behind the UI with 30.0.10.
Had you updated to that?

[HaWi]

I don't think you should be able to get it behind the UI with 30.0.10.
Had you updated to that?

Sorry, Bob, I am still on 29.0.87. I didn't know 30 was already out. My bad
EDIT: I am looking but I cannot find MC30 for MacOS. Did I miss something? I know I bought the license a while ago.

[aliciaviola]

Same with me. I can't see MC 30... up to now.

[JimH]

MC30 isn't available yet.
https://yabb.jriver.com/interact/index.php/topic,133708.0.html

[aliciaviola]

It would be extremely helpful that a new build would fix this bug.

[JimH]

It may not be a bug.  In fact, it's unlikely.

[HaWi]

It may not be a bug.  In fact, it's unlikely.

Could this hinge upon the definition of 'bug'? 

[JimH]

Maybe

[aliciaviola]

Hopefully it will be history with MC 30.
Or a new build? The last one is some time ago.

[blgentry]

Unfortunately, I think they have unofficially "frozen" MC29.  So there will probably be no more 29 builds.  Fortunately, I also think that means that the first public build of MC30 is probably pretty close.  Probably less than 30 days.

I have no special information about this.  I'm stating my opinion based on what I've seen posted on the forums and prior experience.  I could be wrong about both of these things.

Brian.

[EnglishTiger]

Guys this posting by bob gave us a clue that the fix to the problem will be in MC30 and not MC29

I don't think you should be able to get it behind the UI with 30.0.10.
Had you updated to that?

However, extensive testing revealed that the problem is not restricted to the Mac Platform; although it is harder to induce it also happens in Windows. In addition, it is not restricted to MC29, not only did I encounter the same "strange behaviour" in MC24, 25, 26, 27 & 28.
I also discovered that the problem was more extensive than had been reported so far, I discovered several different, sometimes unconnected, ways of inducing the behaviour.

For some very valid reasons Matt and Bob decided to take a "step by step" approach to developing/implementing a solution, on all platforms, as a means of avoiding "regressive behaviour", one change to an area of the tag window code having a detrimental effect elsewhere in the tag window.