Emby Server Running Under Win10 Transcoding .DVR-MS/.WTV Unnecessarily to WMC/Emby-Classic

[latenighter 3]

This is my first post so I hope I've posted to the correct section.  And apologies if I've missed an obvious configuration setting - I have been searching the forums a while to see if anything similar has been reported before but haven't come across anything.

My set-up is a server PC running Emby Server and a separate client PC running Win7 with WMC and Emby Classic.  The server PC has been running Win7 and I'm now testing it with Win10.  Everything has been looking good so far until I discovered that my older (though substantial in number) .dvrs-ms and .wtv files on the server had lost the ability to seek and fast-forward/-backward when the server was running under Win10 and viewed via Emby Classic.  This occurs with Emby Classic using either its internal player or configured to use the WMC player.  I'm currently testing with a clean install, though I encountered the same behaviour with the original upgrade to Win10 from Win7.

When the server is running under Win7, full seek capability is present via the Emby Classic client.  The difference seems to be that Emby Server under Win10 decides to transcode the files to the Win7/WMC/Emby Classic client but when running under Win7 it does not.  This can be seen in the logs I've attached.  I'm using path substitutions on the server under both Win7 and Win10 and it doesn't seem to be a network share permissions issue for direct play as native WMC on the client using the same user ID can play these files with seek/etc. when the server is running under either O/S.  Also .mp4 files containing h264/aac on the Win10 version of the server do direct play with the Emby Classic client.

Is this behaviour that others can replicate and/or have resolved for themselves?

Many Thanks.

 

 

server-63603360289 (Win10).txt

transcode-666663aa-c2fb-4ac2-983a-35178445b0aa.txt

MBClassic-6720169481908421f14b7181edb489f5789f4c (with Win10 server).log

server-63603361126 (Win7).txt

MBClassic-672016f1f46c2b34044836a5db14e8c707dc5d (with Win7 server).log

[Luke 42083]

@@ebr can offer more insight on what's happening from Emby for WMC but most likely the app is not able to access the files directly and that is why it's streaming through the http server. If you look at the detail screen in the web client it will show you the substituted path. That is the path Emby for WMC will attempt to use to access it directly. If that fails, it will stream it instead.

[ebr 16187]

It is almost certainly an access to the media issue as that is the only way that EMC will even attempt a transcode.

[latenighter 3]

Luke/ebr, many thanks for your replies.  You've helped me sort the wood from the trees.

 

With the suggestion to look at what paths the web client on the client PC was showing I discovered that under Win7 the web client gives the path as the network share (ie. \\server\share\...) but under Win10 the path is shown from the server's point of view (ie. J:\...).  This led me to identify that I had faulty path substitution definitions under Win10 (somehow I used "/" for the server source paths instead of "\".)

 

I'm not sure why the .mp4 files were playing without transcoding with the faulty path substitutions but I'll not look into it too deeply.

[Luke 42083]

Because most formats can just stream through the server directly without any reencoding.