[Android] SeekFast causes crash
1、SeekFast causes crash, log
FATAL EXCEPTION: main
Process: com.DefaultCompany.AVProTest, PID: 13025
java.lang.IllegalArgumentException
at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:40)
at androidx.media3.exoplayer.SeekParameters.
Which version of AVPro Video is this please?
3.0.3
Is it Vulkan or OpenGLES? Can you reproduce it in one of our demo scenes?
Exoplayer
OpenGLES
DemoScene :AVProVideo\Demos\Scenes\Demo_MediaPlayer.unity
change seek to seekfast
click TimeForwardButton
Can you send over a full logcat please?
@Ste-RH Attach the full log in this thread, as you asked me. FullLog.log
Are you able to provide the URL you are using @Aunter1992 ?
Are you able to provide the URL you are using @Aunter1992 ? I used avprovideo demo
Reproduced! There will be a fix for this in the next release (v3.0.5).
AVPro Video version 3.0.5 has been released. Please let us know if it has not fixed your issue.
It works for me
When I switch videos and use seekfast to reload the progress, if I do it multiple times, the application crashes.
07-05 11:34:04.026 9599 9599 I System.out: AVProVideo video state: buffering 07-05 11:34:04.028 9599 9599 I System.out: AVProVideo video state: ready | m_VideoState: 4 | m_bIsBuffering: true 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] JNI DETECTED ERROR IN APPLICATION: JNI CallStaticVoidMethodV called with pending exception java.lang.NullPointerException: Attempt to read from field 'int com.renderheads.AVPro.Video.Player_Base$VideoCommand._command' on a null object reference in method 'boolean com.renderheads.AVPro.Video.Player_Base.lambda$RemoveDuplicateCommand$0(int, com.renderheads.AVPro.Video.Player_Base$VideoCommand)' 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean com.renderheads.AVPro.Video.Player_Base.lambda$RemoveDuplicateCommand$0(int, com.renderheads.AVPro.Video.Player_Base$VideoCommand) (SourceFile:-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean com.renderheads.AVPro.Video.Player_Base$$ExternalSyntheticLambda0.test(java.lang.Object) (D8$$SyntheticClass:-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean java.util.Collection.removeIf(java.util.function.Predicate) (Collection.java:576) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at void com.renderheads.AVPro.Video.Player_Base.RemoveDuplicateCommand(int) (SourceFile:-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at void com.renderheads.AVPro.Video.Player_Base.SeekWithTolerances(double, long, long) (SourceFile:-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at void com.renderheads.AVPro.Video.Manager.Player_Seek(int, double, double, double) (SourceFile:-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean com.unity3d.player.UnityPlayer.nativeRender() ((null):-2) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean com.unity3d.player.UnityPlayer.access$600(com.unity3d.player.UnityPlayer) ((null):-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean com.unity3d.player.UnityPlayer$g$1.handleMessage(android.os.Message) ((null):-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at void android.os.Handler.dispatchMessage(android.os.Message) (Handler.java:102) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at boolean android.os.Looper.loopOnce(android.os.Looper, long, int) (Looper.java:205) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at void android.os.Looper.loop() (Looper.java:294) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] at void com.unity3d.player.UnityPlayer$g.run() ((null):-1) 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] in call to CallStaticVoidMethodV 07-05 11:34:04.029 9599 9653 F ro.nebula:space: java_vm_ext.cc:591] from boolean com.unity3d.player.UnityPlayer.nativeRender() 07-05 11:34:04.051 1201 1201 I QTI PowerHAL: Power setMode: 6 to: 1 07-05 11:34:04.053 1201 1201 E QTI PowerHAL: Failed to acquire lock for hint_id: 10A5.
It looks like it might be a threading issue. Which Unity version and which main entry point are you using?
It looks like it might be a threading issue. Which Unity version and which main entry point are you using?
2021.3.16.f1c1 What does "main entry point" mean?
Are you using the latest version of AVPro video? 3.0.6?
Are you using the latest version of AVPro video? 3.0.6?
no, used 3.0.5. I'll try 3.0.6
still has the issue , AVProVideo 3.0.6 ultra full-log306.log
This is now a different issue. This is because the player is being destroyed off the main thread. ExoPlayer now demands that all it's calls are made on the thread that created the object (the main thread in AVPro Videos case).
This will require us to defer the destroy/deinitialise calls to the main thread. We will look into making this change.
For the record, this is the callstack:
at void androidx.media3.exoplayer.ExoPlayerImpl.verifyApplicationThread() (ExoPlayerImpl.java:2797) at void androidx.media3.exoplayer.ExoPlayerImpl.stop() (ExoPlayerImpl.java:995) at void com.renderheads.AVPro.Video.Player_ExoPlayer._stop() (SourceFile:-1) at void com.renderheads.AVPro.Video.Player_ExoPlayer.CloseVideoOnPlayer() (SourceFile:-1) at void com.renderheads.AVPro.Video.Player_Base._CloseVideo() (SourceFile:-1) at void com.renderheads.AVPro.Video.Player_Base.Deinitialise() (SourceFile:-1) at void com.renderheads.AVPro.Video.Manager.DestroyPlayer(int) (SourceFile:-1) at boolean com.unity3d.player.UnityPlayer.nativeRender() ((null):-2) at boolean com.unity3d.player.UnityPlayer.access$600(com.unity3d.player.UnityPlayer) ((null):-1) at boolean com.unity3d.player.UnityPlayer$g$1.handleMessage(android.os.Message) ((null):-1) at void android.os.Handler.dispatchMessage(android.os.Message) (Handler.java:102) at boolean android.os.Looper.loopOnce(android.os.Looper, long, int) (Looper.java:205) at void android.os.Looper.loop() (Looper.java:294) at void com.unity3d.player.UnityPlayer$g.run() ((null):-1)
@Aunter1992 We are struggling to reproduce the crash here. Can you provide some more information as to your projects setup?
- How are you destroying the MediaPlayer?
- Are you doing it on a thread?
- Do you have the 'Application Entry Point' set to GameActivity?
We still cannot get it to crash like you say. Would you be able to send over a base-bones project to [email protected] that shows the crash @Aunter1992 ?
We still cannot get it to crash like you say. Would you be able to send over a base-bones project to [email protected] that shows the crash @Aunter1992 ?
It looks like the issue was with my usage. If I don't call forcedispose before each openmedia, the crash no longer occurs. I have corrected this, thank you.
Thanks for letting us know!
I have identified the cause of the problem. It is due to an unhandled exception from AndroidJNI.
The call to Native.AVPPlayerRelease(_player) threw a JNI exception that was not handled.
If I continue to use JNI calls in C#, it will not cause the program to crash, something like this.
However, if the next JNI call is made in C++, it will cause the program to crash.
Here is how I am handling it to avoid this issue.
This involves the issue of handling AndroidJNI exceptions, which you can look up on your own.
Back to ‘can you provide a bare bones project that shows the crash/exception’ ?
I can see why it’s happening, but I cannot implement and test a fix if I cannot reproduce it.
Back to ‘can you provide a bare bones project that shows the crash/exception’ ?
I can see why it’s happening, but I cannot implement and test a fix if I cannot reproduce it.
call SystemInfo.batteryInfo after AVPlayRelease , It will throw JNI Exception when Mediaplayer destoryed. you can do a simple test .
Tried that. No difference. Cannot reproduce.
Tried that. No difference. Cannot reproduce.
Strange problem, let's put it aside for now. I'll organize it later.
1942 Please address this issue as soon as possible.
How is this issue linked to issue 1942? If it is not, then cross posting with no link is extremely unhelpful and just slows down how quickly we can offer support. Please delete the post if the issues are not linked @Aunter1992
Whilst I cannot reproduce it...I am 99% sure I know what is causing it, and have put a change in to counter the issue. Not being able to test it, this fix is going in completely blind.
We will include it in the next release (v3.0.7) which we hope to get out tomorrow or early next week.

Strange problem, let's put it aside for now. I'll organize it later.