2286 - MM5 just ate 192 of my tracks.

by **Ludek** » Wed Dec 23, 2020 11:12 am

1. OK, sounds probable, I see that LowLander & Drakinite are able to replicate something similar this way: https://www.ventismedia.com/mantis/view ... 991#c60282 , it's being looked into.

2. OK, I'll take a look at the log.

EDIT: Wathcing the log it seems that rather folder updates are taking the time (rather than file moving), but I cannot replicate and your log isn't complete, it is missing many debug messages. This mosty happens when DbgView is started after MM5 start. Could you please generate another log for me, but with DbgView started prior to MM5 ?

3. Agreed, full path would be better here, I'll update this (tracked as https://www.ventismedia.com/mantis/view.php?id=17284 )

4. I think that the white screen was most probably related to the "out of memory issue" https://www.ventismedia.com/mantis/view.php?id=17273 fixed in 2289
Are you able to re-trigger this with build 2291 ? i.e. if you cancel the task in 2291 are the tracks still inaccessible under Entire Library > Location ? Otherwise yes, I suppose that 'Rebuild database' would fix that.

by **Barry4679** » Tue Dec 22, 2020 8:26 pm

I don't think that I will be able to re-trigger the phantom move again, but I have some thoughts & observations:

You thought that MM5 may have captured Ctrl+A and Ctrl+R keystrokes
- I don't think that it would have been Ctrl+R .... but it could have been Ctrl+X Ctrl+V
- I had Chrome Browser open, and was writing an incident report open .. I also had Microsoft Edge open because the Support person that was trying to fix my Internet connection was communicating to me periodically in a chat tool, and its popup would not open in Chrome ... I had some trouble getting notifications sound from from the chat panel, so I pressed some buttons which may have issued commands .... but I think that it was probably triggered by Ctrl+X amd Ctrl+V because I would have used those commands for sure
I ran some tests today with Ctrl+X and Ctrl+V ... there seems to be some (unrelated) problem
- I selected an album on my NAS, and tried to cut and paste it back into the same share on my NAS ... ie. try to retrigger how //flac/AlbumArtist?Album got somehow got moved to //flac/flac/AlbumArtist/Album
- MM5 is moving tracks ... but soooo slowly ... seems to be taking more than a minute per track
- I will send you a debug log
When tracks are being moved, the MM5 Status Bar doesn't display the target location ... it just shows the file name
- can this be improved? ... it is hard to see what is happening, and where it is up to
I see some minor database corruption following cancel of the move using status bar context menu
- when the phantom move incident occurred, I cancelled the move operation using the Cancel option that is on the context menu for the Status Bar
- this seems to have resulted in some minor db corruption
  - the moved tracks are missing from the Location node in EntireLibrary
  - they are in the other EntireLibrary subnodes, but missing from the Location subnode ... missing from both the original and moved-to location
  - I will send you images
  - remember that MM5 white screened after after I cancelled ... but it is strange that all moved tracks are missing from the Location node
- I am guessing that this would be corrected if I rebuilt the database?

by **Barry4679** » Tue Dec 22, 2020 6:55 pm

Ludek wrote: ↑Tue Dec 22, 2020 10:58 am Hmm, that's unexpected, I thoguht that MM5 moved the files -- so it should have update also the paths in the database. This is not in a batch, but for every file.
And yes, the Deadlinks node should list them.

Apologies. The "deadlink" part of this report is Tester Error.

Since the phantom track moving happened from the Folder node, it attacked folders starting at the beginning of the alphabet ... I checked the tracks from EntireLibrary sorted by AlBumArtist ... so I checked 13th Floor Elevators ... but MM strips off "The" prefix .. ie they are really The 13th Floor Elevators ... so they had not been moved.

When I check Folders which had been moved, the Location has been updated to the move-to location ... so that is why there is nothing in DeadLinks.

by **Ludek** » Tue Dec 22, 2020 10:58 am

No you misunderstand ... The Location, as displayed in the File Properties dbox, is pointing to the old location.
And Edit>DeadLinks does not report the tracks as dead links.

When do update Location? After completion of the whole batch ... or as you move each individual track?
Remember I looked at the Status Bar, and saw MM5 was moving tracks ... panicked ... right clicked the Status Bar, and took the Cancel option.

So you sure that this is expected?

Hmm, that's unexpected, I thoguht that MM5 moved the files -- so it should have update also the paths in the database. This is not in a batch, but for every file.
And yes, the Deadlinks node should list them.

True. ... I have not given up.

Nice!

