CPU pegged why?

[mastrmind11 717]

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 37084]

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

[mastrmind11 717]

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 37084]

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

[mastrmind11 717]

No worries, I'll post over there.  Thanks

[mastrmind11 717]

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 717]

 

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