The radio stations are currently stored as user preferences in tuneIn.stations and tuneIn.order. This means the radio stations can be used without a tunein account which I think is very convenient.

Alternatively, the BeoplayRemote.app could fetch favourite radio stations from tunein.com. This would fit into the B&O eco-system. Get/store tunein username/password. Query tunein.com on application start.

I was not able to see the application item in the menu bar until I set the app.title to my preferred value. I guess it should have defaulted to "BeoplayRemote", but it didn't or something happened.

I'll try to recreate with the latest code by wiping app.title

FYI: I have Bartender app running to enable me to see all menu items when there is not enough room.

Hi

Any chance to make the code combatibel with MACos Big Sur?

Thanks.

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

Could fetch the B&O icon from the connected speakers and use it in the menu bar instead of the rather clunky "BeoplayRemote" text label.

my Core goes off every 20 minutes like when you press the power icon button located at the top left of the B&O app main screen. Looking at the device through the B&O app "now playing" screen, it does not show a usual off status but a "tunein" paused status instead. Very confusing and unusual. Note that the all lowercase "tunein" wording is coming from your tool when using the TuneIn Radio option. This "tunein" indicator is never shown when the product is controlled by the B&O App.
I thought it could be a phantom code running on my Mac that could do that, but the device went off even after a Mac reboot.
I restarted the product and after 20' it didn't go off, but I only played with sources and volume with the tool. I'll get back to you with more details when I'm able to reproduce the issue, but my feeling is that the Radio option may introduce some disorder somewhere.

Originally posted by @mbolo01 in #4 (comment)

BeoplayRemoteGUI.app is automatically compiled and relased by the github "release" workflow whenever a new release tag is pushed to github. Release files can be downloaded from https://github.com/tlk/beoplay-macos-remote-gui/releases

Neat.

Downloading and running the thing is another story, though, as Chrome warns that the file may be dangerous and macOS will need some convincing since it is not signed with an Apple developer certificate.

That said, the BeoplayRemoteGUI.app built by the github workflow seems to work.

It would be nice to have « standby » and «standby all » options to put the selected devices or all B&O devices in standby mode. This feature is implemented in the B&O app (top left power icon), in all B&O remotes (long press on the stop button) and can also be configured on all their devices that can be physically controlled.

a "join multiroom experience" option would also be a good enhancement in the Sources. The Home Assistant has a reference to it, but I have not seen it working. Fyi, when you have multiple products configured for multiroom, a product can join another product that is streaming something by either physically acting on the product itself or a remote, or through the B&O App.

Originally posted by @mbolo01 in #4 (comment)

Create custom view with the following info:

• Artist name
• Album name
• Album art

Hotkeys should work when the menu is open, but they do not.

Currently, hotkeys are disabled/enabled when the menu is opened/closed. This workaround is used because otherwise keypresses are queued up while the menu is open and then being processed all-at-once after the menu closes.

I am not sure why or where the events are being queued and I do not understand the root cause of this issue. The hotkey library being used is this: https://github.com/soffes/HotKey/

I have been experimenting with another workaround based on hidden-but-enabled menu-items with corresponding keyboard shortcuts. This works, although the menu closes immediately on keypress.

the mechanism in charge of reconnecting the notification-receiver implements a simple backoff algorithm in order to keep it from entering a busy-loop hammering out 1000s of connection attempts during an error scenario. This means that it might last more than 2 minutes before it attempts to reconnect. Maybe this is what you are seeing.

This could be improved by having the UI reset the backoff algorithm and make it attempt a reconnect immediately when receiving a command (play, etc) or when the user open the status menu.

Originally posted by @tlk in #18 (comment)

It would be nice to be able to see what is currently playing.

For tunein radio stations, this could be indicated with a check mark symbol next to the radio station.

May I suggest different signs that inform about an issue such as:
"! M5 Kitchen" or "x M5 Kitchen"

Originally posted by @mbolo01 in #9 (comment)

Instead of using submenus for the sources and tunein stations, those items could be visible from the main menu, ala:

Originally posted by @tlk in #4 (comment)

Bonjour. Thanks again for this development that I discovered through the Beoworld forum and which I hope will one day catch B&O interest and support.
In the mean time, if I may and for the purpose of sharing only, I would like to submit ideas and report bugs when identified.

Idea:
On the same principle than the TuneIn Radio section, a "Select Source" could be a nice addition.
Use case: I often change sources for my main product as I have many going through such as internet streaming services, local DLNA media server, a TV, a record deck via an another linked B&O product or simply joining another experience (B&O multiroom). A simple source selector from a source list pulled from the selected product would help, like it has been done for the Home Assistant integration.

At the end of the day your clever development could be the GUI version of the B&O Essence remote product which has basic, but super useful, functions to drive any brand product.

Many thanks again

B&O has replaced "TuneIn" support with "B&O Radio" in a recent firmware update.

Refs tlk/beoplay-macos-remote-cli#3

I have the following Xcode error:

Previous version works fine.
Kind regards,
Jérôme

From beoworld.org:

controlling a Moment with the app triggers high CPU usage on the Mac and the app must closed to recover.

Crashes are happening frequently with the latest code iteration when the Mac goes in sleep mode while on battery. I could capture this in Xcode:

