Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application crashes #18

Closed
mbolo01 opened this issue Nov 30, 2019 · 7 comments
Closed

Application crashes #18

mbolo01 opened this issue Nov 30, 2019 · 7 comments

Comments

@mbolo01
Copy link

mbolo01 commented Nov 30, 2019

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)

@tlk
Copy link
Owner

tlk commented Nov 30, 2019

Oh, that's not good. Thanks for the stacktrace. Maybe the latest update addresses this. Still learning ;-)

I have been experimenting with Swift Combine and SwiftUI. It would be useful to avoid issues like this one and would also come in handy to make the app stateful (for the togglePlayPause button, showing current source and radio). The catch with Combine and SwiftUI is that it only works on macOS Catalina (10.15) or newer as far as I can tell. Would that work for you?

@mbolo01
Copy link
Author

mbolo01 commented Nov 30, 2019

Thanks! I'll see if the latest update has addressed the issue.
Regarding Catalina, I'm not yet there. Not all the programs I use are Catalina compatible yet, I think I'll move to Catalina in a couple of week at the soonest.

@mbolo01
Copy link
Author

mbolo01 commented Dec 1, 2019

No crash since the latest update. Well done!

@mbolo01
Copy link
Author

mbolo01 commented Dec 2, 2019

I noticed that when the Mac comes back from sleep mode, BeoplayRemoteGUI does no longer show the latest used device with a check mark while the latest used device is indeed the one the fn key are acting on even is not check marked in BeoplayRemoteGUI.

@tlk
Copy link
Owner

tlk commented Dec 3, 2019

Ok, maybe there will be other users some day, so keeping the backwards compatibility :-)

Good to hear about the lack of crashes.

I recently made it so the app will switch to a ― symbol instead of the ✓ symbol when it is connecting/reconnecting to a device in order to receive notifications such as current source, current radio station, current volume level. Under normal circumstances the ― symbol should only be visible for a short moment when reconnecting.

Now, 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.

Firing off commands at the device (play, etc) will go directly to the device as separate requests, so they work independently from the notification mechanism.

@mbolo01
Copy link
Author

mbolo01 commented Dec 3, 2019

Good idea to keep backward compatibility, which does not prevent you to decide the maturity point of the legacy version and stop maintaining it while progressing on a more modern version for Catalina and higher, but again I'm not a developer, so I may not understand all the implications.
When the user opens the status menu could be the best option so you know at that time what device you'll fire off commands and so avoid playing loud in the bedroom thinking you are controlling the party room :-)

@tlk
Copy link
Owner

tlk commented Dec 3, 2019

Yep, will have a look at the backoff algorithm at some point. Btw, I recently changed the app so it auto-connects only to the default device specified under "devices.default". If that setting is left empty or unset the app should never auto-connect to a device. I think that is preferable over auto-connect because it will prevent situations like the one you just described :-)

@tlk tlk closed this as completed Dec 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants