MediaMonkey forum

If MM5 detects that a file or folder is inaccessible, it caches this info and does not retry for the duration of current MM5 invocation.

Example:

• the resource is on a NAS which requires a ID and password to open

• MM5 raises the credential challenge, but gets no valid response; eg. maybe the main screen, or some other application sits on top of the dbox, or the dbox is accidently closed

• I then open the resource elsewhere (eg in Windows File Explorer) and supply the credentials to Windows

• MM5 can play the tracks, it can display the folder and tracks with in the Location tab, it can display the tracks and tags in the MM5 main panel ... all looks OK, there is no visible indication that the situation had occurred ... the UI has no retry or refresh option anyway

• ==> if I try to update the album's art via File Properties it complains that one of the tracks is inaccessible

• but if I select the album and take option "Lookup Image ... I am able to update the album art ===> this makes MM5 look faulty IMO

• ==> if I search for dead Links all tracks are listed as inaccessible

This is a confusing situation.
MM5 should retry access in these kind of situations, and not rely on a stale cache for accessibility status

Hi,
Network access connections are dependent on Windows file explorer Access. For me each time MM access NAS Shared folder it asks fro credentials and once I accept it is saved for that session.

There is already added bug at https://www.ventismedia.com/mantis/view.php?id=13971

EDIT: You can try my app at https://www.ventismedia.com/mantis/view ... 971#c55685 to init UNC Path Login creation (App is safe, but as it does not contain digital signature it throws UAC dialog and you need to start it thru MORE INFO)

Hi Peke,

I can't see how the issue that you linked to relates to the issue that i am reporting.
I am reporting that MM5 flags a resource as being inaccessible, and that it persists with that view even when the resource becomes accessible.
This leads to a confusing situation:

• eg. I cannot update an album's art via one MM5 route (edit Properties) due to "inaccessibility" , but I can successfully update the album art via MM5 Lookup Image

• eg. MM5 reports that the track is a Dead Link, even though I can play that track using MM5 via it's Path tag

• eg. MM5 can see the file and display and its tags in the Folder view, but it is "inaccessible" via the Edit Properties facility

I don't see how any of this is applicable to the seven year old issue that you are trying to bump.

I see the issue as being:

1. MM5 can get itself into an illogical and erroneous state because it relies upon potentially stale cached resource state
2. and MM has no UI control to fresh the resource availability status, for use when the inaccessible issue is resolved externally

Barry4679 wrote: ↑Sat Dec 09, 2023 4:00 am I can't see how the issue that you linked to relates to the issue that i am reporting.
I am reporting that MM5 flags a resource as being inaccessible, and that it persists with that view even when the resource becomes accessible.

I could not replicate your behavior. Even I have incorrect credentials and use my app to change them I can play the tracks normally afterwards.

Barry4679 wrote: ↑Sat Dec 09, 2023 4:00 am This leads to a confusing situation:
eg. I cannot update an album's art via one MM5 route (edit Properties) due to "inaccessibility" , but I can successfully update the album art via MM5 Lookup Image
eg. MM5 reports that the track is a Dead Link, even though I can play that track using MM5 via it's Path tag
eg. MM5 can see the file and display and its tags in the Folder view, but it is "inaccessible" via the Edit Properties facility

Aren't 1 and 3 same thing? 1,2,3. You play track and it gets un dead link then you can edit properties. But yes this is a BUG opening properties should check accessibility.

Barry4679 wrote: ↑Sat Dec 09, 2023 4:00 am I don't see how any of this is applicable to the seven year old issue that you are trying to bump.

If problem is credentials issue then my solution should work.

Hi Peke,

Peke wrote: ↑Sun Dec 10, 2023 7:13 pmI could not replicate your behavior. Even I have incorrect credentials and use my app to change them I can play the tracks normally afterwards.

You are probably not testing what I am trying to report.
I am talking about a situation where credentials are not supplied:

• either the User got challenged, and then pressed Cancel, intending find and supply the credentials later, either via MM or some other way

• or the User didn't see the challenge ... easily done because MM5 does not do a good job of keeping these dboxes on top of itself... MM5 doesn't present these as a modal dbox, so if the user never responds MM5 keeps ob chugging along, giving no indication that it is waiting for something

• or the User accidently closes the challenge dbox

From this point MM5 never checks again. It relies on a stale cached status setting for the device.

Peke wrote: ↑Sun Dec 10, 2023 7:13 pm Aren't 1 and 3 same thing? 1,2,3. You play track and it gets un dead link then you can edit properties. But yes this is a BUG opening properties should check accessibility.

1 and 3 are alike from the POV that they both make MM5 look buggy, but I think that they are different as they present differently to the User.

In #1 MM5 won't let me edit album art because it is inaccessible, whereas it it is editable using a different route through the UI.
In point #3 the tracks is reported as being inaccessible, when it obviously not because I can see it via the Folders view which looks directly at the file, ie. doesn't use the the file tags stored in the MM5 db.

If you are reporting that the only problem is with the File Properties facility, you are missing part of what I am trying to report.

There is at least one other situation where MM5 is use the stale cache of resource availability, ie. the FilesToEdit>DeadLinks report.

There are likely to be multiple other situations also.
The main point is that MM5 is using a stale cached value for resource availability status
It takes no account of a situation where the user has been challenged, failed to provide the credentials, and the User then provides the Credentials to Windows outside of MM5.
MM5 persists with the view that the resource is unavailable. And there is no indication as to the cause of the erroneous errors. And there is no way to get MM5 to recheck availability, without closing and restarting MM5.