Binary does not execute in MIBOX4 android 9 device, Kodi 19

[lopezvg]

Binary not loading in a MIBOX4 device.log

The Kodi installation has strange paths, that maybe is the cause of the problem. See messages of Quasar launch with similar problems.

Besides the user claims that the Configuration menu is forcing to use IP 192.168.1.1

[i96751414]

Are you sure the add-on containing the binaries was installed (using the repo)?

[lopezvg]

The user says it does and the repo is installed.

Please see the torrest error at log line 305, but also see the following lines about the Quasar initialization, which follows similar procedure as Torrest, and you'll see problems there also.

[i96751414]

Line 305 should only be logged if the binary is not found inside the addon resources folder. Unfortunately the latest version of torrest does not print the expected path, so it will be hard to debug. If the user can test with the changes added in 418769897e4a491cf86266638fdca001360858c5 it would be great.

Anyway, I believe he won't be able to run Torrest in Kodi 19 without root permissions (due to Android SDK 29 changes).

[lopezvg]

If the user can test with the changes added in 4187698 it would be great. It is complicated to ask a user to do that...

Anyway, I believe he won't be able to run Torrest in Kodi 19 without root permissions (due to Android SDK 29 changes). Although the behavior is compatible with you comment, I thought the problem started with Android 10 + Kodi 19. If you see in the log line 5, it states: Running on Xiaomi MIBOX4 with Android 9.0.0 API level 28, kernel: Linux ARM 32-bit version 4.9.113

[i96751414]

I see your point.. But Kodi 19 was compiled targeting sdk 29. If you have a look at line 337 there is already a Permission Denied. (Not sure if related, though)

[lopezvg]

You are right, it points at to the SDK problem. I'll try to find the time tomorrow to sent you an email with a proposal for that problem

[i96751414]

In the meanwhile I have added support to Android rooted devices and I am doing some work to run torrest on an APK, however at the moment is just a proof of concept.

[i96751414]

Can the user test this one and provide the Debug log? It would be useful to understand if we need extra work to get the binary path. plugin.video.torrest-0.0.10-6-g6bb0bee.android_arm.zip

[lopezvg]

I have sent your request to the user. Lets wait...

[lopezvg]

This is the log from the user. I'm afraid it is full of errors. kodi.log

[lopezvg]

I have made some modification in Quasar's deamon.py to try better alternative binary paths and to log it properly. The attached log from the user shows that /data/data/org.xbmc.kodi/files/ is not accessible to copy the binary.

For unknown reasons, the installation path is not /data/, but /mnt/expand/586a4906-8623-4b44-b7f3-eb1800cde7c2/. I have seen this situation in the pass. See log lines 288-322 for Quasar resolution

I believe that Torrest should try first, instead of a hard coded /data/, xbmc.translatePath("special://xbmcbin/").replace('user/0', 'data').replace('cache/apk/assets', 'files'). If still inaccessible, then try xbmc.translatePath('special://xbmcbin/'.replace('cache/apk/assets', 'files')) LOG171527512.log

[i96751414]

Thanks. I will have a look during the weekend.

[i96751414]

Hi. I had a look at the logs, and unfortunately these are not debug. However, there are 2 entries which are from torrest:

2021-03-18 19:52:14.058 T:25737   ERROR <general>: DEBUG:root:Default android app dir '/data/data/org.xbmc.kodi' does not exist

2021-03-18 19:52:14.060 T:25737   ERROR <general>: DEBUG:root:Using android app dir '/mnt/expand/586a4906-8623-4b44-b7f3-eb1800cde7c2/user/0/org.xbmc.kodi/cache/apk/assets/'

The current implementation already uses special://xbmcbin/ as a fall back path.

I may be wrong, but since there are no errors regarding torrest daemon init, I believe the user has first installed the plugin without the daemon, which led to the "service_enable" setting to be disabled: https://github.com/i96751414/plugin.video.torrest/blob/ed7d2ca78ef1e6d92467adb057c22fcfdacc5c03/lib/service.py#L283-L286 Although now he is using the plugin with the daemon, since service_enable=false, the daemon is not started.

I'd suggest the user to enable the daemon again (in the addon settings) and send the debug logs.

[lopezvg]

I asked the user to activate all Torrest logs to DEBUG level. I hope he did. How can we know? Is this what you mean by debug?

Originally the user installed the Torrest addon from the repo, so all errors happening after are a consequence of the first reported problem. I assume the user has installed the curretn version of the addon using the link you provided. I'll tell the user to verify that the setting is on, but Torrest should set this setting on on every Kodi init to avoid this situation.

[i96751414]

When I say debug, I mean enabling Kodi debug: https://kodi.wiki/view/Settings/System/Logging#Debug

If the user installed the addon from the repo, then the setting should be enabled. Let's see what the user says.

Torrest only touches that setting when it is enabled and the installed addon doesn't have the binary (it also displays a message to let the user know the service was not started). After that, it's up to the user whether to enable or not the setting again.

[lopezvg]

I think this time it worked for the user LOG218567915.log

[i96751414]

Nice. So this was a problem related with installing the plugin without the binary at the very beginning after all? If so, I believe this issue can now be closed.