-
-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when viewing TV recording already in progress #1759
Comments
Thank you for posting this issue and all of the detail that you provided. So far I haven't been able to reproduce this crash, but I also don't get the extra "jpeg_pipe" entry in the destination library when recording. My only somewhat educated guess at this point is that this "jpeg_pipe" entry only exists with certain Live TV setups, and when the Jellyfin Roku client tries to retrieve information on it is when the crash happens. To help with being able to reproduce this issue, would you provide an overview of your Live TV setup? For example, what tuner do you use? Are you using IPTV, and if so can you provide information on that setup? At this point I don't believe this is EPG related, but just in case what is your EPG source? Does the Android client show this "jpeg_pipe" entry during recording? Based on your issue report I'm thinking that it doesn't, and that this would be the preferred behavior for the Roku client since it would not a playable item. |
My setup is a HDHomeRun Connect Duo (HDHR5-2US with firmware 20231214) on the same subnet as Jellyfin. Jellyfin itself detects that via the "Live TV" setting, along with Schedules Direct for the guide data. Pretty vanilla setup I think? Playing around a little today and a brand new recording doesn't have this issue... What has reliably shown this problem is the 6pm local news here, so I will fully delete that series and recreate from scratch and then see what happens this week. (This series also has other oddities such as no series or episode meta-data from Schedules Direct, it's shown as "live" in the guide, and it would sometimes leave a .bin file instead of a .jpeg for the thumbnail.)
Yes it does. It appears as a (zero byte) episode recording. Are there certain API calls the Roku client makes? If so I could run a |
That is not only pretty vanilla, it is also pretty close to my setup. I have a HDHR Extend, though my EPG data isn't from Schedules Direct. The latest firmware for my device is 20230713, so it's possible HDHR has made changes, though if so it is odd that it isn't consistent about producing this 0 byte file. When you look at the filesystem for the show's target directory when a recording is in process, are you able to see what the filename is for the 0 byte file, and if so what is it? When I have a recording in process that has seasons, in the appropriate season directory I'm getting 3 files for the episode, none of which are 0 byte:
Do you have any other processes running that monitor or write to your recording directory other than the Jellyfin server? I'm thinking of things such as a job that looks for new recordings and transcodes or remuxes when recordings are completed... Specifically the line of code that errored for you above is trying to display the video codec for the file (e.g. "Video: 1080i H264 SDR" for a show that was recorded and recording has completed.) I'm looking right now in the Jellyfin Roku client at an episode that is currently recording, and it is just showing blank for the video and audio codec. I think that is because the server hasn't had a chance to run an analysis on the file yet. Still though, no error or crash. I also tried creating a 0 byte "(Episode Name).mp4" in the directory by doing a touch from the command line on the server, and the Roku Jellyfin client sees that 0 byte file and lists it as an episode in the season , but no crash. Thank you for the info about the oddities with the EPG data for your local news. The section of code that is erroring is getting an "Invalid" instead of no value. I can't see a scenario where EPG data would have information on the video codec since that is specific to your recording (e.g. my Extend can transcode to a lower resolution than the broadcast if I want), but perhaps there is an EPG listing with an odd format that is causing the TV show object to be built with an invalid/unexpected structure. I'll need to dig into the code to see what calls the Jellyfin client is making to the Jellyfin server to try to get this information. Let me know what you find as recordings proceed on that evening news show that is problematic. Sorry so long. Partially this is me recording what I've found so far for others or when I next look at this. Disclaimer: I'm just an interested member of the community, not an official Jellyfin Developer. This got my attention because I made my first Jellyfin contribution in the Jellyfin Roku client v2.0.4, to fix the ability to start viewing recordings in process. Changes had been made in v2.0.0 had caused issues for this functionality. However, I haven't (so far) had to make any changes in the code where you are seeing errors. |
Here's what I observed with the recording today, 3 files:
Items 2 and 3 match what you likely have, however item 1 I think is the problem.
I observe
Browsing the folder in the Roku app for this show causes it to crash as per my first post, whereas Android and the web GUI work fine (but contain this additional file). Manually renaming this file to .jpg and refreshing the metadata for the library prevents the crash. What is interesting is the timestamp of this thumb.bin file is much older than the recording, as if Jellyfin is pulling it from a cache somewhere... Edit: the thumb.bin file seems to be this issue. |
Great find on the root cause for there being a incorrect .bin file! I don't understand what the use cases are that cause the Jellyfin server to sometimes produce the incorrect .bin as you are often getting, while I have not seen this issue yet. To summarize, at this point it appears highly likely that this Roku client crash happens as a result of an upstream defect in the Jellyfin server. As of today the servers team is asking if the issue still exists in the Jellyfin Server master branch (I assume this will eventually be server v10.9.0?) This upstream server defect has different undesirable impacts on the Jellyfin clients: the web and Android client show double episodes, of which one entry is unplayable. The Roku client crashes when trying to enter the series listing when a recording is in process for that series. There are arguments for addressing this issue in the Roku client, or for waiting to have the root issue to be addressed in the Jellyfin server so that this condition doesn't exist for the Roku client. @cewert or @1hitsong - do you have input on this? I know server v10.9.0 has a lot of changes in it, though the list has not yet been published. |
For now I have a post-processing bash script to rename the Edit:
|
@VTRunner the fix for the error in the OP is an easy one - just ensure |
@ch6574 Are you still seeing this issue with Jellyfin server 10.9.x? I still have not been able to reproduce this issue, so I can check that a change doesn't break anything, but I can't test that it fixes this issue. |
I upgraded to 10.9.2 over the weekend, and haven't seen this issue since (a random |
Software Versions
Describe the bug
Attempting to browse to a TV recording of a show that is currently recording results in the app crashing and being returned to the Roku home screen.
How To Reproduce
Expected behavior
Ideally the series is browsable, and the active recording is playable as a "catch up". This is possible to do on both the Jellyfin web client as well as the Android client.
N.B. I do observe that while the live recording is taking place an extra media entry is shown in the series listing in the Jellyfin web with media type of "jpeg_pipe" of size 0 MB.
Logs
Screenshots
n/a
Connection Information
Additional context
The text was updated successfully, but these errors were encountered: