CPU pegged why?

[mastrmind11 722]

Throttling enabled, auto thread count, no hardware acceleration.  Linux 16.04.  There is a red transcoding bar on the dashboard but says direct playing underneath.  Transcode logs shows native/copy.  Info attached.  I've seen this happen before with different titles as well.  

 

server.txt

transcode.txt

[Luke 42077]

Looks like just not being reported correctly. It's not direct playing though.

[mastrmind11 722]

Looks like just not being reported correctly. It's not direct playing though.

 

Interestingly when I play this in my browser, it reports "direct streaming" and the audio is being remuxed while the video is being copied (makes sense since it's DTS).  However, the CPU had a 25% load.  So I guess I'm asking why webOS does the opposite of what Chrome does when playing, and why does my CPU peg in webOS but not Chrome?  Thanks

[Luke 42077]

I can't speak for that app I'm afraid, as it's not built by us.

[mastrmind11 722]

No worries, I'll post over there.  Thanks

[mastrmind11 722]

Why does my server use 25% CPU when playing the media in Chrome, while Screenplay completely saturates my CPU playing the same media?

And why does Chrome remux the audio and copy the video while Screenplay does the opposite?

Attaching the logs here as well.

server.txt

transcode.txt

Edited April 28, 2017 by mastrmind11

[kwilcox 78]

Its really about how the underlying WebOS web service negotiates the request.  WebOS can handle DTS but chrome cannot for example.  In your above attachments, I see a screenplay based session starting at 11:01:49.7348 on 2017-04-28 but its an HLS request.  Very odd since you have direct play set to enabled in settings...  In screenplay v1.2.1, I don't offer an HLS session if that is the case:

       if (prefs.directPlay == true)
       { 
           prefs.mimeType = "mp4"
           dom.append("#video", {
                 nodeName: "source",
                 src: emby.getVideoStreamUrl({
                     itemId: item.Id, 
                     extension: item.MediaSources[0].Container
                 }),
                "type": mime.lookup(prefs.mimeType)
           });
       }
       else
       {
           prefs.mimeType = "m3u8"
           dom.append("#video", {
                nodeName: "source",
                src: emby.getVideoHlsStreamUrl({
                    itemId: item.Id
                }),
                "type": mime.lookup(prefs.mimeType)
            });
       }

[mastrmind11 722]

 

Its really about how the underlying WebOS web service negotiates the request.  WebOS can handle DTS but chrome cannot for example.  In your above attachments, I see a screenplay based session starting at 11:01:49.7348 on 2017-04-28 but its an HLS request.  Very odd since you have direct play set to enabled in settings...  In screenplay v1.2.1, I don't offer an HLS session if that is the case:

       if (prefs.directPlay == true)
       { 
           prefs.mimeType = "mp4"
           dom.append("#video", {
                 nodeName: "source",
                 src: emby.getVideoStreamUrl({
                     itemId: item.Id, 
                     extension: item.MediaSources[0].Container
                 }),
                "type": mime.lookup(prefs.mimeType)
           });
       }
       else
       {
           prefs.mimeType = "m3u8"
           dom.append("#video", {
                nodeName: "source",
                src: emby.getVideoHlsStreamUrl({
                    itemId: item.Id
                }),
                "type": mime.lookup(prefs.mimeType)
            });
       }

I might very well be running an older version of Screenplay.  I have it installed on the kid's tv and they skip the update option when it pops up.  I'll check it tonight when I get home and report back.  Thanks