019-11-30 15:42:39.435482+0100 BeoplayRemoteGUI[9534:689302] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSArrayM: 0x600000c66fd0> was mutated while being enumerated.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff3ba41acd __exceptionPreprocess + 256
1 libobjc.A.dylib 0x00007fff66143a17 objc_exception_throw + 48
2 CoreFoundation 0x00007fff3bab5372 -[_NSSingleObjectEnumerator init] + 0
3 AppKit 0x00007fff39315544 -[NSMenu indexOfItemWithRepresentedObject:] + 231
4 BeoplayRemoteGUI 0x0000000100018649 $s16BeoplayRemoteGUI20DeviceMenuControllerC03getE4Item33_4CD222AE1A7609D3DCCAA857D78A448DLLySo06NSMenuH0CSgSo12NSNetServiceCF + 89
5 BeoplayRemoteGUI 0x0000000100016d1f $s16BeoplayRemoteGUI20DeviceMenuControllerC06removeD0yySo12NSNetServiceCF + 687
6 BeoplayRemoteGUI 0x00000001000161ad $s16BeoplayRemoteGUI20DeviceMenuControllerC06handleD7UpdatesyySayAA0D7CommandVGFyycfU + 813
7 BeoplayRemoteGUI 0x000000010000486d $sIeg_IeyB_TR + 45
8 libdispatch.dylib 0x0000000100415e7c _dispatch_call_block_and_release + 12
9 libdispatch.dylib 0x0000000100416f1b _dispatch_client_callout + 8
10 libdispatch.dylib 0x000000010041f067 _dispatch_lane_serial_drain + 773
11 libdispatch.dylib 0x000000010041ff1b _dispatch_lane_invoke + 442
12 libdispatch.dylib 0x000000010042b4db _dispatch_workloop_worker_thread + 691
13 libsystem_pthread.dylib 0x0000000100490015 _pthread_wqthread + 421
14 libsystem_pthread.dylib 0x000000010048fe01 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(Recorded stack frame)

There is an issue where the BeoplayRemoteGUI.app sometimes, but not always, fails to auto-connect to the device it was last connected to.

This issue was observed quite frequently on recent macOS releases while macOS 11.5.2 appears to have reduced the failure rate.

I have observed similar behaviour using the DNS-SD Browser discovery.app where a device is discovered but sometimes resolving is either very slow or fails to complete.

It would be nice to have only one play/pause option instead of two distinct actions.

Dear "tlk"

I think that the drop down menu should stay unless another area of the screen is clicked, where currently it closes after an action is chosen.
E.g. for a previously selected product, If i want to select a radio and change the volume consecutively, I have to (1) select the B&ORemoteGui icon in the menu bar, (2) select a radio, (3) select the B&ORemoteGui icon in the menu bar (4) choose the volume .... and assuming the volume chosen is not good, (5) select the B&ORemoteGui icon in the menu bar and (6) reposition the volume.

The iOS app does not show the radio station name when it has been started from the BeoplayRemoteGUI.app

I usually have to launch the application twice to get the full list of my devices. Maybe waiting more time for product advertisement is required at startup or auto-refreshes while the menu is developed?

Originally posted by @mbolo01 in #4 (comment)

When TuneIn is controlled through B&O code, the first step may be to fetch the TuneIn user's favorites (which requires a login to TuneIn), including some static metadata such the radio name. This list of radios may then be used to build a kind of play queue that can be controlled like other play queues, with the exception that the play queue content is not exposed in the app now playing screen like a music play queues are. Controlling the radio play queue is like controlling a music play queue: pause/start/forward/backward.

When controlled by your application, only the selected TuneIn radio is pushed in the play queue, which means that forward/backward actions have no effect and this is perfectly normal.

In order to introduce this kind of navigation within a radio list, and without a need to login to TuneIn, do you think it is possible to push the list of the application configured radios so it can be controlled by the app backward/forward options, or from a physical remote if closer?
I understand it is useless form your app point of view only as the radio list is directly seletable without the need to navigate forward/backward, but could be a nice addition so it can be used jointly by a physical remote. I see that as a nice to have.

Originally posted by @mbolo01 in #4 (comment)

Unfortunately the BeoSound Moment is not following the same exact schema than the other B&O products. Where volume control respond to the same commands, other actions are failing or not producing the expected results.
It would be good to either inventory the differences and grey out some options when they are not compatible with the Moment (which is EOL, so we can guess it will never be aligned with other products), or learn about the differences and treat them as exceptions.

KR - Jérôme

When pausing a device that is a secondary member of a multiroom group, the multiroom master device is paused too.
Normal behavior should be to pause only the selected device. In case the selected product is the multiroom master, then all devices member of the multiroom are paused or stop receiving multiroom flow.

Despite all conditions being met, f11 and f12 are no loger working, all the other fn keys are.
Nothing changed in my Mac configuration that I could think about, I checked in Mission control and these Fn are not used.
I ran again the terminal default commands
Any idea where I should look?

This application listens for hotkeys being pressed, and it does not stop them from being captured by other applications.

Example:
Open Chrome.app and press F12. This will turn up the volume, but it will also open the Chrome Developer Tools.