Rusty -
Confirming *not* the folders node.
Cheers
Matt

Hi Matt,

Thanks for the report about the 'collapse' issue. We've already fixed a related bug ( https://www.ventismedia.com/mantis/view.php?id=21150 ) so this should be resolved in the next build.

As to the originally reported problem, I still can't replicate. Could it be that the edits were made in the 'Folders' node rather than in Music > Location? The folders node isn't a library node--it shows tracks based on their actual tag metadata, so perhaps the track tags hadn't yet been updated when you presed F5?

-Rusty

Rusty and Lowlander,

Sorry for not being clear again, it is difficult to describe all of the necessary context. I have clairified my previous post to make clear that I was working in a [b]list view in the centre panel[/b] with a sorted/filtered view derived from [b]All Files within the Entire Library[/b] node. I'll try to remember to capture as screen shot for context and post via imagebb.

So, to answer the question, no, the location>list by album was not the view that I had the issue in.

Rusty

Have installed Build 3049.

I am trying inline edits with the [b]location>list by album view [/b]for an album now, but it is difficult to use because [b]it keeps reverting to the show of 5 tracks[/b], and I'm having to continually select the small control to show all tracks (30) for editing, even for tracks that I'm in the process of editing. This auto contraction seems to wait until I click in the Lyric panel at right to get lyrics showing, and then auto contracts after about 30 seconds, recurringly. This effect is so bad that it's not worth my while to do any more editing in this view. I've only done inline edits for two tracks in and F5 did not suppress display any of those edits. If you can advise a way to have the view not reset the location>Albumview presentation to the small view then I'm happy to start edits again.
 
I was initially reluctant to move to 3049 because you have turned off the ctrl+Mouseheel zoom, which (even with its problems) was the easiset way for me to zoom out to get good screen usage plus also zoom in to get good big album art images for the albumart icon (grid by album view) for a playlist. However, a combination of skin size (small for working and large for icons) and left/right panel drag left/right for wrapping the icons is workable enough.

Cheers

Matt

What node in the Media Tree is selected when you do the edits and F5?

Hi Matt,

I tried replicating this with RC-2 (build 3049) following your rough steps, and was able to trigger the issue described at https://www.ventismedia.com/mantis/view.php?id=21180 (though I'm not sure if that's what you were experiencing). It's also possible that the issue has already been fixed in 3049 since there have been several fixes since 3044 related to inline editing, and edit problems in the Location node [List (by album)] view. Is this the view in which you experienced the problems?

F5 shouldn't have any limitations wrt to refreshing a view. Lowlander was just suggesting using F5 in case there was a bug causing the view to not refresh automatically.

Would you mind updating to RC2 and letting us know if the issue is partially fixed and/or the remaining problem is the one I've described above?

Thanks!

-Rusty

Rusty and Lowlander,

Sorry for my initial explanation not being clear, and I need to emphasise that this is [b]not associated with edits to the CD identification screen[/b], which I assume is the same one as the CD drive under the Locations node. I do understand that edits there are not necessarily permanent. This problem is to do with data in the Main List, after the CD has been ripped.

Steps that I undertook in the reported instance were:
[list]MM running for a while (DbgView, uncertain)[/list]
[list]Working in the main list of the centre panel with a list view derived from "All files" under the Entire Library node[/list]
[list=]Inserted a new CD, a compilation album of a TV show soundtrack (Sample People). Lookup failed to find it and so all values were at their default "Unknown". [/list]
[list]Ripped CD anyway and all of the CD files turned up in the library.[/list]
[list]Updated the AlbumArtist, Album, AlbumArt and some custom field values via bulk select and Properties pane. New values showed up in the main list as expected. [/list]
[list]Updated the track Artist and Title for the Sample People tracks via inline edit, one at a time top to bottom, took a while with 18 tracks. All editied values showed in the main list so everything seemed normal, as it had in many other similar instances over the past years with MM. [/list]
I had another CD to rip and so, in accordance with relatively recent advice offered by a moderator in the forum, I used F5 to refresh the view of the main list before initiating the rip of the new CD.

