Can not skip\forward\etc

[sonusfaber 17]

Hello

I am noticing that I am unable to rewind or fast forward when I play a movie from the Emby app on both Android and Android TV.

On the other hand it work always fine on the PC\Chrome browser and also works perfectly on any Android device using the Chrome browser

So... same Android device, FF\REW do not work by the app, but work by the Chrome browser

Even if I am noticing such strange bahaviour just now, while I am using Emby since years and years... anyway I update the Emby server version to 4.8.11.0 but no improvement

 

Thanks

embyserver (1).txt

[sonusfaber 17]

Adding another piece to the story...

If I try to resume a movie, it always starts again from the beginning: yesterday I stopped to play a movie... in the Emby menu it is displayed as continue watching, but restart from the beginning.

Edit: I understood that in some cases FF\RW\resume work and looking at the NERD STATS I can say that when the stream is transcoded, then FF\RW\resume work.

The problem is that in almost 90% of the cases, it goes with direct playing without trasncoding.
So 2 workaround found:
1) set the quality in the app a step lower than the direct playing bitrate... this force the server to trasncode, or
2) there is a setting in the app that correct playback and also this force the trascoding

The problem is that both 1) and 2) are settings specific for that playback session. Just changing the movie needs to re apply the settings.

Is there any way to force always transcoding in the server?

 

 

Edited July 2, 2025 by sonusfaber

[visproduction 315]

Sonus, If the media file has some corrupted error, then some players will auto adjust and playback and others will not.  This seems to fit your description.  The converted version plays back correctly, perhaps because the errors have been fixed by the conversion.  Android has issues and Chrome does not, also perhaps becuase Chrome brower player auto fixes the data problem in the media and Android does not.

Just because a media plays back in one software / browser, means the media file has no issues.

A way to test this is to use a sample media the same size, that is created without errors for testing systems. https://sample-videos.com/

Another way is to run an error check on the media that is having problems using ffmpeg full install or other software.

If you can eliminate the media from being the problem, then the issue can be more in the Emby server code.  If you don't run these tests, then you won't know.  Quite often the media has issues and people think it's fine because it seems to play back on another player.

Hope that helps.

 

[sonusfaber 17]

@visproduction

Most problably I am missing some technical details how this process works.

So let me ask... at the and of the story, when I watch a movie by using Emby App on Adroid or Android TV... who is decoding and playing the moview? Is it Emby app or what?

Anyway I can confirm: I have 12 TB of movies and NEVER NEVER in years had such problems... I am experiencing such issue in the last months.

[visproduction 315]

Sonus,

Typo from above post: Just because a media plays back in one software / browser, does not mean the media file has no issues.

Emby either offers direct playback or transcodes to fit, whatever the end player needs.  To know this, there is some communication from Emby to check what the end player, browser, mobile, TV and whatever connection is available and can playback correctly.

I don't know the exact code, I am guessing, based on reading through forum posts, there is a combination of a DLNA (Digital Living Network Alliance) profile that matches a code query of what player is working and possible a test for bandwidth to help pick a transcoding that can happen in real time and not cause buffering.  In other words, a quality intensive transcoding that takes 5 seconds for every 1 second of media time is not acceptable, so the transcoding flips downward in either size or quality until a real time transcoding appears possible and then Emby picks that setting and starts transcoding.

If someone sees an error in the above, please post a correction.

So either direct play or transcoding can run into some issues.  If the connectivity speed changes and  Wifi has all sorts of possible issues that can change the bandwidth up and down.  I think the standard setting might be something like 75% of what is tested to be safe.  So, if 1000K/sec tests OK, direct only happens when 750K/second can transfer 1 second worth of media.  Similarly, transcoding drops to 75% of tested bandwidth that might be available and automatically adjusts which exact transcoding settings are used to keep that bandwidth rate.  I believe this is to cushion any slowdown in bandwidth so the media plays smoothly without buffering, even if Wifi or network traffic or remote location has some temporary connection problem.

Great, but this start setting sticks as the choice from Emby to delivery either direct or transcoded content.  It is not tested again and updated.  At least that is what I read in a post about 8 months ago.  I haven't seen any new info about testing mutiple times during a session.

Forward and rewind:  So, if the media delivery is progressing in real time at say 75%, then perhaps a minute or two forward might be available.  We all have seen the player timeline on various media sites move forward slowly.  If you jump ahead 10 minutes, everyone is used to expecting a delay for the timeline transcoding to change and rebuffer.  Then if you jump back 5 minutes, well it has to do it again.  There is some time delay from the user sliding the timeline, the end player software picking up this change, sending the request through the network / Internet back to the server, the server recognizing the request, pausing the media stream, moving to a new location on the time line of the original media, starting either to direct play or transcode and then waiting for the buffer to fill, and then sending the new media stream at the new timeline location to the end user, back through the network, received and processed by the user's player and software and then delivered to a visual and audio updated timeline playback.

