Slow direct playback of MP4

[sfatula 207]

Ok am attaching embyserver.log, look around this timeframe:

 

2019-01-08 14:20:42.559 Info HttpServer: HTTP Response 500 to 192.168.3.38. Time: 1159ms (slow). http://192.168.3.39:8096/emby/Videos/3fe48f362df98f81b3167783477697eb/stream.mp4?Static=true&mediaSourceId=3fe48f362df98f81b3167783477697eb&deviceId=C47D39F6-E6D7-4C78-B021-F3349876F1F0&Tag=67721f6586aeeab92f0c83eb740ba893 

 

What happens is wife is watching her video, and, every minute, or less, or more, it pauses playback. No idea why. I suspect these log entries may be a clue. The ATV machine plays Amazon, Netflix, live TV, philo, other recordings, whatever just fine, and never pauses, ever. For some reason, this show gets paused. The server is virtually idle at these times, nothing going on. 

 

Have any clue why this might be?

 

To add more info.... I can play the exact same video on an iPad without issue, no pauses, at the same time, or not. 

embyserver.txt

Edited January 8, 2019 by sfatula

[Luke 42077]

Is this an mp4 that has been synced to google drive? If so then the upcoming new server release will have a number of improvements for that.

 

But even better, the Apple TV app will soon be getting the same video player as the iPad and that point I suspect this issue will go away. 

[sfatula 207]

It is not syncd, local playback, direct. Just to experiment, since this is the only thing we have that uses direct playback, I set the ATV max bitrate so it forces transcoding to see if transcoded, which is used for all other videos we play, will play fine. 

 

Is there a better way to force transcoding other than max bitrate on the client?

Edited January 8, 2019 by sfatula

[Luke 42077]

That is currently the only way to force transcoding.

[sfatula 207]

Worked fine transcoded. Of course, not optimal but will find a way to make it so. Hope the next ATV client works better!

[Luke 42077]

Thanks for the feedback.

[sfatula 207]

So, instead I will do this for each mp4, which is only a few files that we download daily:

 

ffmpeg -i 5987168068001.mp4 -vcodec copy -acodec copy  5987168068001.mkv

 

I will simply incorporate it into the download script. No big deal, surprised that mkv (without any codec change) works while mp4 does not. Oh well. 

[Luke 42077]

You can also send a pm to @@ebr to join the beta program. The new video player will be much more robust and you may not need to convert those anymore.

[sfatula 207]

I appreciate the offer, will be traveling too much to offer much help. Since there is no codec change, it runs a second or 2 so it's not a big deal. I'll patiently wait. 

[ebr 16169]

The original is an mp4 which the native player direct plays already so I'm not sure what will be improved there - will be interesting to see.  After converting to mkv, there will be a benefit, however.

[sfatula 207]

The original does not play, it pauses often and I get the log messages noted. The same video, with only the container changed to mkv, nothing else, plays fine on the same ATV. The mkv says it is direct streaming, I suppose that is the difference? So, it doesn't really use hardly any CPU which is great. 

 

All working fine here. mkv works, mp4 did not. And as a bonus, the embedded tags (description, title, etc.) also work in the mkv. 

[Luke 42077]

Thanks for the info. Normally I'd want to get a copy of one of these files so that we can improve the failure detection in the app and automatically switch to transcoding. But I think we'll just wait for now given that we're about to roll out a new player.