|
|
I can't replicate and from the screenshot I don't see anything bad.. Please share the sample file and debug log.. |
|
|
From the log I see that the file has been organized at the same second with tagging, and during tagging the FileExists function returned false, so I wonder: Was the file only temporarily inaccassible? |
|
|
Supposing that the file was inaccessible only temporarily (tagging called at the same time with organizing) I tweaked the code to prevent from this situation.. So please re-test in 3105 |
|
|
Re-openeing: LowLander is saying that just adding the accent letter (in Properties > File Path) causes the file to be inaccessible permanently, added some new logs to analyze.. |
|
|
Test note: The key to repliciate is scan the original file with 2-chars version of é (65CC81) and then open Properties and replace the 2-chars version of é (65CC81) by one char version (C3A9) .. and actually such a file is removed from library due to this SQL: [13868] MM5 [19628](R) DB exec SQL: DELETE FROM Songs WHERE SongPath=':\Temp\logs\Quando - Michael Bubleé & Nelly Furtado | Karaoke Version | KaraFun.mp4' and IdMedia=5 .... [13868] MM5 [19628](R) DB lock took 0 ms : UPDATE Songs Set SongPath=':\Temp\logs\Quando - Michael Bubleé & Nelly Furtado | Karaoke Version | KaraFun.mp4', IdMedia=5 WHERE SongPath=':\Temp\logs\Quando - Michael Bublee´ & Nelly Furtado | Karaoke Version | KaraFun.mp4' and IdMedia=5 .. must be really long standing issue, good catch! Happens in 5.0.4 too |
|
|
Fixed in 3105 |
|
|
No toast was shown on Organize Files, but in-line editing and opening Properties both showed toast that file was inaccessible after Organize Files. Playback also failed. File remained inaccessible after MM restart. |
|
|
It seems the key is that the files are being organize to an existing folder with a variation of the accent. Perhaps File Explorer doesn't see the difference, thus adds it in the existing folder, but MediaMonkey does see a difference, thus can't find the file? |
|
|
I am unable to replicate after the fix in 3105... accents are stored correctly also in DB... In your log I see that you are using auto-scanner, so maybe that's the key.. Could you please isolate some exact and consistent steps with screencast video and share the files? The log is useless in this case as I can't see the character variants :-/ And could you please test whether auto-scanner plays a role and if not then disable it to rule it out? Tested also with my NAS (Synology) and I am unable to replicate after the fix in 3105.. But in your debug log I see 'Michael Bubl ' while in my it is either 'Michael Bublé' or 'Michael Buble´' Isolating some consistent steps to reproduce (with empty DB) and attaching the music file , MM5.DB, screenscast and text file with the accents would be really useful here.. |
|
|
It seems to require to use a NAS to reproduce. So far I've not been able to reproduce with files on internal drive. It seems Windows handles this weird é differently. The test folder/file copied from internal to NAS also showed no problem, but copying the folder name from the original NAS did reproduce the issue on the new NAS. |
|
|
Another screencast/log added. txt was already provided. DB from after this screencast added. All Auto-Scanning was disabled for this test (it's not a factor). |
|
|
OK, I tried the exactly same steps as on your last screencast video, created the folder and then auto-organized to that folder, but it created duplicate folder (with different accent) on my Synology NAS and the file was playable without issue, so I would probably need to use your kind of NAS to replicate.. BTW: If you create the folder with different accent manually (as in step 1), it does not create duplicate folder for you ? image-6.png (19,593 bytes) |
|
|
Based on conversation with LL: - The issue occurs only with tracks stored to a NAS (i.e. it's related to differences in file storage on Linux vs Windows) - The issue likely isn't a regression - There's a known workaround of manually editing the folder name to the correct character Considering the above, we may want to consider pushing if we're unable to determine a simple/consistent set of repro steps. LL's hypothesis of when this occurs is that: " somewhere I had some files Organized by MM with a variant of the é character (Ludek already indicated we're dealing with 2 variants). This created a Michael Bublé folder with an alternative é character. So now when I Organize files with the normal é version they end up in that alternative version of Michael Bublé. MM thus can't find the file as it's looking for the specific é variant. So the 'bug' is either: MM doesn't organize to the correct variant of é (however Windows and/or Linux may be the cause of this). MM reads specific variant when it shouldn't (as OS doesn't see diference (like capitalization in Windows)." |
- Anonymous