The further the user is removed from the server and whatever limits are on the network traffic and perhaps Wifi data update issues, the more time all these steps can take.

If the original media has any timeline errors, then either the end player corrects for these issues or not and refuses to play at all.  Many medias have timeline and other errors and many players take additional time to resolve this before playback.  Normally, a fix for any media to resolve timeline or corrupt data is to test, fix and remux the media.  As I understand, Emby streams the media and doesn't necessary fixes anything, except when it transcodes.  So, direct play gets no correction, but transcoding does.

It's possible if the original media has corruption and timeline errors in the metadata, that direct play will have a problem and going forward or rewind could fail completely.  Transcoded from this original problem media, would work better, but take some time to step through everything mentioned above.

Did I miss something or are my assumptions incorrect?  If anyone knows the code better, please post a correction.

Sonus, if this is suddenly happening now, perhaps the buffer percentage that, I think, was at 75% changed to 90%, which might cause the issues you notice.   Possibly some other direct play or transcode settings change pushed the delivery speed too much and you might run into buffering.  Maybe there was a transcode option default that changed that works for some hardware, but not good for your setup.

It's important to pin down exactly what is going on in your case.  That's why I mentioned testing with sample videos to eliminate the possibility that you have large media files with some hidden errors, you've never noticed.  Another step is to recreate the problem with test media and include a log of what is happening.

Wow, too many words again... Hope this makes sense and maybe helps.

[sonusfaber 17]

@visproduction

tested some videos where I can not FF\REW\etc. with FFMPEG and all of them are error free

[visproduction 315]

Aha, good.  So now it's something involved with direct play bandwidth.  Something has changed.  Can you replicate the problem with a media test file and create a log?  There is DLNA debugging option in Admin.  That might be interesting to see.  Again, I am guessing, at this point.  I have not dug this deep before.  Someone else needs to look at the logs.

It occurs to me also that some media files have 30 graphic based subtitles.  It's very typical with any media from a blu-ray disc.  There is no file error, but this is a mess to contend with when delivering direct or transcoding.  The entire media needs to be scanned and then some rule for what happens to all those subtitle graphics then kicks in.  It can cause all sorts of issues.  I think jumping ahead in a timeline with 30 subtitles might cause a delay.  Does Emby need to reaccess all the graphic subtitles at the new timeline location? 

MKVtools can remux audio and video and skip any unneeded subs.  It typically takes about 2 minutes for 2 hours of media.  You can do many videos at a time.  That might help.  If you try a test media file and it works fine for forward and rewind, then we are still looking at something different going on with your media.  Does that make sense?

 

Edited July 4, 2025 by visproduction

[sonusfaber 17]

Moreover, I am not a frequent user of fast forward... so even if I NEVER noticed such issues before, I can not guarantee 100%... but... for sure I user every day "resume playing". I am used to watch a movie maybe in 3 o 4 days... so I stop the play during lunch on the tables and I resume playing the day after in the evening from the Android TV and it always worked, but no more now and I did not changed ANTYTHING, but... experiencing such issues... I upgraded Emby server to the latest version (it runs on Ubuntu).

@visproductionmany thanks for the help, but... using the test files the clip with the rabbit... just to be clear... these run fine.

P.S.: I see that: if I play the movie from a smartphone connected to the home WiFI... I can not FF\REW\resume, the same device connected to my home via VPN and a very very poor mobile network... then it works... It is simple... over poor bandwidht the server re-encode, with home WiFI it dooes not re-encode. But it happens also with nVidia Shield wired to the emby server @ 1 Gbps

Tell me exactly what I have to do for the test and I will do.

[visproduction 315]

Sonus,

1) First easy test I would try is to remove all the subs from one of one media file and then try the new media version without subs and see if that helps.

MKVTools Can do this.  It makes a new file.  It's quick.

Hopefully, that is the culprit.  I would post back that this happens and that sub removal helped.  That can be a feature request.  Emby would be better, if it could handle such things more easily automatically.

2) If you still have issues and the new media version with no subs still causes a problem.  Maybe turn on: Admin dashboard / Devices / DLNA / Checkbox - Enable DLNA debug loging

Run the new test file that still has issues and create the issue on your player.  Then stop,  go to Admin dashboard / Emby Server / Logs and grab the latest log and DNLA logs

Then post exactly which Emby version, which OS and what hardplayer ran into the fast forward / rewind issue.  Mention the media content is a media that you already removed the excess subs and still runs into this issue.  Also, maybe grab a screen shot of your admin transcoding settings.

 

