What about the minimum version of Android?

[aldenml]

What about the minimum version of Android?

[master255]

@aldenml Thank you so much! +1000 points in karma 👍

I will test this library on my project later. If any questions arise that I cannot solve, I will write to you.

[arvidn]

surely 32bit android supports larges files, right?
libtorrent 2.0 uses fseeko() which takes an off_t for the offset. This type is supposed to be at least 64 bits, even on 32 bit systems.

Does android need fseeko64() instead?
If so, what is a good macro to detect this case?

[aldenml]

@arvidn is absolutely right :), and btw my plan is to look at this "non-trivial" issue probably during the weekend.

[aldenml]

Hi @master255, I finally added a more robust solution to build android binaries locally. It uses docker, see https://github.com/aldenml/libtorrent4j#android-local-builds

I created a new branch test-19 (https://github.com/aldenml/libtorrent4j/tree/test-19) with your changes (on both libtorrent4j (7f706ed) and my libtorrent fork (aldenml/libtorrent@b9f0a8b).

Just in case, to correctly clone:

git clone https://github.com/aldenml/libtorrent4j.git
git checkout test-19
git submodule update --init --recursive

I'm also attaching the arm 32bits jars, since I needed to build to test anyway (in case you just want to drop the jars and test): arm-jars.zip

[gubatron]

Excellent solution, I was thinking of doing this for jlibtorrent, but eventually I managed to finally build everything on my end locally (on a powerful AWS instance with an older kernel to avoid issues with Linux distros that are more conservative upgrading their libc6 libraries, like Linux Mint).

There was really nothing wrong with the build scripts after all, simply a matter of build environment.

I think I'll still adopt the docker solution so that it's portable and deterministic.

[aldenml]

yes, you should be able to change, compile and build yourself.

[gubatron]

docker gives you certainty it will build.

our local build scripts (jlibtorrent) work on some machines and not on others without changing anything on the scripts.

The idea is having a portable environment where it will always build.

[master255]

@aldenml I'm talking about this bug arvidn/libtorrent#4338

[aldenml]

I'm open to exploring the creation of a build with API-19, maybe with a different artifact. Out of curiosity, is your user base with API-19 a significant amount?

[master255]

@aldenml No. There are few users with Android 4.4, but they are about 4%. And I have a Galaxy S3 test phone (which has outstanding specs: support wifi 5G, has a 4x core processor and NFC technology) that runs on Android 4.4.

Other than that, one line of code is not a reason to raise the minimum api version. It's not professional.

[master255]

@aldenml Ha ha. We still have these phones on sale. Just found it...didn't know about it.
https://www.e-katalog.ru/SAMSUNG-GALAXY-S3-16GB.htm

[master255]

@aldenml And jlibtorrent-1.2.10.0 supported Android 4.4. I just checked it. But jlibtorrent-1.2.12.0 doesn't.
The problem is in the compilation scripts.

[master255]

@aldenml I found the problem!
The thing is that the toolchain for the 21 api is being used. And we need to use toolchain for 19 api. And then these commands will work:
# hacks to remove when API >= 21
"-D"epoll_create1(x)=-1; errno=ENOSYS"
"-D"posix_fadvise(x1,x2,x3,x4)""

Fix this. Tell me how to do a release version with your script and we'll move to torrents 2.0.

[aldenml]

OK, doing some experiments with API 19. Btw, keep in mind that there are some non-trivial API differences between libtorrent4j and jlibtorrent since we track different libtorrent branches.

I will let you know the results.

[master255]

@aldenml I don't use much frost wire code. Almost everywhere I have a direct call to the library.
I am waiting for your results. Maybe this will help you:
frostwire/frostwire-jlibtorrent#250 (comment)

[aldenml]

@master255 this is what I have so far:

• With some tricks, I can build the arm and x86 for android api-19. See the branch https://github.com/aldenml/libtorrent4j/tree/android-19, you can download the binaries artifacts here https://github.com/aldenml/libtorrent4j/runs/1758351202.
• The problem is more than just the lack of posix_fadvise. The new libtorrent >= 2.x uses the posix call fseeko, and with "large files" support this only becomes available with API >= 24. Still, it could be present at runtime with the device's own bionic. You need to test multiple devices (with API 19) to see how likely the success rate is.
• As pure extra information, Android KitKat (and below) is full of corner cases when it comes to large files (i.e. > 4GB). See: https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md#using-with-early-api-levels, https://android-developers.googleblog.com/2017/09/introducing-android-native-development.html and https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md.

I tried to run emulators with API-19, but for some reason, they don't work anymore on my PC. If you are willing to try with the binaries, I can take a look at the log if you have some errors.

I mentioned the difference between libtorrent4j and jlibtorrent (api wise) because they are not 100% compatible (even to the swig layer). I recommend you to try changing the dependency to libtorrent4j in your build script and see if it even compiles, then see if you are comfortable with the number of necessary changes.

Hope this helps.

[gubatron]

I think we'll be dropping Kit Kat 4.4 (android api 19) support as of our next build.
Stats for 2002 put Kit Kat at 4.4% of the market share (statista) and 4.2% for FrostWire's userbase.
At these points those users are having more problems than most and leaving negative reviews.

[gubatron]

I've been battling this issue when building 32-bit for arm at link time:

requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC

and this error for x86 (32bit) also at link time

relocation R_386_GOTOFF against preemptible symbol _ZN5boost4asio6detail10call_stackINS1_14thread_contextENS1_16thread_info_baseEE4top_E cannot be used when making a shared object

My android-arm-config.jam has as the first option -fPIC, and the 64-bit versions for android build and link just fine.

I'm building on a 64-bit Linux machine, I wonder if this has anything to do with that.

At this point I'm willing to run a 32bit virtual machine, or just skip altogether local builds and port the build scripts to github actions. Perhaps it's faster trying the 32bit vm.

import os ;

ANDROID_TOOLCHAIN = [ os.environ ANDROID_TOOLCHAIN ] ;
ANDROID_API = [ os.environ android_api ] ;

using clang-linux : arm : $(ANDROID_TOOLCHAIN)/bin/armv7a-linux-androideabi$(ANDROID_API)-clang++
    <cxxflags>-fPIC
    <cxxflags>-march=armv7-a
    <cxxflags>-mfpu=neon
    <cxxflags>-std=c++14
    <cxxflags>-DANDROID
    <cxxflags>-D__STDC_FORMAT_MACROS
    <cxxflags>-D_FILE_OFFSET_BITS=64
    <cxxflags>-frtti
    <cxxflags>-fno-strict-aliasing
    <cxxflags>-fvisibility=hidden
    <linkflags>-static-libstdc++
    <linkflags>-fuse-ld=bfd
    # debug information
    <cxxflags>-g
    <cxxflags>-gdwarf-4
    <cxxflags>-fdebug-macro
    <cxxflags>-ggdb
    ;

[gubatron]

Thanks @master255 I was missing the ":" at the end of
using clang-linux : arm : $(ANDROID_TOOLCHAIN)/bin/armv7a-linux-androideabi$(ANDROID_API)-clang++
like you mentioned on the jlibtorrent issue tracker.

This made the arm 32-bit finally built!

The windows build is still broken (even after adding the also missing ":" to that .jam file)

[master255]

@aldenml I tested it. And this is what I got:

1. The 1.2 version of the library works well on my Galaxy S3. Even with files over 4 gigabytes.
2. Your script does not compile arm 32 version of the library. The error is in the attached file.
   
3. I still don't understand how to get a release version of your library. Maybe I need to use some similar script? https://github.com/frostwire/frostwire-jlibtorrent/blob/master/swig/package-remote-build.sh
4. In order to test your library I need to modify it for streaming (and other features) and compile it myself.
   Your usual version of the library will not work for me exactly. How can I do that?

[master255]

@aldenml
2. Okay. I repeated the fork and the compilation was successful.

Answer the other questions.

[aldenml]

@master255

1- Good to know you have a device with no issues
2- OK
3- I haven't figure out a way to download the binaries with a script, but you can do it manually if you build them using GitHub Actions.

4- How do you it right now using jlibtorrent? If you are using some sort of script for the local build, I imagine I can take a look and adapt it for libtorrent4j.

[master255]

@aldenml
Perhaps we need to develop scripts to compile on the local computer? So as not to download 300 megabytes and not to wait so long to compile after changing one line of code.
As it is done in https://github.com/frostwire/frostwire-jlibtorrent

Yes. I am currently compiling Jlibtorrent on my local computer. The resulting jar files are 2.5 Megabytes in size.
This is as quick and easy as possible for me.
I have a very powerful computer and I can control the compilation process.
This post contains my swig directory with which I was able to compile the latest version 1.2.12 of libtorrent.

I am using Windows 10 Compact and as a Windows component Ubuntu 20.04 LTS.

I tried to change the libtorrent branch to 2.0, but errors appeared. So far I don't know how to fix them. If you can help with these scripts, it will help us to switch to 2.0 version.

[aldenml]

OK, I will take a look at the scripts and report back

[gubatron]

Beware of local compilation when distributing binaries.

Our last build for Linux for instance was built in my shiny new Ubuntu kernel, and now I have users complaining that they don't have the latest libc :p

Make sure to build on older kernels whatever you build to maximize binary compatibility. #LessonsLearned.

[gubatron]

(And I still cannot build jlibtorrent for 32bit x86 android, can't link the damn thing)

[master255]

@gubatron

(And I still cannot build jlibtorrent for 32bit x86 android, can't link the damn thing)

What's your error?

[aldenml]

Hi @master255, copying from jlibtorrent, I created a script for the local build of arm 32bits. I don't want to go further until you are able to test at least with that architecture.

You need to checkout the branch android-19 (https://github.com/aldenml/libtorrent4j/tree/android-19). Inside the folder swig/scripts-b2 (https://github.com/aldenml/libtorrent4j/tree/android-19/swig/scripts-b2) you will find the very familiar script build-android-arm.sh. Give it a try and let me know.

[master255]

@aldenml ok

[master255]

@aldenml I tested with different settings.
These errors occur all the time. Can you help fix them?
errors.txt

You forgot these lines:
# hacks to remove when API >= 21
"-D"epoll_create1(x)=-1; errno=ENOSYS"
"-D"posix_fadvise(x1,x2,x3,x4)""

[aldenml]

I see, go to the line https://github.com/aldenml/libtorrent4j/blob/android-19/swig/scripts-b2/build-android-arm.sh#L20

# NOTE: for Linux, remove "", for macOS, set: sed -i "" <expr>
sed -i "" 's/24/19/g' ${ANDROID_TOOLCHAIN}/sysroot/usr/include/ifaddrs.h
sed -i "" 's/24/19/g' ${ANDROID_TOOLCHAIN}/sysroot/usr/include/stdio.h
sed -i "" 's/28/19/g' ${ANDROID_TOOLCHAIN}/sysroot/usr/include/sys/random.h
sed -i "" 's/POSIX_FADV_RANDOM 1/POSIX_FADV_RANDOM_NOOP 0/g' ${ANDROID_TOOLCHAIN}/sysroot/usr/include/linux/fadvise.h
sed -i "" 's/RANLIB = ranlib/RANLIB = "${ANDROID_TOOLCHAIN}\/bin\/arm-linux-androideabi-ranlib"/g' ${BOOST_ROOT}/tools/build/src/tools/gcc.jam

remove the """ from each sed line. With those changes there is no need to mock epoll_create1 and posix_fadvise.

[master255]

@aldenml Yes. It's finally working! But at the end there was some problem with the compilation gradle.
success.txt

[aldenml]

Can you type gradle tasks inside the folder libtorrent4j1 to see what happens?

[master255]

@aldenml

[aldenml]

Try ./gradlew tasks please. I'm trying to figure out if it's a gradle incompatibility on your system, since I'm using the Kotlin DSL.

[master255]

@aldenml After the command ./gradlew tasks
The installation of gradle is started.
But compiling the library still gives the same errors.
log.txt

[master255]

again

[aldenml]

I think I know what it is. Your system gradle does not support the Kotlin DSL, you need to use the wrapper (./gradlew). I can modify the script, but it's just a simple change:

In these lines https://github.com/aldenml/libtorrent4j/blob/android-19/swig/scripts-b2/build-utils.shinc#L329

gradle clean
gradle build
# android Arm
gradle nativeAndroidArmJar

put

./gradlew clean
./gradlew build
# android Arm
./gradlew nativeAndroidArmJar

[master255]

@aldenml Yes. You're right. Now everything compiled.
But why is the library so big?
It was 2 megabytes bigger.

[aldenml]

@master255 good to know you are finally able to compile.

The first reason it is bigger is because libtorrent4j tracks the libtorrent's master branch, which includes WebTorrent. For that to work, I compile openssl with almost all the features enabled. The second reason is that I'm using -O3 instead of -Os.

[master255]

@aldenml What is this "I'm using -O3 instead of -Os"? Explain in simple words?

I compile openssl with almost all the features enabled

What are the advantages?

[aldenml]

When I compile all the c++ source code, I pass the flag -O3 to the compiler, which optimizes for speed at the cost of bigger binaries. jlibtorrent uses -Os instead, which optimizes for binary size instead.

The reason I enable almost all features in openssl, is because WebTorrent uses a lot of protocols and algorithms while negotiating with web peers. For me to discover which one I can disable, will take me a long long time.

[gubatron]

my error, only for android x86 32bit
relocation R_386_GOTOFF against preemptible symbol

/home/gubatron/src/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin/ld: error: bin/release/android/x86/libtorrent.a(gzip.o): relocation R_386_GOTOFF against preemptible symbol _ZN5boost6system6detail10cat_holderIvE24system_category_instanceE cannot be used when making a shared object
/home/gubatron/src/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin/ld: warning: shared library text segment is not shareable

thinking of building on older linux

[aldenml]

@gubatron, are you sure that when you compile the boost_system library, isn't the linux gcc in the path taking precedence over the one in the android toolchain?

[master255]

@aldenml Okay. I was able to add my changes and compile it. Even runswig worked successfully.
While I'm redoing the whole application, I need compile scripts for all platforms.
Can you help with these scripts?
Android only

[master255]

@aldenml It is very strange that the data types are different here. That's why I'm having problems.

I found a problem. You need to change the type of the variable. Is this possible?

std::vector<int> get_file_priorities_ex() const
{
    std::vector<libtorrent::download_priority_t> v = $self->get_file_priorities();
    std::vector<int> r(v.size());
    for (std::size_t i = 0; i < v.size(); i++)
        r[i] = int(static_cast<std::uint8_t>(v[i]));
    return r;
}

and:

public Priority[] filePriorities() {
        int_vector v = h.get_file_priorities_ex();
        int size = v.size();
        Priority[] arr = new Priority[size];
        for (int i = 0; i < size; i++) {
            arr[i] = Priority.fromSwig(v.get(i));
        }
        return arr;
    }

in TorrentHandle.java

[aldenml]

@master255 good catch, I will fix that and merge back to theandroid-19 branch. As for the scripts, yes, I can help, but I rather wait until you confirm arm is working in a real device.

[master255]

@aldenml I finished fixing the application. There are no errors.
But here is an error when starting the application:

2-04 03:58:38.674 24242-24242 E/dalvikvm: dlopen("/data/app-lib/com.media.library-15/libtorrent4j.so") failed: dlopen failed: cannot locate symbol "fseeko64" referenced by "libtorrent4j.so"...
02-04 03:58:38.679 24242-24242 W/dalvikvm: Exception Ljava/lang/LinkageError; thrown while initializing Lorg/libtorrent4j/swig/libtorrent_jni;
02-04 03:58:38.679 24242-24242 W/dalvikvm: Exception Ljava/lang/LinkageError; thrown while initializing Lorg/libtorrent4j/swig/settings_pack;
02-04 03:58:38.679 24242-24242 D/AndroidRuntime: Shutting down VM
02-04 03:58:38.684 24242-24242 W/dalvikvm: threadid=1: thread exiting with uncaught exception (group=0x41e95c08)
02-04 03:58:39.204 24242-24287 V/FA: Connection attempt already in progress
02-04 03:58:39.299 24242-24242 E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.media.library, PID: 24242
java.lang.LinkageError: Look for your architecture binary instructions at: https://github.com/aldenml/libtorrent4j
at org.libtorrent4j.swig.libtorrent_jni.(libtorrent_jni.java:28)
at org.libtorrent4j.swig.settings_pack.(settings_pack.java:475)

it's real galaxy s3

[aldenml]

That was what I was afraid of from the very beginning, the lack of fseeko64 at runtime. Now I see two options:
1- You drop "temporarily" support for API-19, I help you with the scripts and later I see how I can avoid that call in libtorrent (might never happen)
2- You don't integrate with libtorrent4j until I figure out a way to modify libtorrent (with no ETA).

[master255]

@aldenml Bad news.
I tried turning on the player on my Sony Bravia Android TV 8 32-bit and got an error:
2021-02-04 04:24:51.273 10253-10342 D/222222: FILE_ERROR
2021-02-04 04:24:51.273 10253-10342 D/222222: Avatar.2009.Extended.UHD.Re-Grade.4000nit.2160p.HEVC.HDR.IVA(RUS.UKR.ENG).ExKinoRay.mkv file_seek (/storage/emulated/0/MediaLibrary/Avatar.2009 Extended.UHD.Re-Grade.4000nit.2160p.HEVC.HDR.IVA(RUS.UKR.ENG).ExKinoRay.mkv-ml) error: Value too large for defined data type

If it does not work on TV, no one will use it.
All Android TVs have 32 bits only.

[aldenml]

Sounds to me like the file is too big and you are facing those documented posix related large files issues. Don't you want to try compiling with API-21?

[master255]

@aldenml Okay, I will try to compile with 21. With version 1.2 this file downloads fine.

[master255]

@aldenml how to do this?

[aldenml]

I haven't tested yet, but changing this line https://github.com/aldenml/libtorrent4j/blob/android-19/swig/scripts-b2/build-android-arm.sh#L11 to 21 should be enough. Remember to fix the sed lines.

[master255]

@aldenml Exactly the same:
2021-02-04 04:51:18.755 11133-11225 D/222222: FILE_ERROR
2021-02-04 04:51:18.755 11133-11225 D/222222: Avatar.2009.Extended.UHD.Re-Grade.4000nit.2160p.HEVC.HDR.IVA(RUS.UKR.ENG).ExKinoRay.mkv file_seek (/storage/emulated/0/MediaLibrary/Avatar.2009.Extended.UHD.Re-Grade.4000nit.2160p.HEVC.HDR.IVA(RUS.UKR.ENG).ExKinoRay.mkv-ml) error: Value too large for defined data type
2021-02-04 04:51:18.755 11133-11225 D/222222: TORRENT_ERROR

Libtorrent 2.0 does not work on Android TV. We should tell Arvin about it.

[aldenml]

well, this is very odd then, will try to replicate it on my end

[master255]

@aldenml The size of the Avatar is about 100GB... Check large files.

[aldenml]

wow, no way I can test this on any of my devices :(

What about smaller files? does it work?

[master255]

@aldenml 2.5 Gb is the same problem.

[aldenml]

@master255 that's not right, give me some time to test on my end

[gubatron]

(meanwhile when building locally for android x86 32bit)

will check what happens right before the boost_system compilation.
It's very strange that every other platform builds and links just fine.

Maybe you're onto something, I'll leave a trail of what I did here in case others have the same or a similar issue in the future.

Building Boost.Build engine with toolset gcc... 
Failed to build Boost.Build build engine
Consult 'bootstrap.log' for more details

The bootstrap.log had the following messages

A C++11 capable compiler is required for building the B2 engine.
Toolset 'gcc' does not appear to support C++11.

** Note, the C++11 capable compiler is _only_ required for building the B2
** engine. The B2 build system allows for using any C++ level and any other
** supported language and resource in your projects.


You can specify the toolset as the argument, i.e.:
    ./build.sh gcc

Toolsets supported by this script are:
    acc, clang, como, gcc, intel-darwin, intel-linux, kcc, kylix, mipspro,
    pathscale, pgi, qcc, sun, sunpro, tru64cxx, vacpp

For any toolset you can override the path to the compiler with the CXX
environment variable. You can also use additional flags for the compiler
with the CXXFLAGS environment variable.

A special toolset; cxx, is available which is used as a fallback when a more
specific toolset is not found and the cxx command is detected. The 'cxx'
toolset will use the CXX, CXXFLAGS, and LIBS environment variables, if present.

Similarly, the cross-cxx toolset is available for cross-compiling by using the
BUILD_CXX, BUILD_CXXFLAGS, and BUILD_LDFLAGS environment variables to compile
binaries that will be executed on the build system. This allows CXX etc. to be
set for cross-compilers to be propagated to subprocesses.

[aldenml]

@gubatron attach the whole script output and I will read it, sounds to me like a couple of characters issue :)

[arvidn]

This issue android/ndk#563 suggests that fseeko() on Android does support 64 bit offsets when _FILE_OFFSET_BITS=64, which libtorrent defines in the Jamfile and CMakeLists.txt

[master255]

@arvidn

surely 32bit android supports larges files, right?

Yes. I regularly watch 50GB and 100GB movies. With version 1.2.

Does android need fseeko64() instead?
If so, what is a good macro to detect this case?

I'm not sure. Version 1.2 works with fseek. Don't forget. Version 1.2.12 is fully compatible and works on all android devices.

[arvidn]

Don't forget.

I won't forget :)

[master255]

@arvidn

This issue android/ndk#563 suggests that fseeko() on Android does support 64 bit offsets when _FILE_OFFSET_BITS=64, which libtorrent defines in the Jamfile and CMakeLists.txt

I tried to compile without:
-D__USE_FILE_OFFSET64
The error is repeated.

I tried to compile without:
-D__USE_FILE_OFFSET64
-D_FILE_OFFSET_BITS=64
The error is repeated.

I replaced all fseeko with fseeko64.
The error is repeated.

What should I do to make the error gone?

[arvidn]

you could try sepping into the call to fseeko64() in a debugger, and see what happens to the offset. It might be a good idea to write a small test program just to reproduce this though.

[master255]

Okay. I'll wait.

[gubatron]

(Holly shit this escalated, Arvid is here! Hi Arvid! 🥰 )

[master255]

@aldenml We are all waiting for you. Only you can save Libtorrent 2.0.

[arvidn]

I think there are more competent engineers in the world than that estimate

[master255]

@arvidn Okay. You can delegate this issue to other engineers. When they find a solution to the problem, post in this thread how to fix the bug. I will fix it and test it.
Let's work in parallel.

@gubatron The question became more important. Can Libtorrent 2.0 support Android 32-bit at all.

[aldenml]

Hi @master255, I was able to test quite a bit with arm 32 bits. It works fine on my device up to 50GB (I don't have more free space). I think what happened with your latest try using API 21, was that you had a stale build. I needed to comment a sed line (46c28dd#diff-e9d761c8e61f8145e68eaec70bd20a6ba56f100d95178034949f24978f5ced89R24) to get it right with API 21.

I will help you with the API 19, but can you try one more time with API-21? This time please, clean the scripts-b2/src/ folder, and git pull to get the latest changes.

[master255]

@aldenml ok

[master255]

@aldenml Exactly the same bug.
I made a Pull for libtorrent4j.
I made a Pull for libtorrent.
And fixed my whole application for byte_vector to prioritize files.
I noticed one oddity:
In frostwire, the normal file priority is "1"
but in libtorrent4j the normal priority is "4".
I use priority 1 in my application. I don't think this had any effect on the bug, but priorities have their own meaning. Maybe you need to revise the default priority?

Bug Log:
2021-02-06 15:56:45.615 28047-28149 D/222222: FILE_ERROR
2021-02-06 15:56:45.615 28047-28149 D/222222: Vikings.S06E16.1080p.rus.LostFilm.TV.mkv file_seek (/storage/emulated/0/MediaLibrary/Vikings.S06E16.1080p.rus.LostFilm.TV.mkv-ml) error: Value too large for defined data type
2021-02-06 15:56:45.615 28047-28149 D/222222: TORRENT_ERROR
2021-02-06 15:56:45.615 28047-28149 D/222222: Vikings.S06E16.1080p.rus.LostFilm.TV.mkv ERROR: (75 Value too large for defined data type) /storage/emulated/0/MediaLibrary/Vikings.S06E16.1080p.rus.LostFilm.TV.mkv-ml
2021-02-06 15:56:45.713 28047-28149 D/222222: TORRENT_PAUSED

Maybe you have a telegram and we could resolve this issue quicker?

[master255]

@aldenml Right now I'm trying to reset libtorrent to the last commit in the master branch and test it.

[arvidn]

@master255 if you don't want to step into the failing call in a debugger, you could try running it under strace (ideally with a filter to only include file operations). That might also give you a hint of what syscall is being made and with what arguments.

[master255]

@arvidn Ok. I think Aldenml knows what strace is and if it is available for Android TV.
I am in the process of compiling the last commit. As I see there are a lot of changes.

[master255]

@aldenml I tried to compile the last libtorrent commit and got a lot of errors.
errors.txt

[master255]

@arvidn What will the information about the line, which is an error, give us?
Obviously, the error is in some line of fseeko.
The error comes from passing a 64 bit number, when fseeko can only accept a 32 bit number.

The question is not what kind of error it is or what line it is in. The question is: how to fix it?
I think the problem is in the compilation parameters.

[aldenml]

@master255 I already fixed the priority issue, make sure you are working on top of the HEAD of the branch android-19. I already fixed the priority int inconsistency (now it's byte everywhere).

[master255]

@aldenml Read my posts from this one. More carefully.

Everything has already been tested in different ways and does not work.
I found a new problem with priorities. You didn't fix it.

[aldenml]

@master255 about the default priority, that probably wasn't updated in jlibtorrent when it was changed to types in libtorrent/RC_1_2. The values are correct here in libtorrent4j.

Your latest compilation error is because you are touching the swig layer, avoid that, I tested back to back the compilation from scratch multiple times yesterday. I know this process can be frustrating, local compilation is very tricky.

[master255]

@aldenml I have many changes to libtorrent without which I cannot use the library. I definitely need to regenerate swig.
But I checked there nothing changed compared to your version (except my changes).
In other words, it could not cause a bug.
What are your suggestions? What to do?

[aldenml]

@master255 if you can open source your custom libtorrent(only) changes (and I totally understand if you can't), I could work with that fork to ensure a smooth ride compilation.

[master255]

@aldenml I think you need a messenger for that. Like telegram or something else. My telegram https://t.me/Master255

[aldenml]

@master255 I applied a fix (https://github.com/aldenml/libtorrent4j/pull/159/files) that should help with the API-19 compatibility. Still, this doesn't explain the problem you are having. Just to confirm: In this very same device, when you test with jlibtorrent, you don't have any problem, correct?

[master255]

@aldenml

Just to confirm: In this very same device, when you test with jlibtorrent, you don't have any problem, correct?

I don't understand you. What device? What problems aren't there? What do I need to confirm?

[aldenml]

This error:

Bug Log:
2021-02-06 15:56:45.615 28047-28149 D/222222: FILE_ERROR
2021-02-06 15:56:45.615 28047-28149 D/222222: Vikings.S06E16.1080p.rus.LostFilm.TV.mkv file_seek (/storage/emulated/0/MediaLibrary/Vikings.S06E16.1080p.rus.LostFilm.TV.mkv-ml) error: Value too large for defined data type
2021-02-06 15:56:45.615 28047-28149 D/222222: TORRENT_ERROR
2021-02-06 15:56:45.615 28047-28149 D/222222: Vikings.S06E16.1080p.rus.LostFilm.TV.mkv ERROR: (75 Value too large for defined data type) /storage/emulated/0/MediaLibrary/Vikings.S06E16.1080p.rus.LostFilm.TV.mkv-ml
2021-02-06 15:56:45.713 28047-28149 D/222222: TORRENT_PAUSED

I recall you told me it was an Android 8 (TV). I want to make sure this doesn't happen with jlibtorrent.

[master255]

@aldenml Sorry. I didn't pay attention to the name of the library.
Yes, of course with Jlibtorrent version 1.2.12 there is no problem at all on any device.

[aldenml]

Good, I will let you know when It's ready to test again.

[master255]

@aldenml Ok. I need some time for testing. Now I am in the process of developing torrent storage.
Will I be able to compile the project myself?
I will need to make changes to it.

[master255]

@aldenml Good news. I finished the torrent storage and now I have time to test and help you.
The bad news. The library you attached gives the exact same error:

2021-02-22 16:13:38.328 13116-13205 D/222222: FILE_ERROR
2021-02-22 16:13:38.328 13116-13205 D/222222: Walker.S01E05.1080p.rus.LostFilm.TV.mkv file_seek (/storage/emulated/0/MediaLibrary/Walker.S01E05.1080p.rus.LostFilm.TV.mkv-ml) error: Value too large for defined data type
2021-02-22 16:13:38.328 13116-13205 D/222222: TORRENT_ERROR
2021-02-22 16:13:38.328 13116-13205 D/222222: Walker.S01E05.1080p.rus.LostFilm.TV.mkv ERROR: (75 Value too large for defined data type) /storage/emulated/0/MediaLibrary/Walker.S01E05.1080p.rus.LostFilm.TV.mkv-ml

should I try to compile it myself? And test it again?

[master255]

@aldenml And I installed docker.io in Ubuntu. But I get an error:

 ./build-arm.sh
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
See 'docker run --help'.

Commands like: sudo service docker restart
don't help and don't work.
So I can't compile by myself using docker. Maybe I need to configure something?

[aldenml]

Hi @master255 glad to hear you finished your storage-related work, I will ping you on Telegram to continue troubleshooting.

About docker, that's a very standard piece of software, I google around and found two links that maybe can help you.

https://phoenixnap.com/kb/cannot-connect-to-the-docker-daemon-error
https://phoenixnap.com/kb/install-docker-on-ubuntu-20-04

[master255]

@aldenml Your instructions for a pure Ubuntu system. Not for Windows 10 Ubuntu. I found some docker desktop for windows, but for him to work it needs to reinstall Windows and enable the spyware from Microsoft. Why do we need to use docker? In the past we used the sh script and everything worked fine.

[aldenml]

@gubatron is absolutely right

[master255]

@gubatron But if docker cannot be run on a normal computer, how will all the programmers use it?
On any windows 10 computer it is easy to install ubuntu 20.04 and run the sh script, but installing docker is a big problem. For example I need to completely reinstall the operating system (Windows 10. It takes me a month of time). The docker requires high version requirements for the operating system and hardware. And as a result it might not work for some unknown reason and nobody can help me to solve this problem unlike the sh script.

I think our progress is not yet to the point of using docker.

@aldenml I will think, as everyone else thinks, that there is no point in upgrading to torrents 2.0 unless you fix the overflow int error.
I thought you already found the problem? But the error has repeated again. Perhaps you need help from Arvid?

[aldenml]

@master255 yes, more likely I will need Arvid help.

One question: I see that you are saving to the path /storage/emulated/0/MediaLibrary/. Can you provide the filesystem used in this particular path? (ext3, extFAT, FAT32)

[master255]

@aldenml It's Ext4