Jump to content

"Playback error - Too many errors. Moving on..."


brennanthl

Recommended Posts

brennanthl

On my TCL Roku I am playing back a specific TV recording of the Tokyo olympics opening ceremony - a somewhat large recording. The recording itself was fine and has no issues playing in VLC player locally on the Emby Server PC. For some reason this recording will not start on my Roku app, and I keep getting the "Playback error - Too many errors. Moving on..." issue.

While the file is trying to load I see the "Retrieving" loading bar go from 0->30% several times and then I hit the error.
All of my other TV recordings, movies, TV shows, etc. play just fine through this Roku app so I'm not sure why this one video file is failing to start. I tried adjusting my transcoding settings and enabling/disabling Throttling and nothing seems to work.


Logs attached, search for "ceremony" to find where it was trying to play the file.

embyserver.txt

Link to comment
Share on other sites

 

Spoiler

2021-07-24 09:16:22.679 Error Server: Error processing request
    *** Error Report ***
    Version: 4.6.4.0
    Command line: C:\Users\xbmc\AppData\Roaming\Emby-Server\system\EmbyServer.dll -noautorunwebapp
    Operating system: Microsoft Windows 10.0.19042
    Framework: .NET Core 3.1.13
    OS/Process: x64/x64
    Runtime: C:/Users/xbmc/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
    Processor count: 4
    Data path: C:\Users\xbmc\AppData\Roaming\Emby-Server\programdata
    Application path: C:\Users\xbmc\AppData\Roaming\Emby-Server\system
    System.InvalidOperationException: System.InvalidOperationException: Response Content-Length mismatch: too many bytes written (1899163 of 1898944).
       at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ThrowTooManyBytesWritten(Int32 count)
       at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.VerifyAndUpdateWrite(Int32 count)
       at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.Advance(Int32 bytes)
       at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponsePipeWriter.Advance(Int32 bytes)
       at System.IO.Pipelines.PipeWriter.CopyFromAsync(Stream source, CancellationToken cancellationToken)
       at Emby.Server.Implementations.HttpServer.FileWriter.WriteToAsync(IResponse response, CancellationToken cancellationToken)
       at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost appHost, IRequest httpReq, IResponse httpRes, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
       at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, ReadOnlyMemory`1 urlString, ReadOnlyMemory`1 localPath, CancellationToken cancellationToken)
    Source: Microsoft.AspNetCore.Server.Kestrel.Core
    TargetSite: Void ThrowTooManyBytesWritten(Int32)

The TooManyBytesWritten error. Running through Kestrel...

https://stackoverflow.com/questions/61351582/response-content-length-mismatch-too-few-bytes-written

I suspect kestrel updates broke implementations... @Luke

Link to comment
Share on other sites

brennanthl

Is the issue that the recording is too large? Anything I can try to update? The file size by the way is 22.5GB. Maybe I can try splitting it into multiple files?

Link to comment
Share on other sites

23 minutes ago, brennanthl said:

Is the issue that the recording is too large? Anything I can try to update? The file size by the way is 22.5GB. Maybe I can try splitting it into multiple files?

Yes. It is the size of the recording. The Roku for some reason cannot direct play it. The playback error correction occurs. It tries to direct stream/remux it and that fails. It then attempts to do a full transcode on it. That fails. It tries the transcoding one last time since the last play position. When that fails and stays at the same point it does not know what else to do. We have told it that when it exhausts all its retries to simply to tell the user it cannot play it and tell them it is moving on. That is all that we can do in this case. Every time playback error recovery happens it tries to resume the file at the exact point it is and hopes the play position moves. When it doesn't these errors just cascade until it moves on.

You might try to run the file through MKVToolNix GUI and just choose Start Remux once you ensure all streams will be copied. That might fix it by changing the container. I believe it is because this is a TS file that is obscenely large. If it were MKV this would alleviate the issue I am hoping.

Edited by speechles
Link to comment
Share on other sites

bcm00re
On 7/24/2021 at 11:14 AM, speechles said:

It is the size of the recording. 

