The VideoLAN Forums

On my slow Samsung J7 running Android 8.0.0, new nightlies, including 2023-04-01, readily crash on first use, apparently when I scroll the track list before VLC has finished building its data structures. It never crashes thereafter. Here is a crash dump:

--------- beginning of crash
03-31 21:33:11.931 E/AndroidRuntime(20349): FATAL EXCEPTION: main @coroutine#2322
03-31 21:33:11.931 E/AndroidRuntime(20349): Process: org.videolan.vlc.debug, PID: 20349
03-31 21:33:11.931 E/AndroidRuntime(20349): java.lang.IllegalStateException: Fragment AudioBrowserFragment{1dab148} (9bafc1a9-b3e6-4269-ab41-a51cd9f74f0e) not attached to a context.
03-31 21:33:11.931 E/AndroidRuntime(20349): at androidx.fragment.app.Fragment.requireContext(Fragment.java:967)
03-31 21:33:11.931 E/AndroidRuntime(20349): at androidx.fragment.app.Fragment.getResources(Fragment.java:1031)
03-31 21:33:11.931 E/AndroidRuntime(20349): at androidx.fragment.app.Fragment.getString(Fragment.java:1053)
03-31 21:33:11.931 E/AndroidRuntime(20349): at
...
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): java.lang.IllegalStateException: Fragment AudioBrowserFragment{1dab148} (9bafc1a9-b3e6-4269-ab41-a51cd9f74f0e) not attached to a context.
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): at androidx.fragment.app.Fragment.requireContext(Fragment.java:967)
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): at androidx.fragment.app.Fragment.getResources(Fragment.java:1031)
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): at androidx.fragment.app.Fragment.getString(Fragment.java:1053)
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): at org.videolan.vlc.gui.audio.AudioBrowserFragment.updateEmptyView(AudioBrowserFragment.kt:327)
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): at
...
03-31 21:33:11.935 E/VLC/VlcCrashHandler(20349): Suppressed: kotlinx.coroutines.DiagnosticCoroutineContextException: [CoroutineId(2320), "coroutine#2320":StandaloneCoroutine{Cancelling}@5d8cad5, androidx.arch.core.executor.ArchTaskExecutor$2@d972ea]
03-31 21:33:11.951 I/zygote (20349): Background concurrent copying GC freed 83986(4MB) AllocSpace objects, 11(744KB) LOS objects, 50% free, 12MB/25MB, paused 918us total 131.054ms
03-31 21:33:11.964 E/System (20349): Uncaught exception thrown by finalizer
03-31 21:33:11.966 E/System (20349): java.lang.AssertionError: VLCObject (org.videolan.libvlc.Media) finalized but not natively released (1 refs)
03-31 21:33:11.966 E/System (20349): at org.videolan.libvlc.VLCObject.finalize(VLCObject.java:101)
03-31 21:33:11.966 E/System (20349): at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:250)
03-31 21:33:11.966 E/System (20349): at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:237)
03-31 21:33:11.966 E/System (20349): at java.lang.Daemons$Daemon.run(Daemons.java:103)
03-31 21:33:11.966 E/System (20349): at java.lang.Thread.run(Thread.java:764)

Thanks, we'll take a look.

Hi, I wasn't able to reproduce this. When you say "first use", did you uninstall your previous version to install the nightly and go through the onboarding process, or was it just the first use after upgrading ?

It was first use after upgrading.

Ok, thanks, do you know which version / date of the nightly you had previously ?

Sorry, I've deleted it. I think it was 3.5.4 Nightly 2023-03-20. It crashed too. It has 2,897 MP3s to catalogue.

Have just upgraded to the Nightly of 2023-04-15. Old phone, lots of MP3s, I go straight to audio and use the scroll bar and the app still crashes. (IllegalStateException, AudioBrowserFragment not attached to a context.) Call stack comparable to the one above.

It should be fixed by https://code.videolan.org/videolan/vlc- ... uests/1719

Thank you! It says the fix is targeted for 3.6, but if it will start to appear in Nightlies, I'll upgrade and report.

As soon as it will be merged, it will be added to the next nightly.

It was just merged, you should have the fix tomorrow

Thanks, I'll try it.

Indeed the bug hasn't happened with the Nightly of 2023-04-19, thanks!

Another subtle but wonderful change: The scroll bar disappears too (after a few seconds; reappears if you scroll the list). This resolves my chronic complaint that trying to tap three-dots to append songs to the play queue sometimes scrolls the list—or, if you instead miss to the left, plays the song now and trashes the queue! Also resolves my debate with @Aza that three-dots should be moved to the true middle of the tap region. I now feel the lip of the phone protector to tap three-dots at the edge, with no scroll bar. Much more usable!