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.
MM5 not showing new tracks after rip
Moderator: Gurus
Re: MM5 not showing new tracks after rip
Download MediaMonkey | License
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Re: MM5 not showing new tracks after rip
Lowlander, shall do, just waiting on a new CD in the mail : ) However:
But, happy to follow the bouncing ball and submit a debug log anyway.
Cheers
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
MM 2024.3019 (WEF 4 May 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Re: MM5 not showing new tracks after rip
Hi,
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.
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.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Re: MM5 not showing new tracks after rip
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.
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.
Using 5.1 LATEST alpha or beta build on Windows 10, HP laptop, managing 13k tracks
Re: MM5 not showing new tracks after rip
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.
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.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Re: MM5 not showing new tracks after rip
Rob,
Peke,
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
Thanks Rob, yes that's it.Rob_S wrote: ↑Thu Jan 04, 2024 11:30 am 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,
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?Peke wrote: ↑Thu Jan 04, 2024 11:43 am 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 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
MM 2024.3019 (WEF 4 May 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Re: MM5 not showing new tracks after rip
Hi Lowlander,
Cheers
Matt
Ticket #6711 submitted.Lowlander wrote: ↑Sun Dec 31, 2023 4:59 am 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.
Cheers
Matt
MM 2024.3019 (WEF 4 May 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Re: MM5 not showing new tracks after rip
Ludek reports that this is being addressed in the next release.
MM 2024.3019 (WEF 4 May 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Currently 27K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.