[3.5.8334] Moved / temp inbox files still show up as missing

[theta_wave]

In the recent 3.5.x builds, I noticed something happening files in my inbox when moving/verifying music files outside of Musicbee.

Example 1: For downloaded purchases (bandcamp/qobuz/beatport/etc.), inbox files that have been moved by myself from a first monitored folder (downloads) to another second monitor folder (staging) via file explorer leave behind a missing file indicator for the first audio track despite rescanning the folders and acknowledging that files are indeed no longer in the first folder and are to be removed from the library.

Example 2: In other times, when verifying my ripped CD with cuetools, temp wav files created for verification against cddb and accuraterip databases (and deleted after verification) end up as being displayed as missing files as shown in the screenshot below. Again, these files still remain after rescanning the directory and acknowledging that the files are no longer there and are to be removed from the library. This has been my workflow for the past several years using Musicbee and do not recall seeing this issue as shown in the screenshot. Only after updating Musicbee 3.4.x to 3.5.x did I notice this issue. When moving these inbox FLACs from the first monitored folder to the second monitored folder, at least one stray flac entry remains in the inbox. Like in example 1, it requires manual removal from the inbox tab.

In both examples, this issue is not resolved after rescanning the monitored folders and acknowledging removal of these missing files from the inbox.

Expected behavior: Inbox files that are no longer present in monitored folders are removed either automatically (as they were prior to my 3.4.x -> 3.5.x update) and/or removed after the user acknowledges that the files are no longer present and desires to remove them.

Additional comment: Also, I noticed that there's no easy way to remove such indicated files from the inbox. Locate missing files simply does as it says without the option to trash the missing files from Musicbee's db. I was there was an easier way to going about it instead of going to the inbox tab, break up my sorting criteria there, set sorting by "Date Modified" to highlight the missing files having an "N/A" value from the field, and remove these entries once and for all from there. Because I regularly purchase music online and continue to rip what's left of my CD collection, all of these steps get tedious fast when missing inbox files were immediately and automatically resolved in past Musicbee versions.



Best,
theta

[Steven]

i am just going through the first example and havent been able to reproduce the issue.
Could you confirm the following:
- the new file action on the monitor is to add to the library
- you are moving a folder in windows explorer or actually selecting the files (in one go) and just moving the files to the staging folder
- is your library is auto-organised or perhaps auto-sweep so would that files are further organised automatically from the staging folder?
- sending me a link to your MusicBeeLibrarySettings.ini file might help
- i guess i am also unclear why the files would still show in the inbox unless add to inbox was the library new file action
- also were the files actually showing in the music library

edit:
infact i cant reproduce any of the issues you are reporting so await the answers to the questions

[theta_wave]

i am just going through the first example and havent been able to reproduce the issue.
Could you confirm the following:
(1) the new file action on the monitor is to add to the library
(2) you are moving a folder in windows explorer or actually selecting the files (in one go) and just moving the files to the staging folder
(3) is your library is auto-organised or perhaps auto-sweep so would that files are further organised automatically from the staging folder?
(4) sending me a link to your MusicBeeLibrarySettings.ini file might help
(5) i guess i am also unclear why the files would still show in the inbox unless add to inbox was the library new file action
(6) also were the files actually showing in the music library

edit:
infact i cant reproduce any of the issues you are reporting so await the answers to the questions

