Comments (110)
@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.
from libtorrent4j.
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?
from libtorrent4j.
@arvidn is absolutely right :), and btw my plan is to look at this "non-trivial" issue probably during the weekend.
from libtorrent4j.
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
from libtorrent4j.
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.
from libtorrent4j.
yes, you should be able to change, compile and build yourself.
from libtorrent4j.
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.
from libtorrent4j.
@aldenml I'm talking about this bug arvidn/libtorrent#4338
from libtorrent4j.
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?
from libtorrent4j.
@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.
from libtorrent4j.
@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
from libtorrent4j.
@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.
from libtorrent4j.
@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.
from libtorrent4j.
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.
from libtorrent4j.
@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)
from libtorrent4j.
@master255 this is what I have so far:
- With some tricks, I can build the
arm
andx86
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 newlibtorrent >= 2.x
uses the posix callfseeko
, and with "large files" support this only becomes available with API >= 24. Still, it could be present at runtime with the device's ownbionic
. 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.
from libtorrent4j.
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.
from libtorrent4j.
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
;
from libtorrent4j.
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)
from libtorrent4j.
@aldenml I tested it. And this is what I got:
- The 1.2 version of the library works well on my Galaxy S3. Even with files over 4 gigabytes.
- Your script does not compile arm 32 version of the library. The error is in the attached file.
- 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
- 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?
from libtorrent4j.
@aldenml
2. Okay. I repeated the fork and the compilation was successful.
Answer the other questions.
from libtorrent4j.
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
.
from libtorrent4j.
@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.
from libtorrent4j.
OK, I will take a look at the scripts and report back
from libtorrent4j.
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.
from libtorrent4j.
(And I still cannot build jlibtorrent for 32bit x86 android, can't link the damn thing)
from libtorrent4j.
(And I still cannot build jlibtorrent for 32bit x86 android, can't link the damn thing)
What's your error?
from libtorrent4j.
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.
from libtorrent4j.
@aldenml ok
from libtorrent4j.
@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)""
from libtorrent4j.
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
.
from libtorrent4j.
@aldenml Yes. It's finally working! But at the end there was some problem with the compilation gradle.
success.txt
from libtorrent4j.
Can you type gradle tasks
inside the folder libtorrent4j1
to see what happens?
from libtorrent4j.
from libtorrent4j.
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.
from libtorrent4j.
@aldenml After the command ./gradlew tasks
The installation of gradle is started.
But compiling the library still gives the same errors.
log.txt
from libtorrent4j.
from libtorrent4j.
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
from libtorrent4j.
@aldenml Yes. You're right. Now everything compiled.
But why is the library so big?
It was 2 megabytes bigger.
from libtorrent4j.
@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
.
from libtorrent4j.
@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?
from libtorrent4j.
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.
from libtorrent4j.
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
from libtorrent4j.
@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?
from libtorrent4j.
@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
from libtorrent4j.
@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
from libtorrent4j.
@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.
from libtorrent4j.
@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
from libtorrent4j.
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).
from libtorrent4j.
@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.
from libtorrent4j.
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?
from libtorrent4j.
@aldenml Okay, I will try to compile with 21. With version 1.2 this file downloads fine.
from libtorrent4j.
@aldenml how to do this?
from libtorrent4j.
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.
from libtorrent4j.
@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.
from libtorrent4j.
well, this is very odd then, will try to replicate it on my end
from libtorrent4j.
@aldenml The size of the Avatar is about 100GB... Check large files.
from libtorrent4j.
wow, no way I can test this on any of my devices :(
What about smaller files? does it work?
from libtorrent4j.
@aldenml 2.5 Gb is the same problem.
from libtorrent4j.
@master255 that's not right, give me some time to test on my end
from libtorrent4j.
(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.
from libtorrent4j.
@gubatron attach the whole script output and I will read it, sounds to me like a couple of characters issue :)
from libtorrent4j.
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
from libtorrent4j.
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.
from libtorrent4j.
Don't forget.
I won't forget :)
from libtorrent4j.
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?
from libtorrent4j.
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.
from libtorrent4j.
Okay. I'll wait.
from libtorrent4j.
(Holly shit this escalated, Arvid is here! Hi Arvid! 🥰 )
from libtorrent4j.
@aldenml We are all waiting for you. Only you can save Libtorrent 2.0.
from libtorrent4j.
I think there are more competent engineers in the world than that estimate
from libtorrent4j.
@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.
from libtorrent4j.
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.
from libtorrent4j.
@aldenml ok
from libtorrent4j.
@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?
from libtorrent4j.
@aldenml Right now I'm trying to reset libtorrent to the last commit in the master branch and test it.
from libtorrent4j.
@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.
from libtorrent4j.
@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.
from libtorrent4j.
@aldenml I tried to compile the last libtorrent commit and got a lot of errors.
errors.txt
from libtorrent4j.
@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.
from libtorrent4j.
@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).
from libtorrent4j.
@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.
from libtorrent4j.
@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.
from libtorrent4j.
@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?
from libtorrent4j.
@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.
from libtorrent4j.
@aldenml I think you need a messenger for that. Like telegram or something else. My telegram https://t.me/Master255
from libtorrent4j.
@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?
from libtorrent4j.
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?
from libtorrent4j.
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
.
from libtorrent4j.
@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.
from libtorrent4j.
Good, I will let you know when It's ready to test again.
from libtorrent4j.
@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.
from libtorrent4j.
@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?
from libtorrent4j.
@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?
from libtorrent4j.
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
from libtorrent4j.
@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.
from libtorrent4j.
@gubatron is absolutely right
from libtorrent4j.
@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?
from libtorrent4j.
@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)
from libtorrent4j.
@aldenml It's Ext4
from libtorrent4j.
Related Issues (20)
- Does anyone has WebTorrent working? HOT 9
- Piece Priority behaves erratically HOT 1
- Support for Raspberry Pi HOT 5
- Support for BEP 53 - Select specific files indices for download. HOT 1
- java: package org.libtorrent4j does not exist HOT 2
- No libtorrent4j in java.library.path
- AddTorrentParams getTrackers() returns empty list
- [Android] Fatal Exception: java.lang.LinkageError
- Fetch v2 Magnet failed HOT 3
- Please migrate your websites to cloudflare-pages [FREE HOSTING] HOT 2
- Crash on docker alpine image HOT 1
- Support for Linux ARM64?
- Linking error : no torrent4j in java.library.path HOT 2
- How to create torrents from torrent info HOT 2
- How to get data from ReadPieceAlert
- build libtorrent4j.so failed
- Crashes on Mac OS
- Is project alive? HOT 2
- fetchMagnet(String uri, int timeout, File tempDir) method can't save the torrent file HOT 2
- Add an ability to set custom `disk_interface`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libtorrent4j.