INTERACT FORUM
More => Old Versions => JRiver Media Center 29 for Mac => Topic started by: aliciaviola on April 15, 2022, 06:10:35 am
-
Since MC 29 there is a very strong behaviour.
If I am typing into a tag field the field appears in the colour of the typed words and I can't read them and control wether there is a typo.
Only when I am going to another field the letters are visible. I tried different skins but the effect remained.
Frank
-
With the skin I'm using, it's bright blue on a dark blue BG, pretty easy to read.
Are you using one of the twilight skins?
Is your MC set to use dark/light themes and if so was there some consistency with when you see the issue?
-
I had the issue with Modern Card Dark edition and Purity.
A first test with Twilight worked - I never tried that.
-
You might be interested in The Dream in Blue skin.
https://yabb.jriver.com/mediacenter/accessories.php
Standard view skins
Most recent
First entry.
It's pretty much my default now.
-
You might be interested in The Dream in Blue skin.
https://yabb.jriver.com/mediacenter/accessories.php
Standard view skins
Most recent
First entry.
It's pretty much my default now.
It is very nice but I don't seem to be able to change the width of the tag frame on the left. Am I doing something wrong or is it not changeable?
-
It is very nice but I don't seem to be able to change the width of the tag frame on the left. Am I doing something wrong or is it not changeable?
It's the same as all other skins. You grab the area between the frames and drag. You might have to move around a bit on the frame area until you find the handle. In some cases for me, the handle appears and in other cases it does NOT appear. But I can always change the width of the tag window vs the main window. Play around with it and I'm sure you'll find the right spot.
Brian.
-
On the original subject of text being the exact same color as the box where you type it (thus making it invisible):
I've had this happen 3 or 4 times since switching to MC29. My I've been able to see the text after clicking on another field and then coming back to the original field.
But, I can't seem to duplicate the behavior. I've tried a few different things and can't find the right combination of actions which cause it to use same color text.
Aliciaviola: If you see it happen again, try to note what you did and see if you can reproduce it.
Brian.
-
It's the same as all other skins. You grab the area between the frames and drag. You might have to move around a bit on the frame area until you find the handle. In some cases for me, the handle appears and in other cases it does NOT appear. But I can always change the width of the tag window vs the main window. Play around with it and I'm sure you'll find the right spot.
Brian.
Thanks Brian, I found it.
-
It's still the same, even with The Dream in Blue skin.
The strange thing is, that it happens not regularly.
The last time I pasted text from another field and the text only as visible when I skipped to another field.
It happens quite often and not only when pasting text but equally when I am going from one field to the next
with the tabulator key.
-
I can confirm a similar experience. It's sporadic and I don't know what triggers it. Next time it comes up I'll pull a log.
-
Figured it out. It's tabbing when there is a floating edit window in the list.
Took a while to figure out but it will be fixed in the next build.
-
Great!
-
Figured it out. It's tabbing when there is a floating edit window in the list.
Took a while to figure out but it will be fixed in the next build.
Great, thanks Bob!
I just had it happen again and was about to submit a log
-
With the last build that seems to be fixed.
Frank
-
Sorry a too early hurrah, the fault still exists.
-
Confirmed. I still see the bug as well using 29.0.39.
I need to go home and check the version I'm using and make sure it's the latest (38, not 39).
Thanks,
Brian.
-
You are going to need to give me a way to reproduce it as I can no longer do so with the current build.
-
It's probably difficult to reproduce but I hope this helps:
In this actual case I filled the tag fields for a new recording from the radio and went from field to field
with the "page down" key. In the comment field I typed "?" and several possibilities were displayed but
you can't see the text I typed in the field (photo is attached and the last log).
-
The bug still is there. Am I the only one who has this problem?
Frank
-
The bug still is there. Am I the only one who has this problem?
Frank
I see it, too, occasionally
-
And regrettably the fault still is there
-
I'm letting this one sit for a while, got other things to do and it's not consistently repeatable and the code around it is incredibly complex.
You can bump this thread in a month or so.
-
More than a month ago. And the bug still is there. Only as a reminder...
-
In the meantime it's August and finally a new build that fixes some bugs.
Regrettably not this one....
-
In the meantime it's August and finally a new build that fixes some bugs.
Regrettably not this one....
The latest build was released to fix a license issue.
-
Guys if you look closely at the image in reply #7 the "Comment" tag/field is showing all the characteristics of one that is defined as "List" but it's data type is "String"
Oh and guess what it's the same in the Windows Version
-
Guys if you look closely at the image in reply #7 the "Comment" tag/field is showing all the characteristics of one that is defined as "List" but it's data type is "String"
Oh and guess what it's the same in the Windows Version
If you type a letter, you will see suggestions for string data types as well.
So the screenshot seems right as far as the data type.
If you see something else, please provide some more details. Thanks.
-
Matt - there is definitely something odd going on in both Tag Windows in the windows & mac versions of MC
With the Advanced Section of the Modern Tag Window open I entered some data into both the Band and Comment Fields.
Then I alternated between clicking on the Tag Name and Tag Contents, to be able to edit the content; sometimes the content of the field was visible and sometimes it was not!
I then got the same behaviour when I tried doing the same thing with the Legacy Tag Window.
-
Any hope that this finally will be solved?
Frank
-
I haven't been able to reproduce on Windows.
-
But on the Mac this issue is there for some months now and reproducible as I think.
For some time now - save the video bug fix for the last update - nothing new happened
with the Mac software.
Frank
-
I haven't been able to reproduce on Windows.
Matt it can be a tricky thing to reproduce. The tag windows will behave correctly for hours and then suddenly start playing up. Oh and the "odd behaviour" is not restricted to string fields I've seen it happen with other types of fields, like Disc #, on both the windows and mac platforms.
-
I've seen it happen with other types of fields, like Disc #, on both the windows and mac platforms.
On the same hardware?
Such "odd behavior" is often a video hardware or driver problem.
-
For some time now - save the video bug fix for the last update - nothing new happened
with the Mac software.
You have to be kidding... Television?
I have to say that we spend a lot more time chasing problems caused by Apple than we do with Windows. Their development tools are almost amateurish.
Let the slings and arrows fly.
-
I do not believe this problem is related to drivers or hardware. Multiple people have reported the issue including me.
I don't see it as much of a problem. It's mildly annoying. I do not have a good sequence of events to reproduce it. I thought I had a procedure. Then I tried it 3 times and couldn't get it to happen again. Perhaps someone will figure out a good way to make it happen most of the time and then maybe it can be diagnosed properly.
The worst kinds of problems to fix are those that are difficult to reproduce. Which is exactly what this one is. :)
I'm still very satisfied with this version of MC. In fact I just purchased a pre-release of MC30.
Brian.
-
Something I forgot to mention.
My preferred method for changing/amending tag/field content is to expose the relevant tag/tags in the detailed list in a view and edit the tag/tags there and not in either of the tag windows.
Thankfully I've never encountered any kind of odd/weird behaviour when using that method
JimH - Take a look at my forum profile and then kindly explain just how 2 totally different PC's with very different operating systems and divers can suffer from exactly the same ""video and hardware and driver problem" in exactly the same area of the MC code but not others.
-
Thought I'd try, on the Mac Mini" to see if the Strange/Erratic Tag Window Behaviour was being caused by something else MC was doing. So I made sure that MC29.0.86 was the only thing running on the Mac before opening it.
After opening MC I immediately opened the Modern Tag Window I selected a Track to bring up it's Metadata in the Modern Tag Window but did not tell MC to play anything.
As soon as I pressed on the Word "Name" in the Tag Window MC misbehaved, by showing No Content for that Tag, it then went into Random Mode and would switch between showing and not showing the content for that tag when I clicked on the tag's name. It also started showing the same behaviour when I clicked on the names of other Tags; but as image #4 in the attached pixos gallery https://pix01.jriver.com/wL1%40FMs51 (https://pix01.jriver.com/wL1%40FMs51) reveals editing the Track # Tag in the details panel does show the Tag Content even though the highlighted (selected) entry in the Tag Window appears to be claiming the tag is "empty".
However after switching to the Legacy Tag window I could not get MC to misbehave so it looks like the problem may be restricted to the Modern Tag Window.
So it looks like the best way of Avoiding the Problems is to only use the Legacy Tag Window or the Details List when editing tags
-
Maybe it's because you're pressing on the word "Name" and not on the empty space to the right?
-
Maybe it's because you're pressing on the word "Name" and not on the empty space to the right?
It doesn't matter if I click on the word "Name" or any other part of the "Field Label" in the Tag Window the Field Name and all of the slightly darker grey color behind its Name is a single "Clickable Target".
-
I see, that Bob is back from his holidays.
Hopefully things will be better now.
-
Matt - there is definitely something odd going on in both Tag Windows in the windows & mac versions of MC
With the Advanced Section of the Modern Tag Window open I entered some data into both the Band and Comment Fields.
Then I alternated between clicking on the Tag Name and Tag Contents, to be able to edit the content; sometimes the content of the field was visible and sometimes it was not!
I then got the same behaviour when I tried doing the same thing with the Legacy Tag Window.
Trying to test this on Mac. I can't reproduce it so far.
Did you allow MC to have screen recording permissions? Sometimes it grabs content from a window, stores it and puts it back.
It can't do that without recording permissions.
-
Bob - yes I did give MC every Permission it asked for.
As I said in an earlier post sometimes MC will behave itself for ages before switching itself into "Village Idiot Mode on the Win and Mac Platforms" and start pretending that Populated Tags are Empty.
The one thing I have discovered though is that if MC is just sitting there doing nothing else The Modern Tag Window has a tendency to Immediately drop into Village Idiot Mode
I've attached 2 links to Videos that clearly show the problem.
The 1st one was supplied by another user, who has asked me not to reveal their identity
The second one starts with MC sitting doing nothing and reveals that sometimes it immediately does start acting up.
However, once I let MC play that track sometimes it would behave itself, then go into Village Idiot Mode, only to switch back to behaving itself. Though towards the end of the video when I was looking at the Track # Tag it did something odd - the cranky thing looked like it was going to behave and did reveal the content to then change its mind and decide the tag was empty.
There is one situation where, no matter how often I opened and closed the Tag, MC always behaved itself and that was with a Tag where the Tag Type and Edit Type were both "List" and the tag had more than one entry. i.e. a Track where there was more that 1 Composer.
Video 1 https://www.dropbox.com/s/nwxawqtpork1tun/Screen%20Recording%202022-09-10%20at%2007.28.10.mov?dl=0 (https://www.dropbox.com/s/nwxawqtpork1tun/Screen%20Recording%202022-09-10%20at%2007.28.10.mov?dl=0)
Video 2 https://www.dropbox.com/s/3fhkx6f4196ytda/Screen%20Recording%202022-09-10%20at%2008.01.15.mov?dl=0 (https://www.dropbox.com/s/3fhkx6f4196ytda/Screen%20Recording%202022-09-10%20at%2008.01.15.mov?dl=0)
-
I haven't been able to reproduce that on Windows. Does the same happen there for you, or is it Mac only?
Any extra clues that might help us reproduce?
Thanks.
-
Matt - when running MC on the Win PC when/or if the Modern Tag Window will start misbehaving is unpredictable. For hours and even days it will behave normally and then suddenly misbehave once or twice when opening and closing a Tag to edit it, then revert to behaving normally.
In addition, unlike with the Mac, I found it extremely difficult to get the tag window to misbehave when nothing was playing.
It may even be possible this "odd/miscreant behaviour" may have been around since the introduction of the Advanced/Modern Tag Window. Once I'd observed it in MC29 on both platforms, I started downloading previous "generations" of MC. I went back as far as MC24 on both the Win and PC platforms and, even though I sometimes ended up opening and closing the same tag for hours on end I did observe the same "odd behaviour" on both platforms in MC24 thru MC29 and the MC30 Beta's on the win pc.
-
Longshot, but take a look at the jmd files in this and other nearby folders:
C:\Users\[username]\AppData\Roaming\J River\Media Center 29\Library
Your description sounds like occasionally the appropriate file can't be opened or read. Antivirus is always my hunch with problems related to opening files.
-
Longshot, but take a look at the jmd files in this and other nearby folders:
C:\Users\[username]\AppData\Roaming\J River\Media Center 29\Library
Your description sounds like occasionally the appropriate file can't be opened or read. Antivirus is always my hunch with problems related to opening files.
My testing has been done on both PC's mentioned in my Forum Profile plus on my older Win 10 PC, it's too old to be upgraded to Win 11.
The chances of 3 different operating systems, each one with its own AntiVirus and Firewall Software, misbehaving in exactly the same way in only one area of MC have to be somewhere between Extremely Low and Impossible.
If you look very carefully at the screenies attached to my earlier posts, or the 2nd video in the more recent one - most of the tags where the misbehaviour is observed the Tag Window was displaying the tag's content, before the Tag was opened to allow me to edit it. Plus, when MC reverts back to behaving it continues to display the content of the relevant tag.
In addition, over the last 3 months I have on all 3 pc's been making sure that all of my tracks contain all the Metadata I want them to have/display which has involved me in updating lots of tags, including the ones that I've used to help demonstrate the misbehaviour, without encountering any problems.
-
Are they all three reading from the same drive?
Sorry but I don't re-read each thread before answering.
-
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?
-
Are they all three reading from the same drive?
Sorry but I don't re-read each thread before answering.
Nope - With each PC the tracks MC knows about are held on an internal drive that only that PC has access too.
-
It's not the tracks. It's the library (database) that matters.
-
As with the tracks each PC has its own library and ancillary files
-
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.
-
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.
-
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.
-
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?
-
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.
-
"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.
-
"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.
-
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.
-
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.
-
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.
-
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.
-
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 - 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.
-
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
-
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
-
Try ctrl 1, 2, 3, 4, 5. I know Apple calls the ctrl key something else.
-
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.
-
I don't think you should be able to get it behind the UI with 30.0.10.
Had you updated to that?
-
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.
-
Same with me. I can't see MC 30... up to now.
-
MC30 isn't available yet.
https://yabb.jriver.com/interact/index.php/topic,133708.0.html
-
It would be extremely helpful that a new build would fix this bug.
-
It may not be a bug. In fact, it's unlikely.
-
It may not be a bug. In fact, it's unlikely.
Could this hinge upon the definition of 'bug'? ;D
-
Maybe
-
Hopefully it will be history with MC 30.
Or a new build? The last one is some time ago.
-
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.
-
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.