Trying to figure out what could happen there and the idea is that these tracks might not have been in your MM5 library at all? Then they wouldn't be updated in your library at all after moving (and thus not listed under the Deadlinks node) ??
If you search for the tracks in your library, do you see them?
If you try to play them, are they inaccessible ?
Do you access the "Deadlinks" node under "Entire Library" or a specific collection that could filter them out ?

by **Barry4679** » Tue Dec 22, 2020 8:37 am

Ludek wrote: ↑Tue Dec 22, 2020 7:00 am #2: Files to Edit>DeadLinks is still not detecting the tracks which have disappeared from their expected location.
Yes, this is expecte, because by evidence MM5 moved the files intentionally and thus does not consider them as deadlinks, because also the paths in your database have been updated to the new paths after moving.

No you misunderstand ... The Location, as displayed in the File Properties dbox, is pointing to the old location.
And Edit>DeadLinks does not report the tracks as dead links.

When do update Location? After completion of the whole batch ... or as you move each individual track?
Remember I looked at the Status Bar, and saw MM5 was moving tracks ... panicked ... right clicked the Status Bar, and took the Cancel option.

So you sure that this is expected?

Ludek wrote: ↑Tue Dec 22, 2020 7:00 am The question still is which action triggered moving of the files (which you indicated that cannot rpelicite / figure out ATM)

True. ... I have not given up.

by **Ludek** » Tue Dec 22, 2020 7:00 am

#1: Re the white screen issue: It is the same issue reported here: viewtopic.php?p=475902#p475902
and already fixed as : https://www.ventismedia.com/mantis/view.php?id=17273 in 2289
In your log I saw "Covers: Memory occupied by picture data: 2.8 GB" so yes, that was the "out of memory" case

#2: Files to Edit>DeadLinks is still not detecting the tracks which have disappeared from their expected location.
Yes, this is expecte, because by evidence MM5 moved the files intentionally and thus does not consider them as deadlinks, because also the paths in your database have been updated to the new paths after moving.
The question still is which action triggered moving of the files (which you indicated that cannot rpelicite / figure out ATM)

#3: a small problem resetting a contextual filter in Folders node
Thx, I've got the gif via PM

by **Barry4679** » Tue Dec 22, 2020 3:12 am

#1: a white screen crash while MM5 sitting idle ... debug log was running

Code: Select all

01378497	4498.15966797	[23840] f_flac: FORMAT_OpenFile	
01378498	4498.15966797	[23840] MM5 [1088](R) Locking file: \\NAS-XXXX\flac\Agnes Obel\Aventine\11.flac	
01378499	4498.17187500	[23840] MM5 [22008](R) FH.ReadFileInfo openned	
01378500	4498.17187500	[23840] f_flac: FORMAT_GetExtendedTag	
01378501	4498.17187500	[23840] f_flac: FORMAT_GetExtendedTag	
01378502	4498.17187500	[23840] f_flac: FORMAT_GetExtendedTag	
01378503	4498.17187500	[23840] f_flac: FORMAT_GetExtendedTag	
01378504	4498.17236328	[23840] f_flac: FORMAT_GetExtendedTag	
01378505	4498.17236328	[23840] f_flac: FORMAT_GetExtendedTag	
01378506	4498.17285156	[23840] Dump(String): "PanicModeOn: FATAL PROBLEM"	
01378507	4716.14404297	[2372] CMcMetroFolderWatcher::Change FileAction = 3, szFileName = Microsoft.MicrosoftOfficeHub_8wekyb3d8bbwe	
01378508	4819.36962891	[16812] MM5 [25408](B) TBrowserWindow.prepareResizedShape: width/height: 160/28	
01378509	4819.38085938	[16812] MM5 [1236](B) TBrowserWindow.prepareResizedShape: width/height: 160/28	
01378510	4821.73242188	[16812] MM5 [25408](B) TBrowserWindow.prepareResizedShape: width/height: 1176/755	
01378511	4821.74560547	[16812] MM5 [1236](B) TBrowserWindow.prepareResizedShape: width/height: 1176/755	
01378512	4993.79101563	[24796] Error moving 'C:\ProgramData\McAfee\WebAdvisor\UIManager.dll\log_0003005E003D0007001B.txt' -> 'C:\ProgramData\McAfee\WebAdvisor\UIManager.dll\log_0003005E003D0007001B.txt.0'. Error: 5	
01378513	4993.79345703	[24796] Error moving 'C:\ProgramData\McAfee\WebAdvisor\UIManager.dll\log_0003005E003D0007001B.txt' -> 'C:\ProgramData\McAfee\WebAdvisor\UIManager.dll\log_0003005E003D0007001B.txt.0'. Error: 5

