We have integrated in our app the Connect SDK ver. "com.connectsdk:connect-sdk-android:1.6.0"
This is using the following discovery providers when the scan is started for Cast devices:
With our original implementation, the LG SDK cast services scan was started at app start an was running in background, in order to make the cast icon appear dynamically when a service is found (similar somehow to what Chromecast SDK does).
The problem with this approach is that LG SDK scan(discovery) will cause excessive device heating and app freeze when the app is running for a while (like 30 min or more). Also this can be a problem for battery drain.
Basically the discovery is doing excessive scan work/load (generates a lot of logs), especially when no cast services are found on a network. (this never happens when using only Chromecast SDK).
Chromecast SDK seems to manage scans in a more friendly way and only scans periodically without performance impact. In contrast the LG SDK seems to scan all the time or at very short periods.
1.1) Expected behavior:
LG SDK scan logic should be able to scan for device in background without generating excessive device heating and app freeze (load). Scan for devices only at reasonable periods of time.
1.2) Temp workaround done on our side until above issue is fixed:
Currently we are forced to start the LG SDK scan only when the "CastRouteChooserDialog" is opened (via cast icon), in order to present the found services, and stop the scan when the "CastRouteChooserDialog" is closed, this is to reduce as much as possible overall run time for LG SDK scan.
1.3) Exceptions:
The exception for (1.2) is FireTVService, for which we are forced to keep the scan ON while connected to an Amazon cast device, limitation imposed by Amazon’s Fling SDK way of working.
In this case we only close the overall scan after we have a fail/disconnect from the connected Amazon cast device.
This behavior is the source for the second issue found for FireTVDiscoveryProvider.
In the current version of LG SDK, when the we call stop() method on "DiscoveryManager", it stops all
discovery providers (as expected).
The problem is that "FireTVDiscoveryProvider" does something extra that should NOT DO - in it's STOP method it also triggers a device disconnect in addition to stopping the provider scan. No other discovery provider does this.
2.1) Expected behavior:
Discovery Provider scan state should never interfere with the service connection state, even in the exceptional case (1.3) when we depend on scan to be ON for Amazon devices. If scan is off during Amazon cast, session should fail in a friendly way.
LG SDK should permit us to run (keep alive) only the Fire TV Discovery Provider while casting to amazon devices, without forcing us to keep other providers active.
Also instead of having the disconnect called in "FireTVDiscoveryProvider" stop method, LG SDK should only trigger the disconnect as a result of normal disconnect (manual etc) event.
2.2) Temp workaround done on our side until (1) or (2) are fixed:
We have a custom "FireTVDiscoveryProvider" for which we have removed the unwanted disconnect call.
Also we keep all scans active while we are connected to an amazon device.
When we receive a connection fail or disconnect (manual etc) event for an Amazon device, we stop the scans by calling the "DiscoveryManager" stop inside a dedicated "ConnectableDeviceListener" found in our "MediaRouteActionProvider".
If issue (1) can be fixed, we will no longer need to do the workarounds from issue (2).
Hi,
We have integrated in our app the Connect SDK ver. "com.connectsdk:connect-sdk-android:1.6.0" This is using the following discovery providers when the scan is started for Cast devices:
mDiscoveryManager.registerDeviceService(WebOSTVService.class, SSDPDiscoveryProvider.class); mDiscoveryManager.registerDeviceService(NetcastTVService.class, SSDPDiscoveryProvider.class); mDiscoveryManager.registerDeviceService(CustomDLNAService.class, SSDPDiscoveryProvider.class); mDiscoveryManager.registerDeviceService(DIALService.class, SSDPDiscoveryProvider.class); mDiscoveryManager.registerDeviceService(RokuService.class, SSDPDiscoveryProvider.class); mDiscoveryManager.registerDeviceService(AirPlayService.class, ZeroconfDiscoveryProvider.class); mDiscoveryManager.registerDeviceService(FireTVService.class, FireTVDiscoveryProvider.class);
1) PRIMARY Issue description - Service Discovery:
With our original implementation, the LG SDK cast services scan was started at app start an was running in background, in order to make the cast icon appear dynamically when a service is found (similar somehow to what Chromecast SDK does).
The problem with this approach is that LG SDK scan(discovery) will cause excessive device heating and app freeze when the app is running for a while (like 30 min or more). Also this can be a problem for battery drain.
Basically the discovery is doing excessive scan work/load (generates a lot of logs), especially when no cast services are found on a network. (this never happens when using only Chromecast SDK).
Chromecast SDK seems to manage scans in a more friendly way and only scans periodically without performance impact. In contrast the LG SDK seems to scan all the time or at very short periods.
1.1) Expected behavior: LG SDK scan logic should be able to scan for device in background without generating excessive device heating and app freeze (load). Scan for devices only at reasonable periods of time.
1.2) Temp workaround done on our side until above issue is fixed: Currently we are forced to start the LG SDK scan only when the "CastRouteChooserDialog" is opened (via cast icon), in order to present the found services, and stop the scan when the "CastRouteChooserDialog" is closed, this is to reduce as much as possible overall run time for LG SDK scan.
1.3) Exceptions: The exception for (1.2) is FireTVService, for which we are forced to keep the scan ON while connected to an Amazon cast device, limitation imposed by Amazon’s Fling SDK way of working. In this case we only close the overall scan after we have a fail/disconnect from the connected Amazon cast device.
This behavior is the source for the second issue found for FireTVDiscoveryProvider.
2) SECONDARY Issue description - Amazon FireTVService casting and "FireTVDiscoveryProvider" stop:
In the current version of LG SDK, when the we call stop() method on "DiscoveryManager", it stops all discovery providers (as expected).
The problem is that "FireTVDiscoveryProvider" does something extra that should NOT DO - in it's STOP method it also triggers a device disconnect in addition to stopping the provider scan. No other discovery provider does this.
2.1) Expected behavior: Discovery Provider scan state should never interfere with the service connection state, even in the exceptional case (1.3) when we depend on scan to be ON for Amazon devices. If scan is off during Amazon cast, session should fail in a friendly way. LG SDK should permit us to run (keep alive) only the Fire TV Discovery Provider while casting to amazon devices, without forcing us to keep other providers active.
Also instead of having the disconnect called in "FireTVDiscoveryProvider" stop method, LG SDK should only trigger the disconnect as a result of normal disconnect (manual etc) event.
2.2) Temp workaround done on our side until (1) or (2) are fixed: We have a custom "FireTVDiscoveryProvider" for which we have removed the unwanted disconnect call. Also we keep all scans active while we are connected to an amazon device. When we receive a connection fail or disconnect (manual etc) event for an Amazon device, we stop the scans by calling the "DiscoveryManager" stop inside a dedicated "ConnectableDeviceListener" found in our "MediaRouteActionProvider".
If issue (1) can be fixed, we will no longer need to do the workarounds from issue (2).
Regards