HDR and DV movies are freezing on home network

[wakeboarder141 29]

Just now, rbjtech said:

1GB/sec is easy - 10GB/sec is not.

I'll leave it with you.

I'm meaning 1GB/sec, not 1Gb.  I haven't messed with using multiple ports like that yet.  My brain just defaults to wanting to use the 10Gb since it is the biggest number. I am happy to try whatever you think will be the best way. 

[wakeboarder141 29]

On 3/5/2023 at 1:21 AM, rbjtech said:

ok - so lets try this.   Copy a troublesome file from Jarvis onto Skynet - and then try and play back that file from Emby via that library instead.

I moved some things around to test, and created a new library directly on Skynet.  I have the same playback problems even when accessing the files on the same NAS. 

[wakeboarder141 29]

Anyone have any ideas?  I seem to be abandoned here.

[Luke 37233]

Can you try our standard android app again and let us know how that compares?

https://emby.media/emby-for-android.html

Thanks.

[wakeboarder141 29]

20 hours ago, Luke said:

Can you try our standard android app again and let us know how that compares?

https://emby.media/emby-for-android.html

Thanks.

The behavior is the same.  I can get it to play for a few seconds to a minute, and then it starts freezing for 5-10 seconds at a time, playing a few seconds, repeat.  After stopping the frozen show, trying to replay the episode results in Emby just hanging, and not doing anything after the controls disappear.  I can press back and it will return to the last page instantly as if it wasn't even trying to do anything.

embyserver.txt

[visproduction 125]

I would guess you are hitting the server too hard with your encoding settings.  The http 204 no content at the end of your log is perhaps your server not being able to sort out the stream of packets and browser cache has filled up. If you want high resolution results you have to allow both encoding and packet handling to work without pinning your CPU at 100%.  Sorry, I did not read everything in the post.  This is my guess.

See: https://httpwg.org/specs/rfc9110.html#status.204
 

Quote

15.3.5. 204 No Content

The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response content. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.

For example, if a 204 status code is received in response to a PUT request and the response contains an ETag field, then the PUT was successful and the ETag field value contains the entity tag for the new representation of that target resource.

The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.

For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.

A 204 response is terminated by the end of the header section; it cannot contain content or trailers.

A 204 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

 

Edited March 12, 2023 by visproduction

[wakeboarder141 29]

3 minutes ago, visproduction said:

I would guess you are hitting the server too hard with your encoding settings.  

As far as I know my cpu is used very little as my files all direct play without transcoding.  Is that what you are referring to?

[visproduction 125]

WB,

Hmm, heavy CPU  / GPU would support the idea that your settings are too high. I think 204 error code means something is timing out.  Perhaps some cache size issue inside Nvidia card that you don't see.  Or TCP packets need to render and clear.  If a player or browser cache fills up and does not accept further packets, then some packets could be refused / not acknowledged and have to be resent.  If there is no ack packet returned then the streaming app will resubmit the packet again.  If there is enough of this the packets get out of order and at some point the packets that came in after the missing packet would be discarded.  Windows TCP packet management has to work perfectly with Nvidia to stop this problem.  Maybe it only shows up when the res is so high that the cache needed, for the number of packets per second, goes past what the player can clear.  If the drivers are up to date and testing with the android app does not help, then I think the next step is to turn down your encoding resolution.

Quite often heavy subtitles in the file can also cause and halt playback, even though you don't have subtitles turned on.  Have you tested with a clean test video with no subtitles and no extra audio running with AAC audio?  It's important to use a professionally made test video (available online).  Any other video master may have all sorts of meta data issues and multiple errors or excessive data that dedicated players like VLC can manage, but these videos would cause problems with TV cast or browser playback.  Just being able to view a video on a dedicated player doesn't tell you anything about the quality of the media.  This is why people use test videos.

Hope that helps.

Edited March 13, 2023 by visproduction

[roaku 797]

On 3/12/2023 at 10:58 AM, visproduction said:

I think 204 error code means something is timing out...

 

204 is a success code, not an error code.

Edited March 13, 2023 by roaku

[wakeboarder141 29]

6 hours ago, visproduction said:

WB,

Hmm, heavy CPU  / GPU would support the idea that your settings are too high. I think 204 error code means something is timing out.  Perhaps some cache size issue inside Nvidia card that you don't see.  Or TCP packets need to render and clear.  If a player or browser cache fills up and does not accept further packets, then some packets could be refused / not acknowledged and have to be resent.  If there is no ack packet returned then the streaming app will resubmit the packet again.  If there is enough of this the packets get out of order and at some point the packets that came in after the missing packet would be discarded.  Windows TCP packet management has to work perfectly with Nvidia to stop this problem.  Maybe it only shows up when the res is so high that the cache needed, for the number of packets per second, goes past what the player can clear.  If the drivers are up to date and testing with the android app does not help, then I think the next step is to turn down your encoding resolution.

Quite often heavy subtitles in the file can also cause and halt playback, even though you don't have subtitles turned on.  Have you tested with a clean test video with no subtitles and no extra audio running with AAC audio?  It's important to use a professionally made test video (available online).  Any other video master may have all sorts of meta data issues and multiple errors or excessive data that dedicated players like VLC can manage, but these videos would cause problems with TV cast or browser playback.  Just being able to view a video on a dedicated player doesn't tell you anything about the quality of the media.  This is why people use test videos.

Hope that helps.

Thanks for your suggestions.  Unfortunately, I am not using a browser, or Windows, or an Nvidia graphics card for anything related to Emby.  I have an Nvidia Shield that is streaming from my Synology NAS.  The CPU shouldn't be doing much of anything as these files are direct playing, not transcoding.  The Shield also supports direct playback of all of the formats I'm using, and I am able to play larger, higher bitrate movies without a problem.  It is something specific to Dolby Vision.

[Luke 37233]

Hi, are you still having an issue with this?

[wakeboarder141 29]

2 hours ago, Luke said:

Hi, are you still having an issue with this?

Yes, it has not changed.  It still starts freezing up after a short amount of play. I can get it to play for a few seconds to a minute, and then it starts freezing for 5-10 seconds at a time, playing a few seconds, repeat.  After stopping the frozen show, trying to replay the episode results in Emby just hanging, and not doing anything after the controls disappear.  I can press back and it will return to the last page instantly as if it wasn't even trying to do anything.

[rbjtech 4324]

On 14/03/2023 at 00:11, wakeboarder141 said:

The Shield also supports direct playback of all of the formats I'm using, and I am able to play larger, higher bitrate movies without a problem.  It is something specific to Dolby Vision.

If you are able to play higher bitrate files - I suspect it's the files themselves.

options - remux the files to recreate them (ffmpeg -i input.mkv -c:v copy -c:a copy output.mkv) or re-rip them with whatever you used in the first-place (makemkv perhaps).

AndroidTV has zero issues with DV files (all profiles, 5,7 or 8 - I have played ~100's of them with emby without issue.

Edited March 22, 2023 by rbjtech