[amasephy]

For me the opposite is true. There are some major issues with the fast connect feature.

When I suspend the the app and resume I get a disconnect message about 99% of the time. Also, usually this results in just the main menu being visible which I have never seen before. Usually some of some other pane is partially visible.

Note: when this has occurred and upon resuming establishing a connection to the server is just as slow as it always has been. The fast connect feature isn’t work there.

Regardless, the connection should not be getting lost so easily. I’ve never experienced this before.

This is incredibly annoying and definitely needs some tuning before releasing. 🙂

See this video of it in action.









Edit: Might not be a bug but new intended feature but the small icon you just fixed on iPhone for now playing toggle is now persistent when viewing the now playing playlist.

Edit 2: Here’s a nasty scenario. Upon resuming I got trapped in the custom button menu with no ability to leave it without force quitting the app.

[UlfSchmidt]

@amasephy experiences are such a pity. I really tried every way to make the quick reconnection feature fail. For my configuration, it simply works amazingly. Could this be a difference between iOS 17 and 18? I am still on 17 with my iPad. Or it is a timing issue, as my old iPad might be simply too slow to fail?

[Buschel]

Thanks for the quick overnight feedback. I was not expecting everything to work like charm right away. So, let's dig into it:

When I suspend the the app and resume I get a disconnect message about 99% of the time.
[...]
See this video of it in action.

Well, when you suspend, you *do* disconnect from app. I assume what you see is that the connection is "lost" because the app is going to background and disconnects. In the video I can see that you just reopen within a second. This way you still see the toast message (which takes 2+ seconds). But this should have happened also with the TF builds before. I might just drop this specific toast message, except when the server list is up. Then only the indicator will show "red status", but no toast message pops up. Less annoying.

To confirm this, can you please test, if
a) this happens only with this build in the exact scenario which you tested?
b) this is gone, if you just wait for 3-5 seconds before waking up the app again?

Also, usually this results in just the main menu being visible which I have never seen before. Usually some of some other pane is partially visible.

This is most likely related to the change to not see any glitchy animation of the server list (sliding it out and sliding in the targeted pane).

Note: when this has occurred and upon resuming establishing a connection to the server is just as slow as it always has been. The fast connect feature isn’t work there.

Ok, could be a use case I was not looking into deep enough. Connection on wake-up after sleep might just run in the common heartbeat / timer based loop.

Edit: Might not be a bug but new intended feature but the small icon you just fixed on iPhone for now playing toggle is now persistent when viewing the now playing playlist.

What is the bug? The cover thumb should always be visible in the playlist view and has always been. Or am I getting something wrong?

Edit 2: Here’s a nasty scenario. Upon resuming I got trapped in the custom button menu with no ability to leave it without force quitting the app.

How exactly do you get here? I assume this is an effect of trying to find a solution which does show the glitchy animation of server list before moving to the target-pane.

Edit: I should just never had implemented this feature to automatically enter a submenu. Just 1 click for a user, a lot of trouble for me.

[amasephy]

All previous builds I never experienced the disconnect notice nor did the connection circle turn red doing the exact same actions as in my video.

Just retested and there’s no issue with even the previous TF. See video.


Regarding the persistent icon please disregard. A goof on my part.


To reproduce being trapped in settings pane just suspend the app while viewing that pane. Same situation as main menu screenshot. Basically the remote pane is gone from both views so no navigation is possible. See video.


Btw, apologies that these are in the YTShorts format. I truly hate this but any short clips are automatically set to a short by YouTube.


I am glad you created the feature to go into submenu. It really is nice to have. I know it is more work but definitely worth it for us users. Please don’t give up on it.

[Buschel]

Thanks for retesting with the previous build. I will have look tonight. It is often messy to rework on/off related functions. So, good we see this on a TF build and not a release.

Edit: can confirm the issues you describe on my device as well. Will try this on simulator later, which would be great.

[Buschel]

The issue with the hidden pane is resolved -- a silly but impactful logical error. I am sure this also fixes the issue where you were stuck in the custom button menu of the remote.

What is concerning me is that the simulator does not show the "disconnect" behaviour at all. Will now set up everything to debug on my device.

[amasephy]

Sounds good. Thanks for quickly looking in to this. Glad you were able to find the issue and replicate it.

[Buschel]

Repro of the disconnect message is a pita. This is only reproducible when running on the physical device, and w/o having the debugger connected. This is obviously a timing issue. The old implementation started the JSON heartbeat checks only 3 seconds after "UIApplicationWillEnterForegroundNotification", the new implementation does it right away. As soon as I add a minor delay of 0.1 seconds this error does not occur anymore. Also possible is to start the heartbeat check with "UIApplicationDidBecomeActiveNotification".

@kambala, Is it possible that the App cannot address JSON commands that early (WillEnterForeground) and therefor fails? (https://stackoverflow.com/questions/6362...connection points to something similar).

Edit: Raised PR#1170 for this.

[amasephy]

Third Font Scaling bug has been found. For some reason it’s only an issue on iPad. The version number of the app on what I’ll call the “mascot” pane gets truncated.


Edit:
Something to consider with the bounce rework. There are some disadvantages to the changes with this. Comparing old TF to more recent ones with this change you can run into issues if you open many panes where the main menu can be mostly obscured and you can’t move the panes out of the way like you used to be able to.

An easy way to showcase this is simply bring up the remote, press settings gear, then press …more. Now try moving the panes out of the way to display the main menu in its entirety. It’s no longer possible. However before this refactoring it was easily possible.


Edit 2:

I know you fixed the connectivity issue on iPhone. Still, wanted to let you know something bizarre. I realized that even when that network connection lost toast is visible and the network icon is red, you can actually use the remote to unpause content and it works just fine. So it’s almost like the app is lying about its state.

[Buschel]

1. Font scaling -> Fixed.
   
2. Stack rework -> I will keep like it is for now and wait for more feedback. Finally you ask for the possibility to have a 2nd stable "left" position for a stack with more than one pane.
   
3. Connection state -> Yep. "Connected" means, that the app found the server and could receive a response. In the error case the app could not reach this state at the very first attempt and flags "red". But in fact, this works already right after (0.1 seconds or even less), but the app only checks the state each few seconds (so-called heartbeat). Therefore you still see "red", even though everything works. And I am not planning to do anything about it. Too much hassle for a delayed status icon.
   

[kambala]

Repro of the disconnect message is a pita. This is only reproducible when running on the physical device, and w/o having the debugger connected.

always has been. When minimising an app, it enters suspended state and all sockets are closed, but with debugger attached app never enters a suspended state.

Is it possible that the App cannot address JSON commands that early (WillEnterForeground) and therefor fails? (https://stackoverflow.com/questions/6362...connection points to something similar).

Edit: Raised PR#1170 for this.

yes, that's right, app must "become active" first

[Buschel]

Thanks, then the 10 years old way of doing it just worked because of the long delay. We can discuss further details in the PR (active state vs short delay).