Messages

1

Bug Reports / Re: Artwork resize not at your will

« on: June 08, 2024, 06:28:40 PM »

Thanks for the screenshots, which confirms that a 'Save' button is not available when opening the device settings panel from the navigator panel.
You could create a wishlist post for that. It is not a software bug.

First of all, thanks for all the answers. I am afraid that the missing Save button is indeed a bug, as it is impossible to change the artwork resize value. It works without the button for other fields, I still think it's a good practice to put such button (as it is the case for the Preferences panels).

I don't see a screenshot of the multiple entries for a single device?
Could you screenshoot that too?
Do you think there is a software bug there, or maybe something for the wishlist?

I think that it is not software bug as per the Preferences panels management code. It is probably a bug/mismanagement in the Android discover department, which is not the strongest point of MB unfortunately even if it has improved a lot with time. Unfortunately, I have removed the extra entries so I can't show them. I have backups and I should be able to recover the .ini file, 'tho.

My guess is that I have upgraded during the years my phone from Android 12 to Android 14 passing through Android 13, and this is probably the reason why I had three separated entries (and this is probably also the reason I had to reconfigure the naming scheme on the phone... sigh!)

I agree with you that this issue would need a separate thread. If I recover the .ini file I will think about opening another bug/wishlist request.

Thanks again.

2

Bug Reports / Re: Artwork resize not at your will

« on: June 08, 2024, 05:10:27 PM »

Here you are.

In Preferences:



In <Device> / Settings:



No Save button here. Without remembering about the equivalent function in the Preferences dialog, I had to patch the .ini file to get the resize size I wanted.

As I've written, most other Windows applications (including Windows Explorer) show the name I've assigned to my mobile phone. MB unfortunately doesn't get it, and it sticks to the model number also for the name.

3

Bug Reports / Re: Artwork resize not at your will

« on: June 08, 2024, 04:50:24 PM »

A "save" button already exists. And it saves the artwork at whatever size I choose. So that begs the question are you doing this in the device settings of the preferences menu?

Nope.

I am in <Device> / Settings, and there is no Save button there. However, thanks for pointing me to the preferences dialog, I completely forgotten about it. And yes, once having selected the device, I get the device settings with the Save button.

So, it seems that the button has been forgotten on the other device settings panel, or is it the skin's fault? (Dark-Fine Tuned / Mahogany)

Ans while I am at it, I have THREE instances of the same device in the preferences dialog, I can't understand why, and I can't understand where MB gets its name, as it's not the one also shown in the Windows Explorer tree.

4

Bug Reports / Re: Artwork resize not at your will

« on: June 08, 2024, 03:34:10 PM »

Oh, the reason being that even if the new value is show, even if you move from tab to tab, etc. and it is still shown, the app doesn't really knows about and it remains stuck at 200 px. Matter of fact, exit and relaunch the app et voila, the setting is back to 200.

Please, add that Save button, thanks.

5

Bug Reports / Artwork resize not at your will

« on: June 08, 2024, 03:20:26 PM »

I am trying to define the album artwork should be uploaded on my Android phone. Within the <Device> / Settings page there is the resize artwork to: set by default to 200 pixels. I would like to have instead it resized to 500 pixels, and still copied as folder.jpg

MusicBee has different ideas eventually, as no matter what value I put in the text box I always end up with folder.jpg having 200 pixels of resolution. On a related note, I still find the absence of a Save button a minus, not a plus. I know for sure that in the past it was the case of not having the user choice being reflected in the proper app setting, and this may be another case.

Edit: I've forgotten to indicate the affected version. It's 3.6.8902.

6

General Discussions / Re: Multi-channel support... somewhat

« on: May 05, 2024, 09:43:56 PM »

I have created a wishlist request. Hopefully it will be easy to integrate, as the support is half there already.

7

MusicBee Wishlist / Add support for playing multi-channel tracks (channels downmix)

« on: May 04, 2024, 10:55:08 PM »

Following my help request in another forum section, for which I was hinted to add one item to the wishlist, I'd like to ask to add the proper support of multi-channels tracks to MB.

As explained, MusicBee has no issue in cataloging multi-channel tracks: they are correctly shown, tagged, and probably decoded. Unfortunately, playing them is a completely different matter: the multiple channels are not mixdown properly when the loudspeakers setup has a number of channels different from the tracks being played. MusicBee either fails to send the proper channel(s) to the audio driver, or its downmix logic is flawed, because all I get is the absence of certain channels in the soundscape. Needless to say, any other "competitor" does the right thing, but I love MB and would like to stick with it.

Thanks.

8

General Discussions / Multi-channel support... somewhat

« on: April 21, 2024, 12:50:01 PM »

I've searched in the forum about playing multi-channel tracks, but it doesn't seem there are many posts regarding this feature. I am actually not sure if it is a feature officially supported, or just supported by accident.

The fact is that MusicBee has no issue in cataloging multi-channel tracks, at least in FLAC format: they are correctly shown, tagged, and decoded. Unfortunately, playing them is a completely different matter, and it has been delusional until now, at least for me. The posts I've found suggest many workarounds, like selecting ASIO drivers, but hinting also that not every ASIO driver works as expected. Others suggest to go for WASAPI, but to be honest I am quite sure multi-channel tracks are not first class guests in MusicBee.

Apart from the fact that certain drivers may capture the audio, making it exclusive to the application (ASIO does it for sure), in my case none of the combinations of ASIO (different flavors), WASAPI or DirectSound has produced an acceptable result. I'd say that the problem is that MusicBee either fails to send the proper channel(s) to the audio driver, or its downmix logic is flawed, because all I've got, using a 2.1 loudspeaker set correctly configured for downmixing in the sound control panel, is the absence of certain channels in the soundscape.

I've done comparisons using the Kodi, Foobar or even VLC running on the same PC/audio setup, and MusicBee is at fault here, because every other player does perform as expected.

To be honest, I don't know if the above should be considered a request for a new feature, or a for a fix for the existing one. As said, as of today my experience of MusicBee and multi-channel has been disappointing.

Thanks for your time.

9

Portable Devices / Cannot delete albums in the smartphone

« on: January 18, 2020, 07:01:25 PM »

I as cleaning up my LG V20 smartphone, connected as usual via the USB cable. From within MusicBee I wanted to make some space in the SD card, removing albums I haven't listened to recently.

MusicBee v3.3.7310.31925D  (Win10.0), 18 Jan 2020 19:53:

System.ArgumentException: Value does not fall within the expected range.
   at PortableDeviceApiLib.IPortableDeviceProperties.GetValues(String pszObjectID, IPortableDeviceKeyCollection pKeys, IPortableDeviceValues& ppValues)
   at #=ze0Dt7lPSf5eP$8ro6evGLpjcjSTx.#=za3LWcex3nEZl(String #=z9qMyR9M=, IPortableDeviceKeyCollection #=z$MAljKs=)
   at #=ze0Dt7lPSf5eP$8ro6evGLpjcjSTx.#=zzy$5I_4rbb5hKTIZPg==(#=zlkE2wlw28gwaYlXF4g== #=zNgiccaliIEsX)
   at #=zPcl_Dm20tBbtWkG__qfpA5U=.#=zif_bLtSWbhUpvR_QlQ==(#=zlkE2wlw28gwaYlXF4g== #=zNgiccaliIEsX, #=zlkE2wlw28gwaYlXF4g==[] #=zEz6YmJV5RZBF)
   at #=zcSUiT7FfjPAJ1lCP26kaFcE=.#=zEuznFSCd9tOd(#=zVqPZLW7f_DNBEznUXAxeL38= #=zXICeNpL3C0tk, List`1 #=zekChE4M=, #=ztnKRVAgJflCp_7S4r2oXiHt2$ZKJ #=zxoasSq8=)
   at #=zdRddAG2q7x5I$VaZLhRt54nbElrv.#=zPvjORnV_IbOc(#=zVqPZLW7f_DNBEznUXAxeL38= #=zXICeNpL3C0tk, List`1 #=zekChE4M=, Boolean #=zpJXkyEncr3bZ)
   at #=zdRddAG2q7x5I$VaZLhRt54nbElrv.#=zErh16MQNGJ_uncnrBA==.#=zhGWfqavGcQvcfSZ2h4LOIL4=.OnKeyDown(KeyEventArgs #=zS9VYR_E=)
   at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
   at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
   at System.Windows.Forms.Control.WmKeyChar(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at #=z5SLAdS5FYWmDClcjULjlBIk=.WndProc(Message& #=zPs30CL4=)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


I normally do the cleanup using Windows Explorer, or directly in the smartphone, so I don't know if this is a new bug, or not.