3) Resume after 2 or 3 days.  That's another issue.  It may or may not need a different code fix.  Certainly mention that in your results and maybe test for it with a separate set of logs.

 

Edited July 4, 2025 by visproduction

[sonusfaber 17]

@visproduction

1) removed subs, problem still there.

3) I mean that resume always worked ALWAYS... even after many days... let me say... so many days that the GUI becomes full of items (children are used to start something then stop and jump elsewhere) Now does not work anymore on the movies where also FF\REW fail, even after 5 minutes from the stop to resume.

2) will do later today

[sonusfaber 17]

@visproduction

Enabled DNLA logging, log file attached. The last movie played (Quake) is the movie with issue. no SUBS inside.

P.S.: all the movie files are stored on a local file server. Emby server mounts it in red only. I have also a Xiaomi Mi Box where I installed Kodi and also Emby.
The very same movie is OK with Kodi

Anyway: Emby server runs on Ubuntu 20.04.3
Emby server: 4.8.11
Emby app on the smartphone and tablet: ver. 3.4.74
Emby app on nVidia Shield Android TV: 2.0.93g

[visproduction 315]

Sonus,

Don't forget to attach the log files.

[ebr 16173]

15 hours ago, sonusfaber said:

Emby app on nVidia Shield Android TV: 2.0.93g

Hi.  That's extremely old.  I would update it or install the standard app.

[sonusfaber 17]

@visproduction

@ebr

Updated the app on the nVidia Shield. The app on the smartphone and tablet were both updated. No improvement at all.

Attached the log.

The movie is "terremoto del secolo" or "the quake"

embyserver (2).txt

[Luke 42078]

Hi, we're looking into it. Thanks.

[sonusfaber 17]

@ebr

@Luke

Can you please explain what is the difference between playing a movie inside the Emby app and playing using the Chrome browser on the same Android device?

[Luke 42078]

6 hours ago, sonusfaber said:

@ebr

@Luke

Can you please explain what is the difference between playing a movie inside the Emby app and playing using the Chrome browser on the same Android device?

In the browser you are using the browser's video player, which is very limited in what formats it supports. In the android app we've embedded a much  more robust video player that can handle more formats.

It is probably just having difficulty with your .avi files. There is a playback option in the app to force server transcoding for .avi so I would try activating that.

[sonusfaber 17]

@LukeInteresting. Thanks for the explanation.

I am aware about the app's settings you mention. I tried to eneable\force the transcoding every kind of format, but no improvements.

So far, the only working workarounds are:
- telling to the Emby app I am having troubles or
- setting on the app a quality lower than the source format

Anyway the most strange thing is that I have been using Emby since years and this is the very very first time I experience such issue with so many movies.
Moreover I am not the one that upgrades server\client release as soon they are available: if what I have works, then I do not upgrade and I am sure I did not upgraded anything.

Edited July 7, 2025 by sonusfaber

[ebr 16173]

7 hours ago, sonusfaber said:

setting on the app a quality lower than the source format

If that works, then the setting Luke suggested should work too.  It does the same thing...

[Luke 42078]

Quote

I tried to eneable\force the transcoding every kind of format, but no improvements.

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[visproduction 315]

On 7/5/2025 at 9:20 AM, sonusfaber said:

@visproduction

@ebr

Updated the app on the nVidia Shield. The app on the smartphone and tablet were both updated. No improvement at all.

Attached the log.

The movie is "terremoto del secolo" or "the quake"

embyserver (2).txt 2.01 MB · 1 download

FYI: This log shows the following number of entries:
.avi 1,560 items

.mkv 10,945 items

.mp4 260 items

Time line from: 2025-07-05 00:00:00.027
                      to: 2025-07-05 16:18:01.485  

(16 hours 18 minutes)

I would guess this large number of media content.  Is this being added to the dbase?  If that is true, why wouldn't this also cause playback to be limited, buffered or not play at all while these 12, 765 items are being processed?  Can this huge amount of content be causing the problem?

[sonusfaber 17]

9 hours ago, ebr said:

If that works, then the setting Luke suggested should work too.  It does the same thing...

I understood, but I enabled ALL the flags for all formats... and nothing changes!
This movie is coded with H264, mkv container.

 

1 hour ago, visproduction said:

I would guess this large number of media content.  Is this being added to the dbase?  If that is true, why wouldn't this also cause playback to be limited, buffered or not play at all while these 12, 765 items are being processed?  Can this huge amount of content be causing the problem?

Ah... got it... such large numbers are all the movies in my libraries.

@Lukehere the server log. is it enough?

 

Thanks

embyserver (3).txt

[Luke 42078]

Hi, we're looking into it. Thanks.