philipp.hofmann

Hi Remy, a) I've checked now with "netstat -an". On MacOS10 I get the following entries: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.2020 *.* LISTEN udp4 0 0 *.2020 *.* On MacOS11 I get the following entry only: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.2020 *.* LISTEN but there is no entry for *.2020. I can see with Wireshark-Packet-Sniffer that the UDP package for Port 2020 is there but not read on MacOS11 computer. Best regards, Philipp

Hi Remy, do you have any other idea what to check on my side to solve the MacOS11 issue? Can you reproduce on your side the issue with MacOS11? Best regards, Philipp

The command "nc -vnzu 192.168.10.30 2020-2040" returns "[udp/*] succeeded!" for all ports. But also if the app is not running yet and it's the same response on MacOS 10 as on MacOS 11. I'm using the Delphi-Tethering-implementation and it looks like Start-Listing was successful. FAcceptWait contains the default value, so 1000. I'm wondering if there is any new setting to use for MacOS 11 (e.g. capabilities). I know the Multicast-capability yet but this is only for iOS14.x.

The question for me is now, why it works with your MacOS Big Sur? Is it a different setting for the Mac or a different setting in the provision profile? Can you see that the method TTetheringNetworkManagerCommunicationThread.DoOnReceiveData reached if you start the app on MacOS, equal if DesktopWWallApp or MobilePhotoApp?

Hi, I'm using TIdTime to synchronize the time for an online process but it's not working as expected: Documentation TIdTime.DateTime: - DateTime is a read-only TDateTime property that reflects the estimated current date and time according to a Time server. - DateTime is expressed in the timezone for the local computer. procedure TicTrainerF.syncTime(); var idTime:TIdTime; dtLocal1,dtLocal2,dtServer:TDateTime; begin idTime:=TIdTime.create(nil); idTime.Host:='time.nist.gov'; dtLocal1:=NOW; dtServer:=idTime.dateTime; dtLocal2:=NOW; mlog.info('syncTime: '+DateToStr(dtLocal1,myFormatSettings)+'/'+DateToStr(dtLocal2,myFormatSettings)+' vs '+DateToStr(dtServer,myFormatSettings)); ... It's fine for my windows-computers, so I can use it here. 1. But it's wrong for Android and iOS as the time is returned in UTC instead of the local time zone. -> Question A: Is there a fixed rule for this so that it's always in UTC for this OS? 2. On my Amazon FireHD-10 tablet (FireOS/Android) I get something completly different. -> Question B: Was is the reason for completly different results here? incorrect (timezone): --------------------- syncTime (Android): 2021-01-18 16:24:50.789-16:24:51.169 vs 2021-01-18 14:24:51.000 syncTime (Android): 2021-01-18 16:24:48.071-16:24:48.428 vs 2021-01-18 14:24:49.000 syncTime (iOS): 2021-01-18 16:24:49.658-16:24:49.996 vs 2021-01-18 14:24:50.000 incorrect (at all): ------------------- syncTime (FireOS/Android): 2021-01-18 16:24:48.606-16:24:49.028 vs 2021-01-18 14:40:02.000 correct: -------- syncTime (Windows): 2021-01-18 16:24:47.612-16:24:48.359 vs 2021-01-18 16:24:48.000 syncTime (Windows): 2021-01-18 16:24:46.014-16:24:46.771 vs 2021-01-18 16:24:47.000 It's important for me that I can rely on the synchronization, else it's better to skip it and ask the user to take care of it. Are there idea how to improve this synchronization? Best regards, Philipp

Yes, I've changed it in IdGlobalProtocols.TimeZoneBias. I've tested it only with Android but I'm very sure that it's fine for MacOS/iOS also. I can test a new version of the Indy-implementation without huge effort, if this helps you. You have to send me only the pas-file to replace.

Hi Remy, it's Result := -1 * (TTimeZone.Local.UtcOffset.TotalMinutes / 60 / 24);

The error occurs in IdGlobalProtocols.TimeZoneBias: function TimeZoneBias: TDateTime; {$IFNDEF FPC} {$IFDEF UNIX} var T: Time_T; TV: TimeVal; UT: {$IFDEF USE_VCL_POSIX}tm{$ELSE}TUnixTime{$ENDIF}; {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} begin {$IFNDEF FPC} {$IFDEF UNIX} {from http://edn.embarcadero.com/article/27890 } gettimeofday(TV, nil); T := TV.tv_sec; localtime_r({$IFNDEF USE_VCL_POSIX}@{$ENDIF}T, UT); // __tm_gmtoff is the bias in seconds from the UTC to the current time. // so I multiply by -1 to compensate for this. Result := (UT.{$IFNDEF USE_VCL_POSIX}__tm_gmtoff{$ELSE}tm_gmtoff{$ENDIF} / 60 / 60 / 24); {$ELSE} ... If I replace this with the following it's fine: function TimeZoneBias: TDateTime; {$IFNDEF FPC} {$IFDEF UNIX} var nowDt:TDateTime; {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} begin {$IFNDEF FPC} {$IFDEF UNIX} nowDt:=NOW; Result := TTimeZone.Local.ToUniversalTime(nowDt)-nowDt; {$ELSE} ... So it's fine for iOS and Android. For Android/FireOS there seems an additional issue with Delphi 10.3.3.

For me it's fine to compare with UTC time but the documentation of TIdTime says "DateTime is expressed in the timezone for the local computer". And for Windows it's matching the documentation and for Android/iOS it's not matching the documentation. That's the point. In my case I need to know the difference between the local timestamp and the server timestamp. That's the reason to use TIdTime. On Windows it's working fine, if the local time of computer A is 90 seconds ahead and of computer B it's 10 behind, I know that both computer's have a difference of 100 seconds and I have to keep this in mind for all synchronizations between both computers (it's a synchronization of video-play and it's should be insync with an accepted difference of +/-3 seconds. That's working as expected with my routine.

In this case I'm developing software for end consumer, so it's no solution if I have to use additional hardware or if I restrict the software to Sierra.

I can confirm, with Delphi 10.3.1 and MacOS Sierra (-> Xcode 9.2) the BLE implementation is up and running. So I don't have to use the old Delphi Version but have the problem that my clients have to use Sierra also (-> no use case for me).

I was able to use Delphi+BLE only in combination with MacOSX Sierra (or older) but not with High Sierra or Mojave -> this means it's not useable in my use case. If you know how I can use Delphi+BLE also with Mojave I'm extremly interested.

The next step is to downgrade my second MacBookAir to Sierra. But then I can use it internally but can't delivery it to end Consumer as I can't specify the OS-Version to use.

My software runs with all OS (Win32/Win64/MacOS/iOS/Android/Linux [fmxlinux]) but with MacOS the Delphi-BLE-implementation is not useable. P.S.: With Linux BLE is also not useable but there isn't any BLE implementation until now, under MacOS is an error in the existing BLE implementation.

I have now Delphi Berlin 10.1.2 installed, PA Server 18.0 and Xcode 9.4.1 but get still the exception "BluetoothDevice is not found or disconnected" if I request "TBluetoothLEManager.startDiscovery" after I have set TBluetoothLE.enabled:=true successfully. Any other tip?

Ok, to increase the Chance I vote for the following issues: https://quality.embarcadero.com/browse/RSP-21029 https://quality.embarcadero.com/browse/RSP-22905

Hi, is there any solution for this issue in meantime? I use a MacBookAir 2018 with Mojave and XCode 10.1 with Delphi 10.3.1 and get the same error message if I want to use Bluetooth-LE on my MacBook Air. Best regards, Philipp