As soon as the refresh happened, that is when about half of the inline edits of the Sample People files disappeared from the main list. The disappeared info was as follows:
[list]About half of the tracks were affected by the disappearance.[/list]
[list]The affected tracks of the Sample People album were randomly distributed through the 18 tracks of the album.[/list]
[list]For an affected track, all of the inline-edited info was absent, while all of the info populated through the Properties screen was present. [/list]
[list]When I checked a couple of the affected tracks in the Properties screen, the inline edited information was also absent there as well, which REALLY worried me because it looked like MM had vaporised the inline-entered data. [/list]
I then restarted MM, and was thankful to see that the inline-edited data was still present, so I characterised the problem as a display issue and not a data issue.


The only inking I have here about a cause is that[b] I used a variety of means to progress between inline edits[/b], being a random combination of tab, enter and click elsewhere, with the difference depending on where information that I needed for the edits was at the time. Its the only thing I can think of that might account for some tracks having the display of their inline edits preserved (eg via use of Enter) versus others where the inline edits were not visible (eg Tab or click elsewhere). Note that these are just examples, I haven't done enough experimentation to pin down MM's "exit from edit field" behaviour.


Regarding the use of F5 to refresh the view, here is a post from the thread "MM5 not showing new tracks after rip" suggesting use of F5 to get post-rip view of all files:
[quote=Lowlander post_id=515785 time=1703758834 user_id=262]
Does this happen with Build 2829, does F5 fix it?
[/quote]
I have also been recommended to use F5 before selecting all files for a File Report.
Why would F5 break the view of recent edits?
And [b]if there are now limitations on the use of F5, what are they?[/b]

Cheers

Matt

fyi, there was another possibly-related issue reported at https://www.mediamonkey.com/forum/viewtopic.php?t=106517 that we were also unable to replicate (and pushed to post 2024.0).

It sounds like a serious issue, though, so I'm hoping that with step by step reproduction instructions we'll be able to replicate/fix this for 2024.0 (or that the fix to https://www.ventismedia.com/mantis/view.php?id=21160 in a post-3045 build also solves this).

Thanks!

-Rusty

We're unsure what you're doing. You mentioned F5 on a CD after editing it. Is this not what you're doing? Please provide detailed steps to reproduce and feel free to [url=https://www.mediamonkey.com/forum/viewtopic.php?t=97733]add Screenshots[/url] to explain this better.

Sorry for the confusion guys - I was aware of tagging of CD information being temporary until it is ripped.

The problem I'm reporting here is for data on a CD that had already been ripped - to all intents and purposes the [b]files were already in the library[/b], and I was filling in all of the information that the auto tag process had failed to find (artist, album, title etc). That is why I was concerned - MM failed to display edited information for tracks that were already in the database. They had only been in the database for an hour, but in is in, right?

Matt

Hi Matt,

Thanks for bringing this to our attention. The bug with cdplayer.ini functionality will be fixed in the next build.

-Rusty

CD info is only saved to the database once you Rip the CD and then for the ripped files. CD info itself is saved to CDPlayer.ini and there may be a bug with this: https://www.ventismedia.com/mantis/view.php?id=21164

Lowlander, I'm still confused and now a bit worried.

What you have stated is that data that I enter via inline edits is lost from the screen's display of the main list when I use the refresh command. But - at some point the data is committed to the database (a very good thing) because it was all there after I restarted MM.

If F5 causes the display on the main list to be different from the database, is there anything I can do to get the edited data to redisplay without restarting MM? Please note that I have reported a similar matter regarding the erroneous display of Ratings.

Looking at the tenor of some of the other commentary in the forums, it would appear that others have been concerned about this lack of consistency in the display of entered data.

I am obviously missing something about the movement of data from edit field to the database, and would welcome any further explanation.

Also, if there are circumstances where F5 Refresh should not be used, then please point me to guidance in the help text so i can avoid this difficulty in future. If such is not present, then it should be.

Matt

You're refreshing the view, as the data you entered isn't saved, it's lost on a refresh as you're reloading the files. This is not a scenario you should use F5.

On the latest 2024, all edits are lost and this seen both in the Filelisting and Properties.

Lowlander, Version is 2024.0.0.3044.
I don't understand your comment about 'revert', can you explain please?

Thanks
Matt

Which Build (Help > About) of MediaMonkey?

On 2024 I see all files revert, which seems expected as changes aren't actually saved to the files.