Beta Testflight access to beta version - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: Supplementary Tools for Kodi (https://forum.kodi.tv/forumdisplay.php?fid=116) +---- Forum: Kodi Remote for iOS Official Forum (https://forum.kodi.tv/forumdisplay.php?fid=193) +---- Thread: Beta Testflight access to beta version (/showthread.php?tid=359717) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
RE: Testflight access to beta version - amasephy - 2024-10-30 Just want to add a minor observation. It’s really not a big deal but it looks like you can block the dismissal timer on toasts. Basically if you are in a scroll animation while a toast is visible the toast does not go away until scrolling stops. In my opinion scrolling should not block the toast dismissal timer. RE: Testflight access to beta version - Buschel - 2024-10-31 Interesting finding. This is caused by the way how the timer is initialized, and gave me some learning. This timer, as all others as well, is running in a context which waits for dragging to end. I can add the timer to a different run loop context (NSRunLoopCommonModes) and this works. Question now is, shall I also change some of the other timers which are -- some since more than a decade -- running in potentially the wrong context? For example I was surprised to see that the server connection heartbeat also stops while dragging. The same happens with updates to NowPlaying while dragging (only possible on iPad though and of less relevance, as in this situation the NowPlaying screen is anyway only partially visible). @kambala: I will raise a PR and we can discuss there. RE: Testflight access to beta version - amasephy - 2024-11-01 By the way, I still get the connection toast when I enter the app on resuming but now it’s seemingly random. Chances of it occurring increase as more time elapses between suspending and resuming the app. This is not how it was prior to the change to make connection instant. It seems something is still at play here. Edit: This may be related to your timer findings in code. If you are actively scrolling it pauses the progress label time in the now playing playlist on the currently playing item. Again, really minor. RE: Testflight access to beta version - Buschel - 2024-11-01 Sounds like the very short timeout I needed to add is not enough to safely have the socket connection back before attempting to connect. Options are: increasing timeout or rework hooking up reconnection with a different iOS framework call. Thanks for reporting! On the other issue you are exactly right. RE: Testflight access to beta version - amasephy - 2024-11-01 Thanks Buschel. Light at the end of the tunnel for this release is very bright at this point. The fast connect feature really is a huge improvement. Hopefully that sentiment is also reflected in the App Store. Your efforts deserve the praise. RE: Testflight access to beta version - Buschel - 2024-11-01 I was not expecting this to make such a huge difference. But when testing older builds the connection time really feels like something is broken. Btw, soon there will be another test build on the image cache topic. Potentially better scrolling performance, a lot less memory use and a bit less flash use. Would be great, if you play with this once available. I will share some notes on how to test and configure it. RE: Testflight access to beta version - amasephy - 2024-11-01 Of course. Hopefully this addresses the global search scrolling issues I’ve discussed. 👍🏻 RE: Testflight access to beta version - Buschel - 2024-11-01 Yep, let's see. There was an additional scaling step (not chached, directly impacting scrolling) every time the image was not matching the targeted aspect ratio. And there is also an option to reduce the processing load further, but I want to have this tested. But finally, this could also just be caused by re-using the cells and changing their size each time. RE: Testflight access to beta version - UlfSchmidt - 2024-11-01 Sorry for my late feedback. I tested the new version on my iPad over the last few days and didn’t come along any problem except one which I couldn’t reproduce: after starting the playback of a music album, the playlist pane didn’t switch automatically to music but remained on the movies view. That’s it. I think this version is ready to be released to the public. Thanks for your great work, @Buschel RE: Testflight access to beta version - amasephy - 2024-11-01 UlfSchmidt I’ve definitely seen that before. From what I can remember there is no real fix for it. Different actions trigger different behaviors with it. For example, if you use the app to start media with the remote control and navigating Kodi server vs going into a library in the app and starting it directly from there. I know that causes different playlist behaviors. RE: Testflight access to beta version - UlfSchmidt - 2024-11-02 Maybe @Buschel can check how the App gets the information which playlist to show? Since he changed the way the App deals with slideshows I ONLY use the App to control my Kodi server, so this can’t be the reason. If I remember it correctly, I reached this situation by simply … STOP PRESS. While I was writing this I had an idea, checked it twice and BANG!! It’s a small side effect of the fast re-connect feature recently introduced by Buschel. Use the following steps to reproduce. Note: you (may) need on Kodi server a skin that shows a welcome video, not just the Kodi splash screen.
RE: Testflight access to beta version - Buschel - 2024-11-02 Interesting. Most likely an effect caused by the App requesting playlist details while Kodi plays some video which is a special case (non playlist?). I remember you raised something similar related to splash videos some years back. I will try to reproduce. For the time being just remove the splash video or start the app later. 😉 RE: Testflight access to beta version - UlfSchmidt - 2024-11-02 (2024-11-02, 09:49)Buschel Wrote: Interesting. Most likely an effect caused by the App requesting playlist details while Kodi plays some video which is a special case (non playlist?)… Interestingly the App shows the welcome video in its movie playlist, but not any music one starts afterwards. So I tried to reproduce this with a regular video: When Kodi server is playing a movie and I start then the App and tap play on any song, Kodi server stops the movie playback, but doesn’t start the music. I have to start the song playback twice. But I was not able to reproduce the effect just by waiting until the movie ended and then starting the App to play some music. This worked flawlessly. So maybe it’s related to the way the skin starts the welcome video and the problem is on server side? Anyhow, don’t spend too much effort on this as it seems to be an edge case, where I am the only one suffering from worldwide?! RE: Testflight access to beta version - Buschel - 2024-11-02 (2024-11-02, 10:37)UlfSchmidt Wrote: Interestingly the App shows the welcome video in its movie playlist [...]I remember we talked over this a while back. (2024-11-02, 10:37)UlfSchmidt Wrote: When Kodi server is playing a movie and I start then the App and tap play on any song, Kodi server stops the movie playback, but doesn’t start the music. I have to start the song playback twice.Hmm, I did the same now: Start playing a movie from Kodi UI (default skin on Kodi 21.1), then start the App on iPad simulator (it shows the playing movie and the related playlist) and then select an album to play (Kodi plays it, app switches to the music playlist and shows it on NowPlaying). Maybe you can share more details on your use case. (2024-11-02, 10:37)UlfSchmidt Wrote: So maybe it’s related to the way the skin starts the welcome video and the problem is on server side?Could be. As @amasephy mentioned the server's behaviour is different for different ways to start playback in the UI. (2024-11-02, 10:37)UlfSchmidt Wrote: Anyhow, don’t spend too much effort on this as it seems to be an edge case, where I am the only one suffering from worldwide?!Yes, this is an edge case. But I guess more people will see such issues and simply accept or think the app is faulty. RE: Testflight access to beta version - UlfSchmidt - 2024-11-02 (2024-11-02, 12:03)Buschel Wrote: Hmm, I did the same now: Start playing a movie from Kodi UI (default skin on Kodi 21.1), then start the App on iPad simulator (it shows the playing movie and the related playlist) and then select an album to play (Kodi plays it, app switches to the music playlist and shows it on NowPlaying). Maybe you can share more details on your use case. It’s even stranger than I thought: I did as you described above - but this time using an album with more than a single track, Kodi skipped the first songs one after the other and then started playback on track number 12! So my observation remains valid, for shorter albums it simply doesn’t start playback at all, as it takes Kodi a while to switch from movie playback to music playback. So, for me it looks like a problem on server side. Because exactly when the server screen shows the Now Playing view, the fast running through the playlist stops. I fear your emulator shows some completely different timing behavior than the App running on real hardware. |