Crash when viewing TV recording already in progress

[ch6574]

Software Versions

• Jellyfin Server Version: 10.8.13
• Roku Client Version: latest (Jellyfin-Roku-dev-47ac993d869ac0ab6e3b6df749b5b619ad0f90a1)

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

1. While a TV show is recording, attempt to browse to the same series listings
2. Observe the app crash
3. N.B. Other series are viewable, it's only the one with an active recording that is problematic.

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

BrightScript Micro Debugger.
Enter any BrightScript statement, debug commands, or HELP.

Suspending threads...
Thread selected:  1*   ...nts/tvshows/TVListDetails.brs(94)                   m.videoCodec.text = tr("Video") + ": " + itemData.MediaSources[i].MediaStreams[0].DisplayTitle

Current Function:
086:          m.progressBar.width = progressWidthInPixels
087:          m.progressBar.visible = true
088:      end if
089:      ' Display current video_codec and check if there is more than one video to choose from...
090:      m.videoCodec.visible = false
091:      if isValid(itemData.MediaSources)
092:          for i = 0 to itemData.MediaSources.Count() - 1
093:              if item.selectedVideoStreamId = itemData.MediaSources[i].id and isValid(itemData.MediaSources[i].MediaStreams[0])
094:*                 m.videoCodec.text = tr("Video") + ": " + itemData.MediaSources[i].MediaStreams[0].DisplayTitle
095:                  SetupAudioDisplay(itemData.MediaSources[i].MediaStreams, item.selectedAudioStreamIndex)
096:                  exit for
097:              end if
098:          end for
Source Digest(s): 
pkg: dev 2.0.5 6f03fda3 Jellyfin

Type Mismatch. Operator "+" can't be applied to "String" and "Invalid". (runtime error &h18) in pkg:/components/tvshows/TVListDetails.brs(94)
Backtrace:
#0  Function itemcontentchanged() As Void
   file/line: pkg:/components/tvshows/TVListDetails.brs(94)
Local Variables:
global           Interface:ifGlobal
m                roAssociativeArray refcnt=2 count:12
item             roSGNode:TVEpisodeData refcnt=1
itemdata         roAssociativeArray refcnt=1 count:31
indexnumber      roString (2.1 was String) refcnt=1 val:"4. "
airdate          roDateTime refcnt=1
imageurl         roString refcnt=1 val:"http://jellyfin.lan:8096/Items/ba30e19a249c2586046fd9f026e36cce/Images/Primary?maxheight=250&m"...
runtime          <uninitialized>
progresswidthinpixels <uninitialized>
i                Integer val:0 (&h0)
Threads:
ID    Location                                Source Code
 0[u] ??
 1*   ...nts/tvshows/TVListDetails.brs(94)                   m.videoCodec.text = tr("Video") + ": " + itemData.MediaSources[i].MediaStreams[0].DisplayTitle
  *selected   [u]unattached(not debuggable)

Brightscript Debugger> 03-24 00:46:54.828 [beacon.signal] |AppExitInitiate -----------> TimeBase(194072 ms)

Screenshots

n/a

Connection Information

• Is server local or remote? local
• Is server connection HTTP or HTTPS? http

Additional context

[VTRunner]

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.

[ch6574]

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.)

Does the Android client show this "jpeg_pipe" entry during recording

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 curl to dump out the raw data when I next experience the problem.

[VTRunner]

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:

• '(Episode Name).jpg'
• '(Episode Name).nfo'
• '(Episode Name).ts'

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.

[ch6574]

Here's what I observed with the recording today, 3 files:

1. ${Episode}-thumb.bin (32k in size)
2. ${Episode}.nfo (tiny)
3. ${Episode}.ts (1gig)

Items 2 and 3 match what you likely have, however item 1 I think is the problem.

$ file *-thumb.bin
News 4 NY at 6 2024_04_03_22_00_00-thumb.bin: JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, comment: "G", baseline, precision 8, 480x720, components 3

$ ffprobe -hide_banner *-thumb.bin
Input #0, jpeg_pipe, from 'News 4 NY at 6 2024_04_03_22_00_00-thumb.bin':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 480x720 [SAR 72:72 DAR 2:3], 25 fps, 25 tbr, 25 tbn

I observe ffprobe thinks this oddly named image file is a jpeg_pipe and in the Jellyfin GUI under media info it shows:

News 4 NY at 6 2024_04_03_22_00_00-thumb

Container jpeg_pipe
Size 0 MB

Image

Codec MJPEG
Profile Baseline
Resolution 480x720
Bit depth 8 bit
Color space bt470bg
Pixel format yuvj420p
Ref frames 1

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.

[VTRunner]

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.

[ch6574]

For now I have a post-processing bash script to rename the -thumb.bin to -thumb.jpeg, however as this only kicks in after the recording is complete I cannot watch the recording "live" as a catchup on the Roku, only after it has completed.

Edit: ffprobe no longer reports the jpeg_pipe on the renamed file, instead it's now image2.

$ ffprobe -hide_banner *-thumb.jpeg
Input #0, image2, from 'News 4 NY at 6 2024_04_04_22_00_00-thumb.jpeg':
  Duration: 00:00:00.04, start: 0.000000, bitrate: 6352 kb/s
  Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 480x720 [SAR 72:72 DAR 2:3], 25 fps, 25 tbr, 25 tbn

[cewert]

@VTRunner the fix for the error in the OP is an easy one - just ensure itemData.MediaSources[i].MediaStreams[0].DisplayTitle is valid before using it. It's possible the app works fine after that but would need more testing. I don't have a way of testing live TV recordings but I would start there.

[VTRunner]

@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.

[ch6574]

I upgraded to 10.9.2 over the weekend, and haven't seen this issue since (a random .bin file being left as a thumbnail) and even manually recreating that file on the back end doesn't trigger the client to crash any more).