Closed cyyynthia closed 1 year ago
I transfer this issue to WATERMeDIA (when VLC is involved always is WMedia)
First of all: WATERMeDIA no uses Luac scripts anymore, instead we use sealedtx / java-youtube-downloader to extends youtube compat support with a smooth video playing. Luac for youtube is terrible, all videos from that scrips are slow and laggy.
Twitch VODS are still unsupported.
You have nightlies version? we are using 3.19.0 nightlies version to avoid some bugs https://artifacts.videolan.org/vlc-3.0/nightly-win64/20230618-0226/
WATERMeDIA no uses Luac scripts anymore, instead we use sealedtx / java-youtube-downloader to extends youtube compat support with a smooth video playing. Luac for youtube is terrible, all videos from that scrips are slow and laggy.
That's odd, as soon as I updated the lua script for VLC by using the upstream script straight from their repo, YouTube playback started working again. I can definitely say the playback was a bit laggy but I didn't thoroughly test that.
Twitch VODS are still unsupported.
I figured this the hard way - nonetheless it seems to have poked at issues when the URL is invalid, causing some problems which I think would also apply to non-existing channels etc 🤔
You have nightlies version?
I use the vlc
package from the Arch Linux repository - installing from AUR's vlc-git
package would put me on VLC 4.x so there's no "easy way" to get 3.x nightly
Installing manually from their builds on videolan.org is feasible but a nightmare, but I guess I'll give it a shot 😔 I'd still be best to have stable VLC work, or at least have its problems gracefully handled 🤔
I'll give all this a shot and come back with the results.
Alright, I am back with a couple observations:
useVLC
configuration to false
solves the YouTube livestream problem entirely. Stream works in great quality, so does a normal YouTube video and a raw .mp4.
And indeed, after observing in greater details the logs, it seems the YouTube livestream is passed to VLC (explaining my original findings that updating the Lua plugin fixed the issue), and so is the Twitch VOD playback. Both of these fail (for different reasons), the final result is there's nothing to playback, and the game freezes indefinitely.
Considering the type of error and the logs I'm seeing, I'm unsure if going with the Nightly build is a solution or hiding the root of the problem: in both cases, what happens is the playback is abruptly stopped by VLC due to a Lua error. My assumption is that if it's not handled on 3.0.18, I don't see how 3.0.19 would somehow solve the root cause of this issue 🤔
I might be wrong as I haven't looked in details at your code, but the symptoms seems like something that could manifest again and again.
- Interestingly, setting the
useVLC
configuration tofalse
solves the YouTube livestream problem entirely. Stream works in great quality, so does a normal YouTube video and a raw .mp4.
useVLC? on WF?. is impossible, that setting doesn't exists
And indeed, after observing in greater details the logs, it seems the YouTube livestream is passed to VLC (explaining my original findings that updating the Lua plugin fixed the issue), and so is the Twitch VOD playback. Both of these fail (for different reasons), the final result is there's nothing to playback, and the game freezes indefinitely.
Thats how was intended to work, when our URLPatchers fails to get URL throws a handled exception and given to VLC the original URL. of course everything else is handled by VLC.
Considering the type of error and the logs I'm seeing, I'm unsure if going with the Nightly build is a solution or hiding the root of the problem: in both cases, what happens is the playback is abruptly stopped by VLC due to a Lua error. My assumption is that if it's not handled on 3.0.18, I don't see how 3.0.19 would somehow solve the root cause of this issue 🤔
I am using nightlies version to fix bugs mentioned here: https://code.videolan.org/videolan/vlc/-/milestones/119#tab-issues
useVLC? on WF?. is impossible, that setting doesn't exists
Oh I meant on the WaterFrames mod, sorry for the confusion. Changing this there made the livestream work flawlessly instead of having it handled by VLC and broken youtube.luac.
I am using nightlies version to fix bugs mentioned here: https://code.videolan.org/videolan/vlc/-/milestones/119#tab-issues
I'll give it a shot then. Snap is a nightmare and it'll take a bit before I manage to cleanly install nightly vlc without bloating my system with unnecessary bloat 😔
Oh I meant on the WaterFrames mod, sorry for the confusion. Changing this there made the livestream work flawlessly instead of having it handled by VLC and broken youtube.luac.
I ask again. On waterframes? that setting does not exists. also the setting "disableVLC" on WATERFrAMES disable all video features only keeping picture capability.
and watermedia doesn't have config files.
also, if you can and if you want... you can help me giving direct WMedia support to linux installing VLC and send me
I ask again. On waterframes? that setting does not exists.
Uh it might be from a leftover file from the old version then 😵💫 Did the versions prior to using watermedia happen to have this?
Then I'm stupid and sorry for the confusion there; but it makes it extra weird it sometimes freezes to death and sometimes doesn't..? I'm super confused here, actually more than before 😵💫
also, if you can and if you want... you can help me giving direct WMedia support to linux installing VLC and send me [...]
I'm unsure I understand what you need so I'll answer with the best I can come up with 😅 I assume you want the nightly binaries, right?
perfect, the structure can be replicated on watermedia bin extraction and yes, i need nighlies files (dir Structure is done)
And probably you edit a pretty old WF file config.
Welp, the package you have me segfaults on my system. That's unfortunate...
Also, I'm unsure if VLC will be fine if embedded and extracted on-demand, at least using files from the snap package; it's quite common for Linux executables to have paths hardcoded and expect to find libs in /usr/lib/... where you'll not be able to write in from the mod.
Looking at the logs VLC generated, I'm quite sure unless you build VLC from source using the appropriate build flags, you won't be able to construct a portable setup unfortunately :(
To be fair, on Linux users generally are fine with having to install things on their own in addition to other things so I wouldn't consider it a problem per-se, the problem here is the softlock introduced when an error occurs. Have this gracefully handled and even if the player doesn't have the latest bugfixes, I'm sure that'd already be better 🤔
For the livestream stuff, this time I took the time to properly read the logs and they were each time given to VLC to process, instead of being handled by the internal lib. I'm guessing YouTube's quirky video obfuscation system is to blame here for VLC sometimes getting it right and sometimes failing.
I did a bit of profiling using VisualVM, and it seems Minecraft's Render Thread is hanging here in VideoLanPlayer.java#getDuration
, attempting to call libvlc's libvlc_media_player_get_length
It's quite weird, considering the method isn't meant to be blocking but considering the video is "broken" it might cause some player locks to not be dealt with properly in VLC's code resulting in WM's call to indefinitely hang?
I can confirm that the hang occurs here. I constantly have it hanging here, with the following thread dump:
"Render thread" #1 prio=10 os_prio=0 cpu=18212.67ms elapsed=289.14s tid=0x00007f9188015b70 nid=0xcd7bc runnable [0x00007f918e1fc000]
java.lang.Thread.State: RUNNABLE
at me.lib720.caprica.vlcj.binding.lib.LibVlc.libvlc_media_player_get_length(watermedia@1.2.10/Native Method)
at me.lib720.caprica.vlcj.player.base.StatusApi.length(watermedia@1.2.10/Unknown Source)
at me.srrapero720.watermedia.api.video.players.VideoLanPlayer.getDuration(watermedia@1.2.10/Unknown Source)
at me.srrapero720.waterframes.display.MediaDisplay.tick(waterframes@1.3.1b/Unknown Source)
at me.srrapero720.waterframes.custom.tiles.TileFrame.tick(waterframes@1.3.1b/Unknown Source)
at me.srrapero720.waterframes.custom.blocks.Frame$$Lambda$7515/0x000000080107a658.m_155252_(waterframes@1.3.1b/Unknown Source)
at net.minecraft.world.level.chunk.LevelChunk$BoundTickingBlockEntity.m_142224_(minecraft@1.18.2/LevelChunk.java:673)
at net.minecraft.world.level.chunk.LevelChunk$RebindableTickingBlockEntityWrapper.m_142224_(minecraft@1.18.2/LevelChunk.java:766)
at net.minecraft.world.level.Level.m_46463_(minecraft@1.18.2/Level.java:476)
at net.minecraft.client.multiplayer.ClientLevel.m_104804_(minecraft@1.18.2/ClientLevel.java:208)
at net.minecraft.client.Minecraft.m_91398_(minecraft@1.18.2/Unknown Source)
at net.minecraft.client.Minecraft.m_91383_(minecraft@1.18.2/Unknown Source)
at net.minecraft.client.Minecraft.m_91374_(minecraft@1.18.2/Unknown Source)
at net.minecraft.client.main.Main.main(minecraft@1.18.2/Main.java:205)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.7/Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.7/NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.7/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@17.0.7/Unknown Source)
at net.minecraftforge.fml.loading.targets.CommonClientLaunchHandler.lambda$launchService$0(fmlloader@1.18.2-40.2.9/CommonClientLaunchHandler.java:31)
at net.minecraftforge.fml.loading.targets.CommonClientLaunchHandler$$Lambda$845/0x00000008004a23e0.call(fmlloader@1.18.2-40.2.9/Unknown Source)
at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(cpw.mods.modlauncher@9.1.3/LaunchServiceHandlerDecorator.java:37)
at cpw.mods.modlauncher.LaunchServiceHandler.launch(cpw.mods.modlauncher@9.1.3/LaunchServiceHandler.java:53)
at cpw.mods.modlauncher.LaunchServiceHandler.launch(cpw.mods.modlauncher@9.1.3/LaunchServiceHandler.java:71)
at cpw.mods.modlauncher.Launcher.run(cpw.mods.modlauncher@9.1.3/Launcher.java:106)
at cpw.mods.modlauncher.Launcher.main(cpw.mods.modlauncher@9.1.3/Launcher.java:77)
at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(cpw.mods.modlauncher@9.1.3/BootstrapLaunchConsumer.java:26)
at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(cpw.mods.modlauncher@9.1.3/BootstrapLaunchConsumer.java:23)
at cpw.mods.bootstraplauncher.BootstrapLauncher.main(cpw.mods.bootstraplauncher@1.0.0/BootstrapLauncher.java:149)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.7/Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.7/NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.7/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@17.0.7/Unknown Source)
at io.github.zekerzhayard.forgewrapper.installer.Main.main(Main.java:57)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.7/Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.7/NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.7/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@17.0.7/Unknown Source)
at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:243)
at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:278)
at org.multimc.EntryPoint.listen(EntryPoint.java:143)
at org.multimc.EntryPoint.main(EntryPoint.java:34)
I'm afraid version 1.2.11 still locks itself, this time, due to the isPlayable call getting stuck in the libvlc code. :(
I did inspect the process with GDB, and it indeed confirms VLC somehow is locking itself up:
#0 futex_wait (private=0, expected=2, futex_word=0x7f46f62594b0) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x7f46f62594b0, private=0) at lowlevellock.c:49
#2 0x00007f46fb9958c2 in lll_mutex_lock_optimized (mutex=0x7f46f62594b0) at pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=0x7f46f62594b0) at pthread_mutex_lock.c:93
#4 0x00007f4618ed3baa in libvlc_media_player_will_play () at /usr/lib64/libvlc.so
...
At this point this might as well be a linux-only, VLC-related problem but I can't find any single meaningful information about a deadlock in libvlc, other than 10+ years old threads...
I'm out of clues here. I'll try later to put together a test to see if libvlc itself is the problem, or if something else is happening. Maybe thread safety?
Please wait. I need your help to do a bug report to VLC El 19 jun. 2023 11:58 a. m., Cynthia @.***> escribió: Hello! I've been trying out the mod and it caused several hard freezes that were quite annoying to get past, as killing and starting the game again would cause it to freeze again upon loading the frame. I've noticed 2 things that caused such crash, I don't know if they're somehow related: Loading a YouTube video with a """broken""" VLC YouTube plugin: my Linux installation of VLC was somehow not able to play YouTube videos; but this caused the game to freeze upon trying to load a YouTube video. (Fixing my VLC installation did make it work as expected).Loading a Twitch VOD caused the game to freeze and there was no solution for this one. While the YouTube-related freeze didn't log any stack trace, but the Twitch one printed an error related to WATERMeDIA's TwitchPatch. My two cents is that it expects to find a stream, but there's nothing to find as it's a video url. I think overall there seem to be lacking error handling, and any player failure will cause the game to freeze which isn't ideal. I don't know where to report it between here and watermedia's repo, so I figured since you're the developer of both you could transfer the issue to the appropriate repository if necessary. :D
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Please wait. I need your help to do a bug report to VLC
Sure thing, I can do specific tests if you need me to. I kept digging and here's the data I have so far:
4 different threads interact with vlcj
, for a single frame with an invalid Twitch link.
After getting my hands on the VLC debug symbols, here's the precise site the player is locking itself in:
(lldb) thread select 2
* thread #2, name = 'Render thread', stop reason = signal SIGSTOP
frame #0: 0x00007fdccf68b160 libc.so.6`__GI___lll_lock_wait at futex-internal.h:146:13
143 static __always_inline int
144 futex_wait (unsigned int *futex_word, unsigned int expected, int private)
145 {
-> 146 int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
147 switch (err)
148 {
149 case 0:
(lldb) up
frame #1: 0x00007fdccf68b14a libc.so.6`__GI___lll_lock_wait(futex=0x00007fdcca48b580, private=0) at lowlevellock.c:49:7
46 {
47 futex:
48 LIBC_PROBE (lll_lock_wait, 1, futex);
-> 49 futex_wait ((unsigned int *) futex, 2, private); /* Wait if *futex == 2. */
50 }
51 }
52 libc_hidden_def (__lll_lock_wait)
(lldb) up
frame #2: 0x00007fdccf6918c2 libc.so.6`___pthread_mutex_lock at pthread_mutex_lock.c:48:5
45 if (private == LLL_PRIVATE && SINGLE_THREAD_P && mutex->__data.__lock == 0)
46 mutex->__data.__lock = 1;
47 else
-> 48 lll_lock (mutex->__data.__lock, private);
49 }
50
51 # define LLL_MUTEX_LOCK(mutex) \
(lldb) up
frame #3: 0x00007fdccf6918b8 libc.so.6`___pthread_mutex_lock(mutex=0x00007fdcca48b580) at pthread_mutex_lock.c:93:7
90 FORCE_ELISION (mutex, goto elision);
91 simple:
92 /* Normal mutex. */
-> 93 LLL_MUTEX_LOCK_OPTIMIZED (mutex);
94 assert (mutex->__data.__owner == 0);
95 }
96 #if ENABLE_ELISION_SUPPORT
(lldb) up
frame #4: 0x00007fdbe4028baa libvlc.so`libvlc_media_player_will_play [inlined] lock_input(mp=0x00007fdcca48b510) at media_player.c:119:5
116
117 static inline void lock_input(libvlc_media_player_t *mp)
118 {
-> 119 vlc_mutex_lock(&mp->input.lock);
120 }
121
122 static inline void unlock_input(libvlc_media_player_t *mp)
(lldb) up
frame #5: 0x00007fdbe4028ba4 libvlc.so`libvlc_media_player_will_play at media_player.c:198:5
195
196 assert( p_mi );
197
-> 198 lock_input(p_mi);
199 p_input_thread = p_mi->input.p_thread;
200 if( p_input_thread )
201 vlc_object_hold( p_input_thread );
(lldb) up
frame #6: 0x00007fdbe4028ba4 libvlc.so`libvlc_media_player_will_play(p_mi=0x00007fdcca48b510) at media_player.c:1749:29
1746 int libvlc_media_player_will_play( libvlc_media_player_t *p_mi )
1747 {
1748 input_thread_t *p_input_thread =
-> 1749 libvlc_get_input_thread ( p_mi );
1750 if ( !p_input_thread )
1751 return false;
1752
Is it possible that the issue comes from a thread safety issue?
Is it possible that the issue comes from a thread safety issue?
i don't think so... if that was the case can be affected windows.
Please send me your Hardware info and your OS info to submit to VLC a bug report
OS: Arch Linux Kernel version: 6.3.8-arch1-1 Package manager: pacman CPU: Intel i7-7700K GPU: NVIDIA GeForce GTX 1060 6GB GPU Driver version: 535.54.03
VLC installation medium: Arch Linux extra repository
vlc --version
:
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
VLC version 3.0.18 Vetinari (3.0.13-8-g41878ff4f2)
Compiled by builduser on (Jun 8 2023 12:15:27)
Compiler: gcc version 13.1.1 20230429 (GCC)
Please try https://www.curseforge.com/minecraft/mc-mods/watermedia/files/4605839 isn't fixed on VLC, i just try to avoid any special situation
@cyyynthia I don't know if you can help me with the complete backtrace. (using old watermedia)
1.2.15 still causes a freeze, and gets stuck at libvlc_media_player_get_length
(meaning the check added in b778ef5fa821425b66bb27932d2e81d505aae69a doesn't catch whatever state the player is in)
Nothing gets logged in Minecraft's logs, other than the PatchingUrlException
.
i mean for the threads.
Hello! I've been trying out the mod and it caused several hard freezes that were quite annoying to get past, as killing and starting the game again would cause it to freeze again upon loading the frame.
I've noticed 2 things that caused such crash, I don't know if they're somehow related:
While the YouTube-related freeze didn't log any stack trace, but the Twitch one printed an error related to WATERMeDIA's TwitchPatch. My two cents is that it expects to find a stream, but there's nothing to find as it's a video url.
I think overall there seem to be lacking error handling, and any player failure will cause the game to freeze which isn't ideal.
I don't know where to report it between here and watermedia's repo, so I figured since you're the developer of both you could transfer the issue to the appropriate repository if necessary. :D