-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The "Find Exact Matches" action appears to be dysfunctional? #28
Comments
Opening a new issue was the right thing, like you have done now was the right thing to do. In principle every question in new issue, unless it is about one an the same thing. If you want to chat, I created a Discord channel. |
Thank you very much, @Borewit. Let's see how it goes. Maybe later? Are you perhaps on Telegram, as well? I can join you on the latter, already. |
@touwys , you reported it did work when you created a playlist with some audio tracks on In the mean time, I will work on a log file (#35), and eliminate suppressed exceptions, so I can hopefully find an exception somewhere. |
I was already planning to carry on testing along the lines you propose. It makes sense that way. I'll start by copying the same files with their playlist to several other drives, and take it from there. |
I am reporting my findings on listFix_2.5.0 as issues, OK? |
Testing listFix_2.5.0 I find myself chasing windmills. I am quite uncertain at the moment about the way certain actions, when executed, are expected to behave. The nomenclature is confusing, to say the least. Underneath, there follows is a screenshot of one such example: For instance: Are "Exact Matches Repair" (Ctrl + M) and "Find Exact Matches" one and the same thing — only they are accessible from two different locations? As they stand now, their actions do not match. Observation: I made two different playlists. One for a single disc taken from a multi-disc box set, and one for a number of tracks that I randomly selected. I proceeded to move the playlist out of their respective folders in order to break the list-to-track relationship, and then I copied the two test folders over to the roots of three different hard drives, plus one test-folder copied to a subdirectory on one of the drives. All the test playlists repaired properly. It should be noted that even the "Find Exact Matches" (binocular icon) action turned in fully repaired playlists. However, when the same "Find Exact Matches" (binocular icon) action is executed on previously made, older playlists, it still behaves as reported before — for all the releases tested up to now. This issue appears to be one that needs to be ironed out, and any suggestions on what the cause might be and how to proceed to nail it down, are welcome indeed. • Question: "Exact Matches Repair" (Ctrl + M): Screenshot of action-window which opens. What action is required here, which is not already available elsewhere? Does it only open a playlist to repair in some way other than what is already available? • |
Can you try to isolate the error condition? It is probably either the playlist, or the media-library configuration causing the error. If you try to fix another playlist using the same media-library configuration, does it still fail as well? What type of playlist is it? iTunes is probably broken in the last releases, fixed that in #36 (not in any release yet). |
Thank you for your dedication to this job, @Borewit
I am going to give this a bash tomorrow.
All my playlists are "m3u" — none of iTunes. These are almost exclusively generated by MusicBee, my one-stop music library manager since its inception. It is an extraordinary accomplished application, and I can't truly think of any way its configuration can interfere to cause this issue, although anything is possible. I made the two test playlists with it too, today. |
I have released a version 2.5.1 with logging enabled. Hopefully that provides some more clarity on this issue. For easier monitoring of the log file, you mind want to try Notepad++. |
Testing listFix() v2.5.1 Two procedures were tested:
Test Results: 2. Log files The messages of the two log files are identical(?), and they appear to be incomplete, thus inconsequential for error tracking? 1. "Find Exact Matches" 1.1 The media files and playlists that were used for this particular test, are all stored on the same internal HDD, on which the music library is stored. All programme files, including listFix(), are located on an SSD. 1.2 All the playlists, used in this test, were produced by MusicBee, the Library Manager. 1.3 The first attempt to "Find Exact Matches" failed, as can be seen in the first screen video. It still only flashes a progress window, titled "Repairing", across the screen. However, applying "Fix Everything" (magic wand), opens the "Select Closest Matches" window, which locates and matches the missing tracks. 1.4 The second attempt to "Find Exact Matches" succeeded 100%, as can be seen in the second screen video. What changed? — 1.4.1 The same set of tracks were re-assembled in the MusicBee player. 1.4.2 A copy of this set of tracks was exported to a different folder, located elsewhere, but on the same HDD on which the music library is kept. 1.4.3 The playlist for this set of tracks was then separated and placed just outside the folder keeping the tracks, to break the playlist-file relationship. • |
The log file is working for you, because we see the initial log message on INFO level. So that is something.
Secondly the However, hardly anything else then exceptions are logged, so at this moment there is no difference between the 2 files. But, yes there is no exception in the log (ERROR level), which I hoped for,
What if you just copy the playlist to new location, does it break? I will enable more detailed log messages, hopefully that gives more clarity. |
👍
I copied the playlist over, on its own, from the HDD where the music files are housed to the SSD. Resultsof trying to repair this playlist are shown in the two screen videos below: "Find Exact Matches" Failed 👉 SCREEN VIDEO: listfix 2 5 1 find exact matches _ 20230131 |
Downloaded. Any reason why, in this particular case, I should not install this version over 2.5.1? I do not mind, otherwise. |
listFix_2.5.1-1 Test "Find Exact Matches" |
No Interesting, so the log file basically says everything has been repaired, but you graphical user interface just hangs for some mysterious reason. Hmm, maybe I need to look closer into that progress dialog. The |
The playlist is not getting repaired using "Find Exact Matches": 🤔 After the "Repairing" progress window has run its course, first, there is no graphical indication, i.e. the "OK" icon next to the tracks, to indicate that the repair has been effected. Second, graphics aside, in order to verify whether the playlist was in fact repaired, or not, I saved the playlist after the process "Find Exact Matches" > "Repairing" has completed. The intended "repaired" playlist was finally opened in the music player to play, but it was still completely broken, so it did not play. |
@Borewit : Do you perhaps want me to run additional tests for you, regarding the "Find Exact Matches" issue? I am all out of ideas. 🙃 |
This function no longer exists |
@Borewit: Re listFix() v2.4.2:
I am not at all sure about this, but selecting "Find Exact Matches" to fix a broken list appears to not deliver what resembles a result, or flag a clue of some sort. It does briefly display the progress window, though. Screen video below.
In addition, do I post any questions etc, I may have about the app in general, here under issues, or perhaps elsewhere?
Thank you.
The text was updated successfully, but these errors were encountered: