Changing position exit ffmpeg

[xp-1000 1]

hello,

I use emby 3.5.3.0 (I am not sure the problem occurs since this version or even before) on linux with netcore version.

when I try to change position when I watch a video from the web interface, ffmpeg exit.

 

I attach the log and I am available to debug and provide more information if you need.

 

Thanks in advance for your help, it is very disturbing because if you begin to watch a video you need to watch it until the end ^^

 

 

emby.log

[Luke 42077]

Hi there, are you experiencing a problem?

[xp-1000 1]

hello,

yeah I would prefer if I can change position during video playing without crash the video ^^

it worked fine before when I want forward in a video, just have to move the position cursor, there was a little pause then the video play again at its new position.

now the player just freeze when I try to change position (tested on lot of different kind of videos) and the cursor go back to beginning (without action).

I presume I have a specific problem to my install because such a big bug would have already been reported else but I did not change anything recently except upgrading from 3.4.1 to 3.5.3.

[xp-1000 1]

Hmm I also changed from mono version to netcore version but again I am pretty sure if there is this bug in netcore version it would be already reported.

So I understood it probably depends on my own config and not emby itself but I will be grateful if you can help me to find the cause.

I am available to provide you all information you need

[Luke 42077]

Hi there, can you please attach the complete emby server log, and the ffmpeg log? Thanks !

[xp-1000 1]

hello thanks.

here is full clean logs.

 

from the ui point of view, it is simple : when you move the cursor emby player controls work (the interface is not frozen, I can click on top left "back" arrow for instance) but the video just stops (the image stays the last one before move the cursor).

from the server point of view, in addition of provided log, emby itself does not crash and have a "normal" usage of resources.

tested on firefox and chromium and both have the probleme but emby for kodi works, I can move in videos without any problem

Edited December 22, 2018 by xp-1000

[Luke 42077]

Would you mind attaching again? There seems to be a problem with the attachment. Thanks !

[xp-1000 1]

Hello @@Luke,

I uploaded the zip file containing logs here : https://ufile.io/rgcn1

thanks for your help I will investigate further today from my side.

[Luke 42077]

@@softworkz what do you make of this? it looks like some kind of I/O stall on the initial seek?

[softworkz 5066]

@@xp-1000 @@Luke

 

If such seek errors are limited to specific video files, then we should look at those videos and check whether they might have some corrupt index entries (depending on the container format).

But if you see that behavior for all videos, then it's most likely a system setup problem.

 

For further investigation, you should 

• copy one of the videos to a local folder
• create a new movie library for that folder
• wait for library scan completion
• play that file from the local library and try to seek

 

If that is working, we should look at the way you've mounted /mnt/kiwisdatacenter

 

What kind of mount is this? Network? Which protocol?

 

My primary suspicion would be that either the mounting provider or the mounting target implementation does not support direct seeking.

[xp-1000 1]

hello,

thanks for your answer @@softworkz.

 

It is a very simple and classic local mount point from a disk in xfs which has been used from 4 years without any problem and there was no changes recently at this level.

 

I make more tests :

- I did not tested enough videos (or rather not enough of different videos formats) but is works on some videos (so the problem does not impact the entire library)

- videos which works and which does not work are on the same library / mount point

- transcoding seems to present the problem on ALL videos contrary to direct play which works on some videos but present the same problem on other

- all videos work (MKV, MP4) with transcoding or direct play if I play them from the start and not trying to move.

- with emby for kodi it works on ALL videos (even with videos which present the problem from the webui)

- according to these tests, it seems that all MKV videos have seek error and all MP4 videos don't have it (except when you select a specific quality instead of auto to force transcoding). I found one exception with a mp4 video which present the same problem than mkv but I suppose it could be a corrupted file (even if playing from the start works fine), here is its specifications :

Vidéo
Title480P H264
CodecH264
Étiquette du codecavc1
AVCYes
ProfilHigh
Niveau30
Résolution848x480
Ratio d'aspect original16:9
EntrelacéNo
Images par seconde23.9759865
Débit1359 kbps
Profondeur en Bit8 bit
Format de pixelyuv420p
Images de référence1
NAL4
Audio
TitleUnd MP3 stereo Default
Langueund
CodecMP3
Étiquette du codecmp4a
Répartitionstereo
Chaînes2 ch
Débit128 kbps
Débit échantillon48000 Hz
DéfautYes
Conteneurmp4

So you were right @@softworkz but I put you on a bad track saying entire library present the problem (sorry I have a majority of mkv).

 

I hope these information could be useful to help me to debug and I still available to make all tests you propose.

 

I am suprised that all videos works with seeking from kodi but not from the webui but I think I will still try to downgrade ffmpeg even if it does not seems to be updated recently, for your information here is its version :

ffmpeg version n4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180831
configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
libavutil      56. 22.100 / 56. 22.100
libavcodec     58. 35.100 / 58. 35.100
libavformat    58. 20.100 / 58. 20.100
libavdevice    58.  5.100 / 58.  5.100
libavfilter     7. 40.101 /  7. 40.101
libswscale      5.  3.100 /  5.  3.100
libswresample   3.  3.100 /  3.  3.100
libpostproc    55.  3.100 / 55.  3.100

Thanks again for your help

Edited December 26, 2018 by xp-1000

[xp-1000 1]

I just downgraded ffmpeg (1:4.1-1 => 1:4.0.2-7) and now all is working fine (mkv, mp4, transcoding, direct playing ....)

[Luke 42077]

Thanks for the feedback. So this is arch linux?

[xp-1000 1]

Hello,

I only downgraded ffmpeg package so I am afraid this is a problem with either new version of ffmpeg itself or emby compatibility with this version.

I think the only fault of archlinux here is to be too updated compared to other distros.

If I am right my downgrading is only a workaround and this problem will impact all other distros when they will use ffmpeg 4.1.

Idealy, someone should test this version of ffmpeg on its installation (different from archlinux) to validate this assertion.

I will be happy to help you in testing and troubleshooting if you need.

[Luke 42077]

No, it wont' impact other distros because we ship our own ffmpeg with all other distros. Thanks for the feedback.

[softworkz 5066]

If I am right my downgrading is only a workaround and this problem will impact all other distros when they will use ffmpeg 4.1.

 

No, it's not a workaround. We're having our own version of ffmpeg that we're delivering and packaging, and this is the only one we're supporting.

[softworkz 5066]

That's almost been a chorus response :-)

[xp-1000 1]

hello,

 

oh ok I did not know ffmpeg was packaged into the emby package for other distros my bad.
And I thought emby package for archlinux was an "official" package maintained by emby team like for other distros.

So now I know that, yes it should only impact archlinux (and other distros not supported officially by emby team).

 

in my opinion you should add a note to the download page https://emby.media/linux-server.html to inform it is not an official package and you advice using an official one if we encounter problems.

 

and so be carreful when you will want to upgrade your embeded ffmpeg version to 4.1 it will probably cause some problems (and this time for every linux users ^^ )

 

thanks for your help and your availability.

[xp-1000 1]

hmm, I am probably blinded but I don't see how mark the topic as "solved" (seems I cannot edit the title, only the first post)

[Luke 42077]

Done, thanks.