| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018518 | MMW 5 | Tagging framework / input plugins | public | 2021-11-06 06:27 | 2023-10-25 02:05 |
| Reporter | barrym | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | Windows | OS | - | OS Version | 10 |
| Product Version | 5.0.3 | ||||
| Target Version | 5.2 | ||||
| Summary | 0018518: MM5 behaviour with read-only tracks --> MM5 handles saved network credentials incorrectly | ||||
| Description | My music collection is on a NAS. The credentials to my music hare, that are stored in the Windows Credential Manager, have read rights only to avoid against accidental damage by anyone. Could MM do more where it has read-only access? Its capabilities when it strikes a read-only access situation are underwhelming: * there is no indication in the MM UI if I have viewing tracks from a read-only source. * if I update a group of read-only tracks, there is an error for just one of the tracks ... the MM db is updated for all of them, and the MM db is now out of step with the tracks * the single error message is erroneous ... it says the the tracks are "inaccessible" ... this is misleading, the tracks are accessible, the issue is that they are read-only MM offers no support about how to resolve this situation ... ie. what do I need to do to get MM to discard the profile with read-only access, and ask for credentials for an profile with full privileges? I know that it would be bad idea to interrogate the path to every track that I browse past, to see if MM has sufficient rights to update the track. But maybe when I opened a collection, MM could check the top level shares mentioned in the Collection's Location sub-node. And if the location was read-only, the UI could indicate this ... nothing as radical as you do with Safe Mode, but something obvious. Maybe MM5 could have an option to store credentials to be used instead of those stored in the Credentials Manager? Maybe it is better to issue a warning (which can be turned off) before updating the MM db in a situation where there is no write access to the tracks? There doesn’t seem to be a FilesToEdit node for read-only tracks. I thought the Disconnected may offer this, but no. The “inaccessible” error message should have links to the DeadLinks and the proposed ReadOnly sub-nodes in the Files To Edit sub-node. The message needs to be clearer. There should be a retry option ... see the dBpoweramp message from the same situation. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Hi Barry. I just tested this out and when the user attempts to edit a tracks that is tagged as Read Only, it prompts the user whether to modify the RO status for all tracks in that batch (i.e. [Yes] [Yes to all]), and updates the tracks accordingly. Can you clarify what situation this isn't working? p.s. We could also add a status indicator/files to edit node for this, but that's probably lower priority than making sure that the functionality is working correctly. |
|
|
I see the behaviour that you describe when I try to update a locked file on a local disk. The behaviour when the file is on a NAS is different. The behaviour seems to have changed since I reported this issue 6 months ago. I don't get the exception any more. I don't get the get the prompt to alter the RO status either. What seems to happen is that MM5 automatically resets the RO status without confirmation, and updates the tags in the tracks ... This seems worse that the original problem don't you think? |
|
|
I see an additional problem in the same area. I haven't stored credentials to my NAS in Windows Credentials Manager. Each morning when I start my PC and start MM5, it (MM5) asks for Credentials if I try to change a track. This is what I want to happen. But if I open MM5, and then supply credentials by some other means (ie. also open File Explorer, and provide credentials there), MM5 still thinks that credentials are required. And I have no way to supply them. If I open the MM5 File Properties dbox I get the "is inaccessible" toast message. If I wait for that message to auto-close, I can then alter the track. This action updates the database AND the track. I get the false toast challenge every time I open the File Properties dbox. I can't get MM5 to understand that credentials are now available, and I can't get MM5 to rechallenge me. ... ie. the situation is not fixed by F5 etc ... I need to close and the reopen MM5. Also I don't seem to reassign Mantis tasks to somebody else. ... ie this task was assigned to me a couple of weeks ago. I did what was asked, but I don't think that anybody notices, because the task remains assigned to me. |
|
|
Thanks barry--I overlooked your comment. Will review/triage for 5.0.4. |
|
|
1) Re. MM ignoring read-only attributes for NAS tracks. I was able to replicate a related issue: edits to read-only tracks appear to succeed if the track is playing. See 0019383 . Could that be what you were experiencing? If that's not it, I tested this out as follows (first with an MP3 track and then with a FLAC track): 1 For a track on the NAS in the MM library, opened the folder in Windows File Explorer and set the file's attribute to Read-only. 2 In MP3tag, attempted to edit a tag (and then cancelled the operation) --> Dialog appeared warning of the read-only attribute 3 In MM5, attempted to edit a tag --> Dialog appeared warning of the read-only attribute Can you verify these steps on your NAS? I suspect that the issue you're experiencing will occur with any app. And if you can replicate, please verify that the tag was actually edited (and that it's not just the DB that was updated), and confirm what node you performed the operation in. Thanks! 2) Re. the credentials problem, I'm not seeing any issues but need to look into this further because I'm never prompted to log in (I must have auto-saved the network credentials). btw, what OS are you using? |
|
|
No, the issue I was reporting cannot have had anything to do with the now-playing incident, because I have a house full of Sonos players, and therefore never use MM to play music. I have just retested with MM5 2663. The issue is still there. I am on Windows 10. You won't see it unless your remove credentials to your NAS from the Windows Credential Manager. .. ie. Press the Windows button, and type Credentials ... open the Credentials Manager, --> Windows Credentials, and remove credentials to your NAS. ... then reboot, and test. I don't think the problem exists in other apps ... ie. I reboot, then Open Windows Explorer, and attempt to access my NAS, I get the credentials challenge ... press Cancel, DO NOT supply credentials ... then open MM5, trigger it to also challenge me for NAS credentials, supply credentials to MM5 ... then go back to the Windows Explorer session ==> I am now allowed in, because MM has triggered me to enter credentials into my Windows session, So Explorer is happy now. This does not work the other way around .. ie. reboot, start MM5 ... trigger it to issue the challenge .... press Cancel (maybe I need to go and get the password from somewhere)... start Windows Explorer, get the challenge, supply credentials there ... Go back to MM5 ====> every subsequent attempt to update a track gets the toast message ... the update is silently OK, but the toast messages indicates that the update is not happening. My guess is that the toast message is triggered because MM5 remembers that it issued a challenge which was not satisfied ... but the update is proceeding because the NAS is no longer locked against updates in the current Windows session .... ie. MM5 is not rechecking whether the NAS is still locked against updates. I acknowledge that this is a bit of a corner case ... but it is not working as expected, although the issue goes away by stopping and restarting MM5 |
|
|
Thanks Barry. Can you just quickly confirm whether it occurs with a _3rd party_ app rather than explorer (I just want to make certain that the issue isn't a Windows/NAS issue that occurs with any 3rd party app). e.g. MP3tag. If you don't have time, that's fine--I'll ask Peke to test with MM and a 3rd party app based on the instructions you gave. |
|
|
Barry, can you please try to access Shared paths using this approach from CMD started normally and as administrator. Example changing access --------- net use \\server\share /user:test testpassword start \\server\share --------- |
|
|
<<<Rusty: Thanks Barry. Can you just quickly confirm whether it occurs with a _3rd party_ app rather than explorer (I just want to make certain that the issue isn't a Windows/NAS issue that occurs with any 3rd party app). e.g. MP3tag.>>> I only have one other one 3rd party app (that isn't an Explorer plugin) that can tag tracks ... that is MM4. I tested with MM4 ... if I try tagging with MM4, before supplying credentials for my NAS it updates the db, but gives no warning that it is unable to update the tracks. If I leave MM4 running, and use Explorer to re-issue the credential challenge, and then go back to the MM4 session, the UI is exactly the same, ie. MM4 makes no complaint ... BUT the tracks are now being updated. In MM5 this is different. It shows the toast error message ... and then when the credentials problem is resolved externally, it continues to overlay the display for every subsequent track update, even though the track updates are now happening OK. I don't understand your questions. I acknowledge that it is not a major problem. I don't feel that it is acceptable for MM5 to be issuing false, disruptive error messages after the problem has been resolved, but that is just my opinion. I am guessing that MM5 knows that the problem has been resolved ... ie. the write to track is no longer receiving an error return .. so it should not be a big leap to turn off the toast messages until writes start failing again. I can't see that it helps much to see if I can find a 3rd party app that has a similar problem. ... It is either worth fixing, or it is not. Peke. I don't understand what you are saying. My NAS is a Linux box. I have some familiarity with Linux permissions, but I don't want to interfere with the what is happening under the covers in my NAS. It has a UI which allows creation of User Profiles that do, or don't, allow read or write rights for the profile. I don't want to mess with any of that. I am not sure what you are saying. I don't have an access problem. It works once credentials have been supplied. It just issues an erroneous error message that overlays the UI, and it does this for every track update until MM5 is restarted. |
|
|
I was originally thinking that the problem you experienced could be related to different network paths for MM vs File Explorer on your system (e.g. //192.168.1.25/... vs //NAS/...--even though both access the same destination, saved credentials will apply only to one or the other). But when I tried to replicate the problem with the steps that you indicated, I found that MM did behave strangely, though not any more so than MP3Tag which makes me think that it might be a windows problem: 1 Remove credentials for the network stored in credentials manager 2 Reboot PC 3 Run MP3Tag and MM5 & Cancel the credentials prompt 4 Run File Explorer and enter the credentials to the network path when prompted 5 In MP3Tag, navigate to the network path and edit a Title --> Sometimes success and sometimes failure due to inability to navigate to the network path and the following error: 'Network discovery is turned off. Network computers and devices are not visible. Please turn on network discovery in Network and Sharing Center.' (note: this error never occurs when MP3Tag is run _after_ File Explorer is run / credentials are entered). 6 In MMW5, navigate to the Location node and edit a networked file --> Success 7 Right-click on the file in MM > Properties --> Toast message appears indicating that the file is inaccessible! 8 Double-click the file --> The file plays (despite it supposedly being inaccessible)! 9 Delete the networked file from the Music > Location .... node (from the DB only) and then rescan it --> The track fails to scan, yielding an 'error while reading file info'! 10 Restart MM, and then scan the same location --> The file(s) scan successfully with artwork --> Network discovery issues are gone Summary: If network credentials aren't saved, and are first entered via another application after MediaMonkey is already running, MediaMonkey seems to both have access (ability to edit, play) and not have access (properties error, failed scans/tag reading) to files with read/write access. On the other hand, MP3Tag also exhibits strange behavior (network discovery error) in this case, so I wonder whether the 'network discovery' issue may be the cause/related to the anomalies in MediaMonkey. Assigning to Peke to investigate whether this is a Windows issue or an MM issue. |
|
|
Sorry Barry for short reply, it posted short without my explanation. Here is what I tested. Settings are that Guests can't access Network Share, Peke have read only access, Admin have Read/Write Access. 1 Remove credentials for the network stored in credentials manager 2 Reboot PC 3 Run File Explorer, Paste "\\192.168.0.250\TestShare" Cancel credential (eg. Windows only uses Guest which is blocked) 4 RUN CMD in Windows and executed "net use \\192.168.0.250\TestShare /user:peke pekepassword" 5 Run File Explorer, Paste "\\192.168.0.250\TestShare" and path it opened 6 Run MP3Tag and MM5 7 Opened "\\192.168.0.250\TestShare\Sound 3.wav" in MM5 (Properties) and MP3Tag no issues 8 Tried to save Tags in MP3Tag and MM5 -> MP3TAG faild with prompt MM5 Updated Library, but showed toast msg of TAG UPDATE FAIL and continue not needed user interactions. 9 RUN CMD in Windows and executed "net use \\192.168.0.250\TestShare /user:admin adminpassword" 10 Opened "\\192.168.0.250\TestShare\Sound 3.wav" in MM5 (Properties) and MP3Tag no issues 11 Tried to save Tags in MP3Tag and MM5 -> No issues tags saved, no credentials prompts and no windows saved credentials. If file is set as Read only in MM5 i get normal read only prompt. As I see problem is like you pointed PERMISSIONS issue, not read only. Like you pointed checking each file security permissions will influence MM5 Performance especially on batch edits. It is easy to do that in all apps that handle single file. Sorry again for my last short msg, leading to misunderstanding of what I asked you to test. I asked you to do a simple test so that we can add credentials managed directly in MM in order to allow you to controll MM access credentials without any changes on NAS. Let me know if this makes things bit clear. EDIT: You can do same on local files. If you edit track properties and in Security tabs temper with permissions (eg. allow users only read+Read and execute access) to remove and add user Read/write access or use other app (Like HEX editor) to LOCK write access to other apps while it is opened for write. Also File that is still downloading will be write access lockable till download is finished. I think it is normal behavior only thing that maybe can make things clear "Tag update failed: \\192.168.0.250\TestShare\Sound 3.wav is WRITE inaccessible", but "Tag update failed: \\192.168.0.250\TestShare\Sound 3.wav is inaccessible" also point to same thing. EDIT 2: I see that you like any responsible user that care for his files want to have full controll over them. It really depends on your Linux box and how user setup permissions for me as I use QNAP and if I want to use Windows to controll access I have complete tutorial here http://qnapsupport.net/qnap-uygulamalari/kullanici-ve-klasor-olusturma/klasor-olusturma-ve-yetkilendirme/how-to-use-windows-acl-to-manage-user-permissions-on-the-qnap-nas/ and for others you can use https://learn.microsoft.com/en-us/archive/msdn-magazine/2008/november/access-control-understanding-windows-file-and-registry-permissions and https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/access-control image.png (79,695 bytes) image-2.png (26,772 bytes) image-3.png (35,076 bytes) image-4.png (14,022 bytes) |
|
|
Rusty: if you are able to play the track without supplying credentials, maybe you have a Guest account (ie. access without password) that has read access to your music share. This thread is getting complex. I think that MM5 is working AOK here, except for one issue. ie. I have no Guest Account, and no Credentials stored in my Windows PC 1) Start PC ... Windows Explorer cannot open my NAS (no credentials) ... good. 2) start MM5 ... do not supply credentials 3) Folders node cannot open my NAS (understandable) 4) I can open the MM db, and browse my collection ... But I cannot play tracks (understandable) 5) Track properties shows toast message warning that the track is "inaccessible" .. (understandable) 6) Attempt to retag a track ... the db update occurs, and there is a toast message says "Tag Update Failed" ... (understandable, and notably better than MM4 btw) 7) Open Windows Explorer . and supply Credentials 8) Go back to MM5, and open Track Properties again ... same "Inaccessible" toast message <===== This is the problem. The file is no longer inaccessible 9) Attempt to retag the track .. the TRACK IS UPDATED ... and there is now no toast message saying the update failed ... (GOOD) ... btw I hadn't tested this before Everything seems AOK to me except that MM5 has a single attempt to gain credentials, and then keeps issuing the "inaccessible" toast message over and over again erroneously for every use of Track Properties, , until MM5 is closed down. The erroneous toast message is especially annoying because it is on something like a 10 second timer, and it obscures the Cancel|Next|Previous|Ok buttons. Peke: thanks for the additional info. We seem to be on a different track. I don't have any interest in MM storing or obtaining my credentials. Everything seems to be working just how I would want it to. I would just want them to turn the toast message off once they had made their first successful access to the resource which was previously inaccessible. ... Surely this is possible? I see you point about batch operations ... but this isn't a batch operation. It is a single Track Properties transaction. And apologies if I sent you down the wrong track by using the the term "read-only tracks" in the title of this report. This has always been just a report re User Profile File Permissions .... networking is not my "thing", as I am sure that you have noticed :) |
|
|
Barry, the issue that you and I are describing seem to be identical (there are no guest accounts on my NAS--I can only play/edit networked tracks after I've supplied network credentials via Windows File Explorer). I'm just adding to the issue that you've described. i.e. once credentials have been supplied in Windows File Explorer, MediaMonkey appears to have incomplete access: a) the properties dialog generates the 'inaccessible...' error message that you've described b) for networked tracks that aren't in the library, properties aren't viewable in Folders [List] views & scanning the folders generates an error "error while reading file info" To re-iterate: the above issues _don't_ occur if the credentials are entered in Windows File Explorer _before_ running MediaMonkey. The issue is that MediaMonkey, if already running, only 'inherits' partial permissions when the credentials are entered in Windows File Explorer _after_ MediaMonkey is already running. Peke, as both Barry and I noted, the files in question aren't 'read only' (nor 'hidden'). Here are more details re. security properties of the networked file that might help: Security > Advanced > Permissions for [Linux User:NAS\rusty, Administrator, powerusers] are: Read & execute, Read, Write Security > Advanced > Permissions for [NAS\family] is: Read & execute, Read (and 'None' for guests / everyone) Security > Advanced > Share shows: Allow | Everyone | Full Control MOST IMPORTANTLY: in your attempts to replicate the bug, it appears that you _didn't_ run MP3Tag and MM5 and cancel the associated credentials prompt _before_ running Windows File Explorer. That is one of the key steps to replicating the issue as described in the steps at 0018518:0069428 and the associated summary: "If network credentials aren't saved, and are first entered via another application _after_ MediaMonkey is already running, MediaMonkey seems to both have access (ability to edit, play) and not have access (properties error, failed scans/tag reading) to files with read/write access. " |
|
|
I was finally able to replicate using these settings. @Rusty Difference is I guess that Advanced > Share shows "Allow | Everyone | Full Control" and for me it is None which means you can't even list files in folder unless you have credentials. So I can't get to state browser list lengths unknown like in your case. Reason for that is that inline edit, which you found works after enabling credentials in File explorer is due the fact that inline edit access file directly (thru new request) without checking previous results (reason why other parts did not work). If you pressed F5 after Windows explorer allowed connection with correct credentials then all parts of MM would work also. I have also found another case where MM never even report file is not accessible: 1. Select tree to playing (set to list) 2. use File -> Open URL/File -> Paste "\\192.168.0.250\TestShare\Sound 5.wav" which do not exist at all in the folder -> No toast but like in your video length is Unknown. 3. Edit inline -> MM throw toast MSG -> Edit in properties no toast. Looks like MM cashes last access result and in case of inline MM do re query instead of using cache, while some other parts do not do that. Also @BarryM is right Toast is shown even in non existing file and state inaccessible instead file do not existing. EDIT: NOTE that is you try above steps for local files toast is thrown that file is not accessible. eg. instead of "\\192.168.0.250\TestShare\Sound 5.wav" use "T:\TestShare\Sound 5.wav" image-5.png (16,217 bytes) image-6.png (9,528 bytes) |
|
|
bug18518.mp4 (573,307 bytes) |
|
|
--- Peke: "If you pressed F5 after Windows explorer allowed connection with correct credentials then all parts of MM would work also." That is not what I see. Refresh via F5 does not fix the issue where MM5 issues the "Inaccessible: toast error message after the Credentials issue has been fixed externally to MM5. --- Rusty: "To re-iterate: the above issues _don't_ occur if the credentials are entered in Windows File Explorer _before_ running MediaMonkey. The issue is that MediaMonkey, if already running, only 'inherits' partial permissions when the credentials are entered in Windows File Explorer _after_ MediaMonkey is already running." Good we are agreed, but I would describe it differently. .. Just guessing, but I wouldn't say that it is an "inheritance" issue .. I would describe it as MM5 checks accessibility just once, and sets a switch to trigger the "inaccessible" toast message for the remainder of the current invocation .. It is lacking logic to set off the switch following 1st successful write to the drive. And this is an avoidable weakness. We are going around in circles, trying to deduce what is happening inside the MM black box. It would help if someone, who can read the code, provides input here. I feel that everything is working as you would want it, apart from the toast message that gets stuck on. People with a NAS, can either provide a Guest account with read|write access to their media files. Or allow Windows Credentials Manager to capture and store their Credentials inside their PC. Or provide the credentials manually when wanting to use MM5 against the NAS ... I have chosen this approach. MM5 **could** store credentials, like Peke mentioned earlier. Sonos works this way. But unlike MM, it only needs read access. So I have a MusicListener account on the NAS, with read-only access to my Music share, and Sonos has stored these credentials. Maybe some people would want MM to do this ... I would not ... And I don't think that it is Ventis's interests to have their product responsible for storing and protecting user credentials with Write access rights. |
|
|
https://www.mediamonkey.com/forum/viewtopic.php?t=105153 |