I do not believe that is correct.  I had Emby do a Covert on the recording (selecting "TV" and "keep original quality") and the file it creates is the essentially the same size as the original one -- which seems odd since the new one is mpeg4 and the original is mpeg2 -- but the new one seems to play without any issues.

Link to comment
Share on other sites

1 hour ago, bcm00re said:

I do not believe that is correct.  I had Emby do a Covert on the recording (selecting "TV" and "keep original quality") and the file it creates is the essentially the same size as the original one -- which seems odd since the new one is mpeg4 and the original is mpeg2 -- but the new one seems to play without any issues.

It was correct but with an important part left out.  It is the size of the recording within that particular container (TS).  When you converted it, you changed the container too.

Link to comment
Share on other sites

bcm00re
46 minutes ago, ebr said:

It was correct but with an important part left out.  It is the size of the recording within that particular container (TS).  When you converted it, you changed the container too.

Well I first transcoded the recording to mpeg4 with a .m4v container using the 1080p Roku setting on Handbrake and that one wouldn't play either.  So it appears to be more than just an issue with large TS containers.  I feel like it could be more about something happening in the conversion Emby does versus what Handbrake does.  I was using QSV hardware encoding with Handbrake, and I have Emby Convert setup to use NVEC hardware encoding.

Edited by bcm00re
Link to comment
Share on other sites

M4V is masqueraded as MP4 into the Roku application. The Roku technically treats it like an TS inside an MP4 container and has all the problems and benefits of that mixing.

Link to comment
Share on other sites

bcm00re
5 hours ago, speechles said:

M4V is masqueraded as MP4 into the Roku application. The Roku technically treats it like an TS inside an MP4 container and has all the problems and benefits of that mixing.

So I think you are saying if I am going to transcode something to mpeg4 (for use with Emby via a Roku) then I should use MKV and not M4V as the container.

 

Link to comment
Share on other sites

On 7/27/2021 at 7:03 PM, bcm00re said:

Well I first transcoded the recording to mpeg4 with a .m4v container using the 1080p Roku setting on Handbrake and that one wouldn't play either.  So it appears to be more than just an issue with large TS containers.  I feel like it could be more about something happening in the conversion Emby does versus what Handbrake does.  I was using QSV hardware encoding with Handbrake, and I have Emby Convert setup to use NVEC hardware encoding.

mpeg4 in m4v? I don't recall seeing that before, not a typical combination so I wouldn't be surprised if some players have trouble with it. Yes I would suggest mkv over that.

Link to comment
Share on other sites

bcm00re
16 hours ago, Luke said:

mpeg4 in m4v? I don't recall seeing that before, not a typical combination so I wouldn't be surprised if some players have trouble with it. Yes I would suggest mkv over that.

It is the default on the Roku settings -- as well as most others -- in Handbrake which I thought was a fairly common tool.  What codec encoding do you usually see in m4v containers then?  Anyhow, I will start using mkv (which Handbrake also supports) for future files.

Link to comment
Share on other sites

bcm00re
On 7/29/2021 at 3:55 PM, Luke said:

mpeg4 in m4v? I don't recall seeing that before, not a typical combination so I wouldn't be surprised if some players have trouble with it. Yes I would suggest mkv over that.

It is the default on the Roku settings -- as well as most others -- in Handbrake which I thought was a fairly common tool.  What codec encoding do you usually see in m4v containers then? 

Link to comment
Share on other sites

bcm00re
On 7/29/2021 at 3:55 PM, Luke said:

mpeg4 in m4v? I don't recall seeing that before, not a typical combination 

Really?  What codec encoding do you usually see in m4v containers then? 

Link to comment
Share on other sites

On 8/5/2021 at 12:20 AM, bcm00re said:

Really?  What codec encoding do you usually see in m4v containers then? 

Typically just h264.

Link to comment
Share on other sites

  • 3 weeks later...
unisoft
On 06/08/2021 at 15:09, Luke said:

Typically just h264.

they probably meant that 🙄 It's normally what Handbrake would do for that container.

 

I know, I know, people should be accurate but most call VC1 and h264/x264 mpeg4....

 

can't beat a bit of handbraking :)

Edited by unisoft
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...