(1) New file action is to add to the inbox
(2) I move the album folders to a staging directory via file explorer or mp3tag (move to folder based on tags) [I've been doing this for the past 10 years using Musicbee without any issue]
(3) My library is not auto-organized, please see the relevant configuration windows below.
(4) PM'd.
(5) Correct, "add to inbox" is the default action when Musicbee finds a new file.
(6) The files showed up only in the inbox. I manually add every file to the library when I finish tagging them.

Lastly, my MB is a portable install.

[Steven]

Could you confirm I have this right:
- you download the files and MB adds them to the Inbox because they are downloaded to a monitored folder - you said the folder was named "downloads" but i see no such monitored folder so perhaps it is another folder?
- you edit/ move the album folder outside of MB so MB should remove the files from the Inbox at that point
- but when moving them you are moving the album folder within another monitored folder and hence MB should re-add the files back to the Inbox. But again I dont any Staging folder in your folder monitor list. Did you mean for this step that you manually run the File Scanner?

This doesnt quite correspond to what you originally said:
"inbox files that have been moved by myself from a first monitored folder (downloads) to another second monitor folder (staging) via file explorer"
So its quite confusing understanding exactly what precisely is being done and how MB should respond

[theta_wave]

Downloaded files, CD ripped files, etc. go to "0_Transfer" where I fix the tags with MP3tag. From MP3tag, I move the album to 0_Staging where I run them through Foobar's DR plugin to write DR values into the tag. Afterwards, I go to Musicbee's Inbox to add them to my library via "Organize Files". This has been my workflow for many years since first starting to use MB on version 2.5.5. Prior to 3.5.x, I never saw any leftovers/remnants of this process in the Inbox after successfully importing the properly tagged files into my Musicbee library.

[Steven]

when you are downloading, you immediately add them to the Inbox from "0_Transfer" using the manual file scanner?
So at the time you manipulate them/ move them outside of MB they are already in the Inbox?

[theta_wave]

The path of the "0_Transfer" folder is ".\00_Unsorted\0_Transfer", so "0_Transfer" is automatically monitored because the parent directly is among the monitored folders list, so they are in the inbox from the get-go. When they are being manipulated, the downloaded files are already in the inbox.

[Steven]

in that case your workflow effectively corresponds to the testing i did, except i am only moving files with windows explorer.
You have MB running the entire time you do these steps?

[theta_wave]

Yup, I always make sure that both MB and Foobar are running when I make the move. Within mp3tag, my album move is controlled via following action pictured below. The action moves all of the files in the album folder located in "0_Transfer" to "0_Staging" where the album folder and filenames are renamed based on the tag values and the criteria that I set in the action.

For example, I purchased and downloaded a Fleeting Joys album from bandcamp. I unpack the zip into "Fleeting Joys - All Lost Eyes And Glitter," so its path is "\0_Unsorted\0_Transfer\Fleeting Joys - All Lost Eyes And Glitter." Filenames are "<Track#> - <Title>.flac". After tagging the album, my custom action (last modified in 2017) moves all of the contents of the album, plus the included coverart, to "\0_Staging\Fleeting Joys [2021] All Lost Eyes And Glitter [Self-Released, WEB]\" and then renames the flacs to "<Track#>. <Title>.flac". However, it seems that MB does not track the renaming of the first track, so the result is that entry of the first track "01 - foo.flac" in the inbox is left behind despite the first track being renamed to "01. foo.flac". This entry sticks around after organizing the album into the library.



The screenshot below is what happened when I verified a several flacs from ripped CDs that were in the inbox while MB was running: remnant wav files (cuetools apparently creates wavs that are removed after verification is finished). The remnant flacs are from the mp3tag move/rename custom action.

[theta_wave]

Additionally, I've seen malwarebytes quarantining MusicBee.exe 3.5.x lately as ransomware (Generic) whenever I'm scrolling through album art view while MB is caching album art. Malwarebytes likely views MB's album art caching and other MB background activity as reminiscent of ransomware activity. Regardless, MB's 3.5.x behavior is still occurring even after whitelisting Musicbee.exe from ransomware detection.

[Steven]

would you mind running this version
https://www.mediafire.com/file/8gqxmfcfpq0u7xb/MusicBeeDebugMonitor.zip/file
it will log the folder actions mp3tag is using into the error log

re: security software, usually its the new bass*.dll files that trigger the scanners

[theta_wave]

Thanks Steven,

Here's what I saw with one test album I moved from "0_Transfer" to "0_Staging" using mp3tag. Due to the max character length restrictions of forum posts here (even when bracketed by code markups), I had to upload the errorlog to the same link that I PM'd you the other day.

The strange thing is that I don't know where the errant wav files are coming from (nothing is being re-encoded when moving the files). If delete the album folder from "0_Staging" instead of adding it to the library as I usually do, the wav entries are automatically removed from inbox. When I looked at the album folder after fishing it out from the recycle bin, I didn't see any wav files (hidden or otherwise).

EDIT: I don't see any of the reported inbox issues after reverting back to MB version 3.4.7893.

[Steven]

leave behind a missing file indicator for the first audio track

can you confirm one point - were you looking at the Inbox, a playlist, or a sub-folder in the Computer section of the left navigator?

[theta_wave]

can you confirm one point - were you looking at the Inbox, a playlist, or a sub-folder in the Computer section of the left navigator?

I looked at the Inbox and a playlist having the Inbox selected as the source. I never looked at the Computer section.

[Steven]

for the second issue i have put back in some code that will probably address that
for the first i cant reproduce the issue or see how it go wrong, so can you run this debug version and send me the new entries in the log
https://mega.nz/file/IwcVWSDD#5oqCpmRYvQVv7xRra5J3pK6zJ78Rmj2oZpRW9ATFHKs

note that files are not removed from static playlists when a file deletion is detected (and i dont think they were in v3.4 either) - perhaps you were referring to an auto-playlist. If you were did you try pressing F5 to force it to be refreshed?