mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-24 07:30:57 +01:00
DVD subtitles (VobSub) are wrongly converted to SRT #908
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#908
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @KeepBotting on GitHub (Sep 12, 2019).
Describe the bug
External subtitle tracks in VobSub format (
.idx/.sub) can be selected but subtitles are never shown onscreenThis appears to be because the sub track is converted to SRT, but the original files (.idx/.sub) should instead be played by Kodi directly.
Please grep through logs present in various issue comments for more information.
To Reproduce
Expected behavior
VobSubs should appear on the screen as other external subtitles (SRT) and muxed subtitles do.
System (please complete the following information):
10.3.5,10.4.0,10.4.318.3,18.4,18.5,18.60.2.1,0.3.4,0.4.0,0.5.3@mcarlton00 commented on GitHub (Oct 9, 2019):
I spent some time going through my library to find files with messed up subs, and I'm not convinced that this is strictly a VobSub issue. I had a large majority of my VobSub encoded files play fine, but there were a few that wouldn't play. The ones that wouldn't play in Kodi all had special fonts when viewed through the web client.
Regardless of what the actual problem is, we should find the cause and fix it. We'll need to add more logging to find the source, this is all I'm getting when it happens:
And the
ServerIderror is likely unrelated, based on other things we've seen so far@mcarlton00 commented on GitHub (Oct 20, 2019):
Just as an update, I've tracked this down to the response we're getting from the server. When using external vobsub files, the addon seems to download them to
.kodi/userdata/addon_data/plugin.video.jellyfin/temp/Stream.eng.sub, however the server isn't returning anything when downloading .sub files. The server returns a 200 ok, but then the contents are empty. It's possibly a bug in the server instead of JF for kodi, but more investigation is needed since it only appears to happen on some files.@dkanada commented on GitHub (Oct 20, 2019):
@KeepBotting if you could test a broken video and then link the server logs here we might be able to fix this more easily.
@KeepBotting commented on GitHub (Oct 20, 2019):
Much obliged. A full log can be found here.
Relevant bits I can identify:
Seems like it tries to convert them to SRT? I am not sure if this is sane behavior, as VobSub are binary (OCR'd images of DVD subtitles) which likely disqualifies them for conversion into plain text.
Though a
.subis requested after this conversion takes place so not sure what's happening there.@dkanada commented on GitHub (Oct 21, 2019):
@JustAMan @Bond-009 with the logs above should we transfer this to the server issues?
@JustAMan commented on GitHub (Oct 21, 2019):
I wonder why vobsub is converted to
.srtbut a server is asked a.subinstead... it might be a client issue still.@mcarlton00 commented on GitHub (Oct 22, 2019):
The logic for how it builds the URL and determines what file type to download is here, notably around line 486.
2b89f78549/resources/lib/helper/playutils.py (L473-L495)@KeepBotting commented on GitHub (Oct 27, 2019):
@mcarlton00 It may be worth noting:
I cannot reproduce this behavior. No external VobSubs (.idx/.sub) will appear, regardless of the presence of special fonts or characters.
Would a client-side log help in debugging this further?
@mcarlton00 commented on GitHub (Oct 27, 2019):
I can't replicate my earlier findings now. I'm guessing that I was picking up some other formatted subs during my testing before. So it's looking like yes, all VobSub files are failing to render client side.
@JustAMan @dkanada I've done some hacking around in the code, forcing the addon to download
Stream.srtandStream.en.srt. The .en. file reports no handler available in the JF server. But in the debug logs,Stream.srtreportsIs that meaningful to you server guys?
@JustAMan commented on GitHub (Nov 1, 2019):
This debug entry indicates an error detecting the character set of the subtitles file. Ideas @Bond-009 @cvium ?
@KeepBotting commented on GitHub (Nov 3, 2019):
Correct me if I'm wrong but using SRT at all in this case is erroneous. VobSubs are binary files, they are not text but images of subtitles ripped from a DVD.
As such they are formatted/positioned differently than SRT. At minimum, converting to SRT would be undesirable. The original subtitles should be displayed, no tampering.
Kodi supports VobSub just fine, all subtitles not displayed when using Jellyfin are visible when using Kodi as a standalone player.
But I'm unclear on how Jellyfin would be converting images into text at all. Surely there is no OCR happening? And there is no human-readable data inside a set of VobSub files that would be eligible for conversion into plaintext.
Can we verify to see if this SRT file is even valid? This might explain the
null charseterror @mcarlton00 was seeing.@oddstr13 commented on GitHub (Nov 3, 2019):
OCR can do a decent job, but to get it perfect you need manual correction.
On November 3, 2019 9:11:47 PM UTC, KeepBotting notifications@github.com wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
@KeepBotting commented on GitHub (Nov 3, 2019):
It's a job that doesn't need done. The subtitles already exist and are supported by the player. I don't see a reason for jellyfin-kodi to do anything other than request the (unmodified) subtitle files from the server.
@mcarlton00 commented on GitHub (Nov 3, 2019):
My understanding is that we'd need both the .sub and the .idx file for Vobsub to work correctly natively. We currently only request one file altogether. It could be adjusted, but it's a bit of a one off. That's not the real issue.
To me, the bigger issue at this point is that I seem to be unable to download any of the labeled files at playback time (.sub, .idx, or .srt) when something that has Vobsub encoded subs is playing. You would think that the server would serve up the raw files, but it almost seems as though it's forcing .srt no matter what format it is
@JustAMan commented on GitHub (Nov 5, 2019):
LOL, and I checked last time if those were images or text... but failed to read properly the spec that I found! :) in this case they shouldn't be converted at all, but either remained as-is or burnt it.
@KeepBotting commented on GitHub (Nov 5, 2019):
as-is would be ideal. Kodi supports this subtitle format perfectly while direct playing, having to transcode to view VobSubs would be very undesirable
@Maxattax97 commented on GitHub (Dec 22, 2019):
Going to document this so it can be used for further insight.
I have a Pi 3 running Kodi, I stream to it from my Jellyfin server with transcoding enabled. I am wondering if this is altering the way the container holds the subtitles. Here are
mediainfooutputs of some files which do not display subtitles:Star Trek:
Firefly
@Artiume commented on GitHub (Dec 22, 2019):
So this will be a good page to troubleshoot the ffmpeg. The very last example looks like it's creating an MP4 with vobsub so I think ffmpeg does support it.
https://en.m.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/subtitle_options
@iwalton3 commented on GitHub (Apr 3, 2020):
Currently in MPV Shim I don't declare support for external PGSSUB and VOBSUB in the profile because otherwise it tries to send it but gets an empty file. I do for *.sub files because that is also a text subtitle format, but this effectively breaks external vobsub subtitles without telling the client to transcode using the menu. (https://github.com/iwalton3/jellyfin-mpv-shim/issues/27)
I think a good solution would be to add the ability for the client to download the stream as a remuxed *.mks file. That can embed both the *.idx and *.sub file and is supported by mpv.
It also might help to have some way to differentiate between *.sub and .sub/.idx in the profile. But if it just serves mks for bitmapped subtitles it doesn't matter for my specific client.
@KeepBotting commented on GitHub (Apr 4, 2020):
If any testing related to this is needed, please ping
branonin IRC/Matrix@stale[bot] commented on GitHub (Aug 19, 2020):
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.
@sevenrats commented on GitHub (Oct 5, 2023):
needs testing again as per mcarlton. may still not be fixed.
@Shadowghost commented on GitHub (Oct 5, 2023):
Likely fixed by #7960 or #8087
@sevenrats commented on GitHub (Dec 8, 2023):
closing this issue, as its "likely fixed."
Please open a new issue if you experience this problem.