jellyfin / jellyfin-ffmpeg

FFmpeg for Jellyfin
https://jellyfin.org
Other
436 stars 118 forks source link

Video stopping #334

Closed podhorsky-ksj closed 3 months ago

podhorsky-ksj commented 5 months ago

Describe The Bug Multiple times during using jellyfin-ffmpeg with jellyfin, jellyfin sometimes in the middle of the movie stopped playing the video. Only workaround was to play it again and sometimes find the right position, where it stopped, because it wasn't saved. I checked the logs and compared them with the video logs, where this issue didn't happen. Nothing unusual. ffmpeg was just stopped correctly. Some errors, but it was in the correct one too. I checked the network connection, monitored the server, where jellyfin is running, but nothing

When I replaced jellyfin-ffmpeg with normal ffmpeg, I haven't noticed this issue anymore. Steps To Reproduce I used VAAPI hw acceleration (which doesn't probably done the issue) latest jellyfin and jellyfin ffmpeg then just play few videos and see what happened. It occurred more on tizen tv, but I have seen it with web jellyfin too, once for few movies

Expected Behavior Jellyfin should play video without stopping

System (please complete the following information):

MediaInfo

Metadata:
    encoder         : libebml v1.3.1 + libmatroska v1.4.2
    creation_time   : 2019-11-14T10:11:33.000000Z
  Duration: 01:57:32.00, start: 0.000000, bitrate: 6733 kb/s

  Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x816, SAR 1:1 DAR 40:17, 23.98 fps, 23.98 tbr, 1k tbn (default) (forced)
    Metadata:
      BPS             : 6092154
      BPS-eng         : 6092154
      DURATION        : 01:57:31.920000000
      DURATION-eng    : 01:57:31.920000000
      NUMBER_OF_FRAMES: 169077
      NUMBER_OF_FRAMES-eng: 169077
      NUMBER_OF_BYTES : 5370173463
      NUMBER_OF_BYTES-eng: 5370173463
      _STATISTICS_WRITING_APP: mkvmerge v8.3.0 ('Over the Horizon') 64bit
      _STATISTICS_WRITING_APP-eng: mkvmerge v8.3.0 ('Over the Horizon') 64bit
      _STATISTICS_WRITING_DATE_UTC: 2019-11-14 10:11:33
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-11-14 10:11:33
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:1(en): Audio: ac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default) (forced)
    Metadata:
      title           : AC3 5.1
      BPS             : 640000
      BPS-eng         : 640000
      DURATION        : 01:57:32.000000000
      DURATION-eng    : 01:57:32.000000000
      NUMBER_OF_FRAMES: 220375
      NUMBER_OF_FRAMES-eng: 220375
      NUMBER_OF_BYTES : 564160000
      NUMBER_OF_BYTES-eng: 564160000
      _STATISTICS_WRITING_APP: mkvmerge v8.3.0 ('Over the Horizon') 64bit
      _STATISTICS_WRITING_APP-eng: mkvmerge v8.3.0 ('Over the Horizon') 64bit
      _STATISTICS_WRITING_DATE_UTC: 2019-11-14 10:11:33
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-11-14 10:11:33
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:2(en): Subtitle: subrip (default) (forced)
    Metadata:
      title           : English forced sub
      BPS             : 0
      BPS-eng         : 0
      DURATION        : 01:37:04.151000000
      DURATION-eng    : 01:37:04.151000000
      NUMBER_OF_FRAMES: 27
      NUMBER_OF_FRAMES-eng: 27
      NUMBER_OF_BYTES : 398
      NUMBER_OF_BYTES-eng: 398
      _STATISTICS_WRITING_APP: mkvmerge v8.3.0 ('Over the Horizon') 64bit
      _STATISTICS_WRITING_APP-eng: mkvmerge v8.3.0 ('Over the Horizon') 64bit
      _STATISTICS_WRITING_DATE_UTC: 2019-11-14 10:11:33
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-11-14 10:11:33
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

FFmpeg Logs I don't have them, it occurred before I reinstalled the server, but nothing from it caused the issue, because I have seen all rows on correct played movie too.

Additional Context

nyanmisaka commented 5 months ago

@podhorsky-ksj It should be a duplicate of https://github.com/jellyfin/jellyfin/issues/10698, which is fixed by https://github.com/jellyfin/jellyfin/pull/10710

podhorsky-ksj commented 5 months ago

Nope, that's something different. I have seen it even in movies without subtitles. And the stop wasn't at the end od the movie, but in the middle.

nyanmisaka commented 5 months ago

Then I'm out of ideas. I haven't encountered a similar problem once.

What version is vanilla ffmpeg? The changes in jellyfin-ffmpeg are basically for hardware acceleration.

podhorsky-ksj commented 5 months ago

it is 6.1.1. . The changes are even for VAAPI?

Btw. I was thinking, why there is code for ffmpeg. If I had to do something similar, I would put only patch files into this project and then put ffmpeg as submodule of the git project... It would probably be better way to maintain it and everyone would know, what exactly is applied. But it is up to you.

nyanmisaka commented 5 months ago

it is 6.1.1. . The changes are even for VAAPI?

There are some, but not for older platforms. Maybe 6.1 contains some fixes that I'm not aware of. We're still on 6.0.1, we'll probably skip 6.1 and go straight to 7.0.

Btw. I was thinking, why there is code for ffmpeg. If I had to do something similar, I would put only patch files into this project and then put ffmpeg as submodule of the git project... It would probably be better way to maintain it and everyone would know, what exactly is applied. But it is up to you.

Since this is the standard way of packaging for Debian/Ubuntu, we use a similar directory structure as upstream. https://salsa.debian.org/multimedia-team/ffmpeg

podhorsky-ksj commented 5 months ago

So, in my case jellyfin-ffmpeg is not quicker than ffmpeg. So, I will remain on ffmpeg.

I have no idea, where is issue either. Maybe it was something in ffmpeg and there it is fixed now, but not here.

I have to mention one thing, I noticed, I forgot to mention: When I used it on home network, so local address, from home server to computer, nothing unusual happened. It always happened when I push it through public network.

I have home server, where is jellyfin server running, Then VPS, where is running nginx with https certificates let's encrypt (it is not about encryption, it happened even when I used portmap.io for port forward - it also uses ssh port forwarding) and I use ssh port forwarding between home server and VPS. Jellyfin is running on normal configuration without https. So, it can be about some delay of video, through network. And I compared logs from this public network play and from local home network play and they were pretty similar.

gnattu commented 4 months ago

Can you check if the "Throttle Transcodes" setting is enabled in the Playback settings? I've noticed that this option works poorly with hardware acceleration, and it can cause the transcode to be halted altogether and not resume in time.

During my own testing, I also noticed that some videos will lost its last few seconds and never completes the transcode. The transcode progress will be locked to something very close like 99.7% but never completes. The ffmpeg logs indicates that the ffmpeg completed successfully. So this looks like a server-side issue. @nyanmisaka Have you seen this in the master?

nyanmisaka commented 4 months ago

Can you check if the "Throttle Transcodes" setting is enabled in the Playback settings? I've noticed that this option works poorly with hardware acceleration, and it can cause the transcode to be halted altogether and not resume in time.

During my own testing, I also noticed that some videos will lost its last few seconds and never completes the transcode. The transcode progress will be locked to something very close like 99.7% but never completes. The ffmpeg logs indicates that the ffmpeg completed successfully. So this looks like a server-side issue. @nyanmisaka Have you seen this in the master?

It still works for me on master branch.

The reason can be https://github.com/joshuaboniface/rffmpeg/issues/76#issuecomment-1953329450 image

podhorsky-ksj commented 3 months ago

I can't reproduce it anymore.

podhorsky-ksj commented 2 months ago

It happened again. Attaching logs from jellyfin with jellyfin ffmpeg. Log.txt ffmpeg.txt I tried to add throttle f it helps. On the beginning of this ticket I had it disabled.

After 7 minutes, it continues unexpectly with playing (I didn't do anything) so, these logs are similar to 2024-04-18 10:41:40.033, when the playing got stopped.

ffmpegnew.txt Lognew.txt I'm monitoring the network outages, and in this time it was available. Please look into the logs, maybe you will find something.

podhorsky-ksj commented 2 months ago

@gnattu Can you reopen this ticket? I think I don't have privileges.

gnattu commented 2 months ago

It is not a ffmpeg issue from your log. It looks very interesting that during your watching, someone else (or your self) logged in and did a very expensive query which overloaded the server, and then it looks like the server "stopped the world" for a couple of time and then resumes. I'm not sure if this is fixed in 10.9 though, probably not if your library has a complicated structure and your CPU is relatively weak.

gnattu commented 2 months ago

Well, another theory is that due to an ancient dotnet bug, it will raise false positive about network changes on non-windows platforms and caused a networking reset on your server as I've noticed network config change event being raised before the ffmpeg is stopped with q command. This could be mitigated by jellyfin/jellyfin#11253 but that one has not been merged yet.

podhorsky-ksj commented 2 months ago

It is i5 cpu notebook with ssd disk and movies are on hdd disk. But I'm hearing always the fan when it is under load and this time I haven't heard something like you saing, very expensive query. I haven't done anything. And nobody else was on this server. Maybe it is some auto-jobs of jellyfin checking for new media?

ok, I will test it again after the commit merge.

gnattu commented 2 months ago

It is still uncertain if that commit will merge in the 10.9 cycle though, as it introduced a new CLI option. Once merged you can use --nonetchange to disable dotnet's network change API.

podhorsky-ksj commented 2 months ago

It seems this time it is caused by throttle. It does not continue in time, when it was needed. It goes stuck few times and without it it didn't get stuck. Can you do something with it?

gnattu commented 2 months ago

So you are saying disabling throttling does solve this? Then you just disable it as the way it works is fragile indeed.

But for your problem it looks very unlikely a throttling issue to me as the ffmpeg is quit instead of paused.

podhorsky-ksj commented 2 months ago

This one yes. But when this ticket was created I didn't use throttling. But that time it was possibly something in ffmpeg, what is solved now.

Now without throttling it doesn't seems to cause the issues I have seen with throttling and which I mentioned today.

I know there is still another issue with this stop play, but I have problem to reproduce it. I will see.