segfault on specific series
Midek opened this issue · 10 comments
When selecting Next Up option, and then 'Ascendance of a Bookworm - S1E8 Lutz's Main' i am getting Segmentation fault (core dumped)
It used to happen randomly with previous episodes from this series (Ascendance of a Bookworm) too, but it would randomly start after couple attempts before.
With other series that i tested, I did not encounter any issues.
D 1. Favorites
D 2. Continue Watching
D 3. Next Up
D 4. Latest Unplayed
D 5. User Views
> 3
===== Next Up =====
V 1. Shakugan no Shana - S3E16 To Battle, Once More
V 2. After School Dice Club - S1E8 The Fourth Friend
V 3. Kemono Michi: Rise Up - S1E8 Episode 8
V 4. Ascendance of a Bookworm - S1E8 Lutz's Main
V 5. Saki - S1E24 Summer Festival
V 6. Urusei Yatsura - S2E16 The Coming of the Mysterious Red Mantle!
V 7. Lucky Star - S1E12 Let's Go to the Festival
V 8. Vikings - S5E1 The Departed (Part 1)
> 4
Segmentation fault (core dumped)
jftui --version
0.2
It happens from Latest Unplayed menu too.
There are no logs in jellyfin.
Can you get me a stack trace? You don't need a debug build, the regular release should have symbols.
i would love to, but im not exactly sure how, could you point me in the right direction?
Sure! Install gdb and run gdb jftui. Enter start into the prompt and try and replicate the crash. Then enter bt to get the trace.
If you get to a breakpoint (set by some included library, there are none in jftui) just enter continue to go on.
Thread 1 "jftui" received signal SIGSEGV, Segmentation fault.
0x000055555555ea8d in jf_json_parse_versions (media_sources=<optimized out>, item=<optimized out>) at src/json.c:614
614 src/json.c: No such file or directory.
(gdb) bt
#0 0x000055555555ea8d in jf_json_parse_versions (media_sources=<optimized out>, item=<optimized out>) at src/json.c:614
#1 0x000055555555f3cd in jf_json_parse_video (item=item@entry=0x555555604b70, video=<optimized out>,
additional_parts=0x555555621660 "{\"Items\":[],\"TotalRecordCount\":0}") at src/json.c:636
#2 0x0000555555561ef6 in jf_menu_play_item (item=0x555555604b70) at src/menu.c:607
#3 0x00005555555625e9 in jf_menu_try_play () at src/menu.c:635
#4 jf_menu_ui () at src/menu.c:830
#5 0x0000555555558273 in jf_mpv_event_dispatch (event=0x5555555fb6a0, event=0x5555555fb6a0) at src/main.c:361
#6 main (argc=<optimized out>, argv=<optimized out>) at src/main.c:598
Sorry, I have a couple ideas on what could be wrong but I'd like a few more pieces of information from you.
Could you please install jq and report the result of
. ~/.config/jftui/settings; id=$(curl -H "x-emby-token: ${token}" "${server}/users/${userid}/items?recursive=true&searchterm=lutz%27s%20main" | jq -r '.Items[0].Id'); curl -H "x-emby-token: ${token}" "${server}/users/${userid}/items/${id}" | jq
from a terminal session? There won't be any sensible information (or I guess at most the path of the file on your server, feel free to edit that out, I don't need it).
Also, are you using the AUR package, did you checkout the master branch or did you download the 2.0 release?
Finally, I don't think this is the case but would the crashes happen to show up while the server was in the middle of updating the library with the episodes?
I am using the AUR package.
When trying it out, jellyfin is not updating the library.
What i noticed was that when i run the command you posted, jellyfin started scanning the library, and after it finished scanning, the episode started working properly.
When its broken, jq gave me this output:
https://cloud.midov.pl/s/tKxDPsAkR5S3b4X
After a while when jellyfin was done with another library scan jftui started working, and jq gave me output like this:
https://cloud.midov.pl/s/xtzyPT7St4WMDzZ
Apparently it detected the format as webm now? im pretty sure its just mkv there.
Directory tree in my movies dir looks like this:
└> tree Honzuki\ no\ Gekokujou
Honzuki\ no\ Gekokujou
|-- Season\ 1
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 01\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 01\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 01\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 02\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 02\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 02\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 03\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 03\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 03\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 04\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 04\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 04\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 05\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 05\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 06\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 06\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 06\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 07\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 07\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 07\ [1080p].nfo
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 08\ [1080p]-thumb.jpg
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 08\ [1080p].mkv
| |-- [HorribleSubs]\ Honzuki\ no\ Gekokujou\ -\ 08\ [1080p].nfo
| `-- season.nfo
Okay, this is something I've noticed can happen. I don't know why trying to access those files would trigger a library refresh (does it happen with the web client too?) but basically, while the server is in the middle of refreshing it sends clients incomplete information about the items it's currently updating. Whether this is reasonable of the server or not (I'd argue it shouldn't show items at all until it's done, but that's not important now), jftui can't handle it and spazzes out.
Try updating the AUR package (I made a mistake and it's tracking master instead of the releases, gotta fix that :P ), you'll get a patch I wrote a while ago but had forgotten to push that will make jftui exit with an unhelpful error instead of just crash. Which is... not a lot a better but at least a step forwards.
I'll figure out a more graceful way to handle this case in the meantime, if possible I'd like not to show incomplete items at all. Thanks for the report.
After updating the package and replicating the crash again, i got
jftui: src/json.c:694: jf_yajl_tree_get_assert: Assertion `v != NULL' failed.
before the crash.
Accessing the files could have triggered the scan becouse i have
Enable real time monitoring
Changes to files will be processed immediately, on supported file systems.
option enabled in jellyfin, so once i put new files in media dir, it adds them right away.
It might actually be jellyfin bug if it leaves this one series in incomplete state after such scan.
From the webclient i can play those files without issues. I am not sure if they trigger the scan too, but its rather likely becouse thats probably how i fixed it with previous episodes (it crashed jftui, so i would go and watch it through the browser.. and next time i tried it would play in jftui properly).
PS. Thanks for making jftui! a proper terminal/desktop client was the one thing that was missing from emby/jellyfin
From my testing I should have made it so jftui will not show items the server's currently scanning. That means you will have to wait a little bit longer than you would on the web interface (jftui needs some more information in order to properly support split-files). If you could double check your series now works fine you'd do me a favour.
Also I had misunderstood, I thought you meant just listing the new items in jftui caused the library refresh. Changing the content of a monitored library will automatically trigger a scan, yeah.
And you're welcome! I wrote it precisely because I felt the same need :)
Indeed, after updating to jftui 0.2.1, Ascendance of a Bookworm is not being listed now when in broken state.
I think it will actually never be listed unless i execute full library rescan now, but that can easily be fixed by scheduling automatic scans in jellyfin more often.