Messages

1

Bug Reports / Re: WASAPI (SHARED) Completely Stopped Working

« on: March 15, 2024, 06:58:32 PM »

I have a similar bug with Windows 11 and my Musicbee (v3.5.8447 P / output: WASAPI shared) running on my work laptop. Yes, it is an older edition that works perfectly fine on my home desktop. Basically, I have a DAC that is connected to a hub for my laptop. Whenever the laptop screen goes to screensaver mode or turns off after a set idle time, the sound does not work. My workaround is to exit Musicbee, click the volume slider on Window's volume control to produce a sound through the DAC (listed therein as a speaker), and then restart Musicbee.

Of course, there could be a problem with my hub, my DAC (predates Win10), and/or Windows 11 itself. Just offering an observation here and that I'm holding onto my home Win10 install until its EOL.

2

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 31, 2022, 03:00:42 PM »

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.

3

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 31, 2022, 01:53:01 AM »

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.

4

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 30, 2022, 10:20:26 AM »

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.

5

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 30, 2022, 10:05:54 AM »

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.

6

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 30, 2022, 09:04:42 AM »

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.

7

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 30, 2022, 08:50:35 AM »

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.

8

Bug Reports / Re: [3.5.8334] Moved / temp inbox files still show up as missing

« on: October 30, 2022, 06:55:31 AM »

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.

9

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

« on: October 29, 2022, 06:21:28 PM »

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

10

Bug Reports / Re: [3.4.7628] Unchecked double-click action in album view but it still works

« on: January 10, 2021, 06:37:48 PM »

What's in that thread are not "daily" patches. Those are beta releases that incorporate previous patches. You can always get the latest patch from my signature. Or psychoadept's. You can also bookmark the link in my sig and keep it hand. Personally I find it better to follow the forum to see what fixes/changes are incorporated in the new patches.

I think I should have been more clear. What I meant to say is that the patch link was not apparent from any of the links in the "Latest Version" subforum, either in the "Musicbee 3.4 Links" or the "MusicBee 3 Latest Patch Version" threads (the latter of which display outdated links directed to the niblseed hoster). When I was more active on here, I used to use the niblseed.com link to grab the latest daily patch version, but that hoster is no longer available. I also looked at the Bug Reports and Developers' Area for any pinned "latest patch" threads to no avail. The pinned "BEFORE YOU POST - READ THIS" thread in this subforum also does not have the link for the latest patch. So, after reasonable diligence, there was no clear way for me to find the daily patch link without it being provided to me first.

Sorry, despite being a veteran here (remember, you asked me to contribute to the wiki in the past), but a rather inactive one for the past couple of years, I didn't know that I had to go search for your and psychoadept's sigs since I was only focused on the bug forum. Personally, I think that the patch links should be included in a thread in the "Latest Version" subforum and/or in the pinned "BEFORE YOU POST - READ THIS" thread. It seems rather unobvious and cumbersome to go hunt for the sigs of certain members to obtain the daily patch link.

11

Bug Reports / Re: [3.4.7628] Unchecked double-click action in album view but it still works

« on: January 10, 2021, 09:14:30 AM »

https://getmusicbee.com/patches/MusicBee34_Patched.zip
unzip and replace the existing musicbee application files

Thanks Steven.

So, I looked at my MusicBee3Settings.ini prior to applying your patch and it read:

Code

<CoversDoubleClickPlayAlbum>false</CoversDoubleClickPlayAlbum>

However, as shown in my first post, the custom views setting for album art had the option "directly under the selected album or artist" selected for the "show tracks" checkbox. After applying the 7680 patch and restarting Musicbee, the custom views setting for album art correctly had the option "in a separate panel (double click)" selected. Selecting the option "directly under the selected album or artist" brought back the expected behavior.

After closing 7680 patch, the MusicBee3Settings.ini changed the above setting line to the following:

Code

<CoversDoubleClickPlayAlbum>true</CoversDoubleClickPlayAlbum>

Problem solved. Thanks again Steven!

12

Bug Reports / Re: [3.4.7628] Repeated crashing, my setup?

« on: January 10, 2021, 04:39:30 AM »

After updating to the latest basswasapi.dll, I'm happy to say that I haven't experienced any access violation crashes over the past two days. The access violation bug is likely related to the state of my DAC at those times: http://www.un4seen.com/forum/?topic=18305.0

13

Bug Reports / Re: [3.4.7628] Unchecked double-click action in album view but it still works

« on: January 10, 2021, 04:37:13 AM »

I'm using 3.4.7679 P, so you should update to the latest patch version as Steven indicated.

Where did you get that? The latest patch version in the 3.4 thread is 7628 from Nov. 19, 2020: https://getmusicbee.com/forum/index.php?topic=32142.msg183458#msg183458

14

Bug Reports / Re: [3.4.7628] Unchecked double-click action in album view but it still works

« on: January 09, 2021, 10:50:34 PM »

Hi Steven,

I'm using the latest patch version as stated in the topic title: 3.4.7628 P

15

Bug Reports / [Solved] [7628] Unchecked double-click action in album view but it still works

« on: January 09, 2021, 06:26:40 PM »

Bug: Double clicking an album under album view takes me out of album view to an "album and tracks" view showing all of the album's tracks, which can already be viewed in album view when single clicking an album (showing the tracks "directly under the selected album or artist"). I have to perform another click on the back arrow to take me back to the album view. The options under "customise panel" and panel settings are provided below.

Expected: Double clicking an album under album view plays the album (I think this was the old setting, no?) or does nothing per the settings.

Comments: I feel that double-clicking the album under album view that takes the user out of the present view to another view showing only that album is a little jarring and requires an additional click to bring back the previous view. Furthermore, I feel it is a bit redundant if the setting for showing the tracks "directly under the selected album or artist" is already selected as shown in my "customise panel" setting.

Thank you for looking into this issue.