MM5 not showing new tracks after rip

[Lowlander]

Please capture the failure to show last ripped track in a debug log (step 4b) and attach the log to a Support Ticket: viewtopic.php?t=86643

This will help a developer analyze why this happens on your setup.

[MattTown]

Lowlander, shall do, just waiting on a new CD in the mail : ) However:

The good news is that as per your suggestion, pressing F5 did immediately show the last track.

That is by design so that RIP and other library track add do not interrupt your current work.

It would appear from Peke's post that a requirement for the user to press F5 after rip to display the last track is (currently) intended behaviour, If so, this is not confined to my installation and looking at a debug log might be a waste of effort.

But, happy to follow the bouncing ball and submit a debug log anyway.

Cheers

[Peke]

Hi,

It would appear from Peke's post that a requirement for the user to press F5 after rip to display the last track is (currently) intended behavior, If so, this is not confined to my installation and looking at a debug log might be a waste of effort.

Auto Refresh depends on views, but if you find any case we as always consider it to change, ATM I do not see it and do not know how to present it for rest in order to be fixed.

e. if I select several tracks in Entire library -> All tracks then Auto refresh would clear that selection in order to update view, but if it does not refresh then after I finish what I intended with selected tracks I can refresh with F5.

[Rob_S]

Bit of a contradiction here - you say the lack of auto-refresh is by design, yet you do not know how to describe it.

Very simply, there should be an automatic F5 (refresh) function at the end of the RIP process, so all tracks show up right away.

If as stated previously, a manual F5 by the user does achieve this, it should be very easy to include it in the process one time at the end.

[Peke]

If as stated previously, a manual F5 by the user does achieve this, it should be very easy to include it in the process one time at the end.

It is possible, but as I said above it would interfere with current selection and break current work. My Entire Library -> All tracks is 200k+ tracks, auto refresh would unselect all of my tracks and move focus to different part of library for at least few seconds, so that would be very annoying. Same goes for MM tree and other aspects of MM view which is undesirable at least.

Bit of a contradiction here - you say the lack of auto-refresh is by design, yet you do not know how to describe it.

Exactly, two functions that collide each other where it works for one and not for others is very hard to describe in order to satisfy both. That is why ".... (Auto refresh)" option exists in order to work in both cases.

I always use Auto playlist with both cases and different behavior as an example.


Same with Library I prefer non Auto Refresh option in order to not intervene with my work on MM library.

[MattTown]

Rob,

Very simply, there should be an automatic F5 (refresh) function at the end of the RIP process, so all tracks show up right away.
If as stated previously, a manual F5 by the user does achieve this, it should be very easy to include it in the process one time at the end.

Thanks Rob, yes that's it.

Peke,

It is possible, but as I said above it would interfere with current selection and break current work. My Entire Library -> All tracks is 200k+ tracks, auto refresh would unselect all of my tracks and move focus to different part of library for at least few seconds, so that would be very annoying. Same goes for MM tree and other aspects of MM view which is undesirable at least.

I can see that we all have different ways of utilising the many functions of MM, but I won't pretend to understand how inserting a screen refresh for the final file in a rip will break the other (non rip) scenarios you discuss. I'm imagining that you don't mind the last file anomaly because you're happy to get round to the ripped files some time later, by which time some other refresh will make it visible. Looking closer at what you say, am I right in thinking that a system-initiated refresh would refresh all tabs, not just the foreground tab? And if you have a rip running, that final refresh will break a selection process that you have going on in another tab? If so, why doesn't the refresh for each of the rip files before last break your selection? And if that doesn't break your selection, why would displaying the last file do so?

I don't actually have a difficulty with having to press F5 at the end of a rip to get the last file to show, but that's only because I've been educated about it through this forum post.

From a broader perspective, I think that MediaMonkey has a usability problem because the behaviour that a casual user could reasonably expect is for the program to show all files that have been ripped, and there isn't currently any way for a casual user to know that that they have to press F5 to make it work right. If a user-induced refresh remains the way to go, then I strongly suggest that you put a text prompt into the rip dialog box to inform the user of the necessity of a final F5 screen refresh at the end of the rip.

Cheers
Matt

[MattTown]

Hi Lowlander,

Please capture the failure to show last ripped track in a debug log (step 4b) and attach the log to a Support Ticket: viewtopic.php?t=86643

This will help a developer analyze why this happens on your setup.

Ticket #6711 submitted.

Cheers
Matt

[MattTown]

Ludek reports that this is being addressed in the next release.