Playback freezing and playing (buffer maybe?)

[aerik 0]

Hi folks!

I have a emby server on rpi4 4gb and my media on gdrive, i'm using rclone to watch my media but on Android TV (Sony X905E) sometimes 1080p media stutter and buffering (i think, don't appear any message, only freeze the movie/tv show) and 2160p stutter all time..

But, if when stutter I pause the video and wait about 15 seconds and play again, no problem at the end the movie (it's very rarely)

In another devices, my android phone for example, 1080p loading is much faster and skip (10s forward and regress) is faster too compared with my android tv

Any help about this?

Tks!

embyserver.txt

[ebr 16184]

Hi.  When in that log did the problem occur?  Was an ffmpeg log created as well?

[aerik 0]

1 hour ago, ebr said:

Hi.  When in that log did the problem occur?  Was an ffmpeg log created as well?

at the end of the log, around 2~3 minutes of playing and freezing

idk about ffmpeg log, how it's created?

[Happy2Play 9780]

5 minutes ago, aerik said:

at the end of the log, around 2~3 minutes of playing and freezing

idk about ffmpeg log, how it's created?

You have disabled the options so you will not get ffmpeg logs.

 

Quote

2020-07-30 17:19:28.184 Info MediaInfoService: User policy for username. EnablePlaybackRemuxing: False EnableVideoPlaybackTranscoding: False EnableAudioPlaybackTranscoding: False

 

[aerik 0]

7 minutes ago, Happy2Play said:

You have disabled the options so you will not get ffmpeg logs.

 

 

Yes, I don't use transcoding, log is correct, right?

[Happy2Play 9780]

Yes, but at the same time just because you don't allow transcoding that could be a issue also (to high of bitrate).  What is the media info for the item being played?  As I was not able to interpret that from the server log.

[ebr 16184]

Please turn that option back on and see if you still have this problem.

Thanks.

[aerik 0]

Honestly, I do not want to use transcode in any way, I believe it is not even worth the test, capable of freezing my raspberry hahaha.

Testing for some time, I did the following test, changed the server address to the local IP (I forgot to mention that I am using letsencrypt + duckdns) and by the local IP there was no stop/buffer at all, until less use of the raspberry CPU, however accessing the server through the letsencrypt address, the problem occurs.

Is the problem related to the SSL protocol with emby or is it related to the use of letsencrypt processing?

The strange thing is that, as I commented, where the crash occurs most often is on TV, on my cell phone playback is much faster, even accessing the server via letsencrypt

 

About the media info:
https://hasteb.in/moqizofi.yaml

 

2 hours ago, ebr said:

Please turn that option back on and see if you still have this problem.

Thanks.

 

12 hours ago, Happy2Play said:

Yes, but at the same time just because you don't allow transcoding that could be a issue also (to high of bitrate).  What is the media info for the item being played?  As I was not able to interpret that from the server log.

 

[ebr 16184]

I would imagine this would come down to the fact that you are routing the traffic through the external IP.

[Luke 42078]

On 7/31/2020 at 11:38 AM, aerik said:

Honestly, I do not want to use transcode in any way, I believe it is not even worth the test, capable of freezing my raspberry hahaha.

Testing for some time, I did the following test, changed the server address to the local IP (I forgot to mention that I am using letsencrypt + duckdns) and by the local IP there was no stop/buffer at all, until less use of the raspberry CPU, however accessing the server through the letsencrypt address, the problem occurs.

Is the problem related to the SSL protocol with emby or is it related to the use of letsencrypt processing?

The strange thing is that, as I commented, where the crash occurs most often is on TV, on my cell phone playback is much faster, even accessing the server via letsencrypt

 

About the media info:
https://hasteb.in/moqizofi.yaml

 

 

 

Remember that Emby will already direct play whenever possible, so there's nothing you need to do to force that. If it is not direct playing, then there's a specific reason for it, and forcing it is likely to cause problems. (See the warning underneath the option).

Can we try turning it on and then go from there? Thanks.