That track is one of the tracks which MM5 moved in the problem mentioned at the top of this thread. ... I have not fixed up the tracks yet ... they are still not where MM5 expects them to be

I sent a dl link to Ludek.

#2: Files to Edit>DeadLinks is still not detecting the tracks which have disappeared from their expected location.

#3: a small problem resetting a contextual filter in Folders node

Location node

open NAS share .... big Folder 40k+ tracks

set on Recursive control

type a contextual filter string

do not wait for completion ... turn off Recursive

cancel the contextual filter

==> screen remains filtered ... stays filtered if you navigate to another Folders node ... fixed by open|close the original node

Sent gif file to Ludek which demonstrates problem

by **Barry4679** » Mon Dec 21, 2020 9:07 pm

Ludek wrote: ↑Mon Dec 21, 2020 9:31 am I guess that Drag and drop could cause it as it seems that MM5 somehow moved the tracks intentionally (from your description), but I guess you haven't performed any drag&drop operation this time?

But also be sure that you have disabled auto-organizing (Options > Auto-organize)
Mainly the checkbox '[x] Automatically organize files (during scans or edits)'

I did no drag and drop.
The auto-organise options were disabled.

I don't think I was pressing any Ctrl keys.
MM5 may have been doing the 23 minute scan that I mentioned here ... maybe it completed that, and woke up, and captured some key strokes.

I was under some stress at the time ... I was typing the report, while also interacting with a technician using a chat thing, trying to get my Internet connection fixed .. so maybe it did not notice

I installed 2288.
I have been unable to replicate the issue ... will keep trying

by **Barry4679** » Mon Dec 21, 2020 10:45 am

yes, sounds serious, but hopefully it is not. Is late here, will try and get you info tomorrow.

by **Ludek** » Mon Dec 21, 2020 9:31 am

That's curious and sounds quite a severe issue.

I guess that Drag and drop could cause it as it seems that MM5 somehow moved the tracks intentionally (from your description), but I guess you haven't performed any drag&drop operation this time?

MM5 was underneath my browser while I typed the report ... maybe it captured some key presses

This sounds more probable, maybe the MM window somehow got to a state that it didn't know that it is no longer the active window.
Then performing a hotkey action could cause the moving somehow.
I guess that the moost probable set of hotkeys would be Ctrl+A, Ctrl+R, Enter which manually triggers auto-organize.

But also be sure that you have disabled auto-organizing (Options > Auto-organize)
Mainly the checkbox '[x] Automatically organize files (during scans or edits)'

Also, if you will be able to figure out how to replicate this issue then also debug log would be probably helpful, but I guess that the main key is to find the action that triggerred the file moving in your case.

Thanks!

by **Barry4679** » Mon Dec 21, 2020 5:36 am

I found the tracks ... they are on my NAS
moved from /flac/albumartist/album ==> /flac/flac/albumartist/album

I don't know if I reported it but once before I found that tracks had been moved while using MM5 Folders node
They ended up in something like \\NAS-xxxxx\flac\Abba\Abba\Abba\Abba\Abba\Abba\Abba\Abba\Abba\Abba\Abba\The Visitors ... I think that I was testing drag and drop that time ... I don't think that I was able to replicate it, so maybe I did not report it

I will try some more testing this area tomorrow, and see I can get more useful info.

by **Barry4679** » Mon Dec 21, 2020 5:16 am

I was testing the Folders node

as described here ... MM5 was "reading files..."

I opened another window (Chrome browser) to make the above report

when I returned to MM5 I noticed that the status bar had to changed to say it was "moving" files

I panicked, and cancelled the task using the context menu on the status bar, without taking note of where the files were being moved to

MM5 immediately white screened

I checked via Windows Explorer --- the files are gone

I check via MM4 --- there are deadlinks for 192 files ... 4.0gb

restarted MM5 --- the MM5 db says that the files are in their original location ... untrue

MM5: the deadlinks option run over EntireLibrary finds no errors ??! ... which is obviously a bug, also indicated here

I have no idea where MM5 has moved my tracks ... I have looked, but cannot find.
I have no idea why MM5 moved any files?
MM5 was underneath my browser while I typed the report ... maybe it captured some key presses

I have no idea why it white screened.

Is there any way that I can find where my tracks are?

2286 - MM5 just ate 192 of my tracks.

Post a reply

Expand view Topic review: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

Re: 2286 - MM5 just ate 192 of my tracks.

2286 - MM5 just ate 192 of my tracks.