GUID / SSL Issue for remote user swapping from AndroidTV to Unified client on CCwGTV 4K.

[vaise 340]

I did this years back and after a few niggles back and forth, its o=been over a year stable on the unified client - but all my TV's are on my LAN.

I commented to a friend that he was transcoding something I do not, and after comparing the playback settings, decided that he should try the unified client instead.

So he installed the androidTV, then installed the Emby for Android.

After config, he then got a full blue screen saying 'Unrecognised GUID format'

An AI search said this was die to cache stuff being left behind, so he cleared all that n the client, and I cleared the device on the server.

Then he gets a message about the ssl cert, and after clicking OK on that, he gets the guid error again.

Any ideas here ?  The poor guy is recovering from hospital and really needs his access to emby.

Screenshots are attached.

This is why it was not direct playing from the logs - 

2026-06-14 16:20:44.119 Info MediaInfoService-0HNM9NFP6N551:00000005: User policy for x-MikePullan. EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
2026-06-14 16:20:44.119 Info MediaInfoService-0HNM9NFP6N551:00000005: Profile: VideoCodecProfile, DirectPlay=false. Reason=Android-Exo.VideoProfile Condition: Equals. ConditionValue: Main. IsRequired: False. Path: /media/TVShows/Clarkson’s Farm/Season 3/Clarkson's Farm.S03E01.Unfarming.mkv

This is the GUID log issue in the logs I believe - 

2026-06-14 23:22:44.696 Info VideoService-0HNM9NFP6NDPS:00000001: http/1.1 GET http://‌‍‍embyredirect.vaisewilliams.com‌/emby/videos/activeencodings/delete?deviceId=d6626c7e5e9deb8d&PlaySessionId=430d1c84c39045f0ab6f928a4ff138a0&X-Emby-Client=Emby for Android&X-Emby-Device-Name=Family room Google TV&X-Emby-Device-Id=d6626c7e5e9deb8d&X-Emby-Client-Version=3.5.36&X-Emby-Token=‌996943c887b1491a969bb11e9173f3b5‌&X-Emby-Language=en-au. Source Ip: ‌‍‍202.87.173.6‌, Accept=*/*, Host=embyredirect.vaisewilliams.com, User-Agent=Mozilla/5.0 (Linux; Android 14; Chromecast Build/UTTC.250917.004; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/148.0.7778.215 Mobile Safari/537.36, Accept-Encoding=gzip, deflate, br, zstd, Accept-Language=en-AU,en-US;q=0.9,en;q=0.8, X-Real-IP=202.87.173.6, X-Forwarded-For=202.87.173.6, X-Forwarded-Proto=https, sec-ch-ua-platform="Android", sec-ch-ua="Chromium";v="148", "Android WebView";v="148", "Not/A)Brand";v="99", sec-ch-ua-mobile=?1, X-Requested-With=com.mb.android, sec-fetch-site=cross-site, sec-fetch-mode=cors, sec-fetch-dest=empty, priority=u=1, i
2026-06-14 23:22:44.718 Error VideoService-0HNM9NFP6NDPS:00000001: Error processing request
    *** Error Report ***
    Version: 4.9.5.0
    Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
    Operating system: Linux version 6.12.54-Unraid (root@Develop) (gcc (GCC) 15.2.0, GNU ld version 2.45-slack151) #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025
    OS/Process: x64/x64
    Framework: .NET 8.0.25
    Runtime: system/System.Private.CoreLib.dll
    Processor count: 12
    Data path: /config
    Application path: /system
    System.FormatException: System.FormatException: Unrecognized Guid format.
       at System.Guid.GuidResult.SetFailure(ParseFailure failureKind)
       at System.Guid.TryParseGuid(ReadOnlySpan`1 guidString, GuidResult& result)
       at System.Guid..ctor(String g)
       at Emby.Server.MediaEncoding.Api.BaseStreamingService.GetState(StreamRequest request, AuthorizationInfo authorizationInfo, String manifestAbsoluteUri, Boolean requiresOutputPath, CancellationToken cancellationToken)
       at Emby.Server.MediaEncoding.Api.Progressive.BaseProgressiveStreamingService.ProcessRequest(StreamRequest request, Boolean isHeadRequest)
       at Emby.Server.Implementations.Services.ServiceController.GetTaskResult(Task task)
       at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
       at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, RestPath restPath, String urlString, String localPath, String contentTypeInPath, CancellationToken cancellationToken)
    Source: System.Private.CoreLib
    TargetSite: Void SetFailure(ParseFailure)
    
2026-06-14 23:22:44.718 Info VideoService-0HNM9NFP6NDPS:00000001: http/1.1 Response 500 to ‌‍‍202.87.173.6‌. Time: 22ms. GET http://‌‍‍embyredirect.vaisewilliams.com‌/emby/videos/activeencodings/delete?

 

 

 

[Luke 42706]

looks like your reverse proxy is changing a post to a get.

[vaise 340]

Not sure what you mean there ?

The user is able to resolve this by turning their device fully off and on at the wall.  

I have had the same system for ages.  Cloudflare does the app and WAF protection, then when it sees a bit of playback, it redirects those to run at my reverse proxy.

This is the config in Cloudflare that does that -

This system has been in use for many years.

This is the first remote user to change to the new unified app. 

I then got another user to do it, and they got the ssl message only once.  Never the guid one.

I have now directed two more users to do it (reasonably technical), so lets see what happens to them.

 

Edited June 16 by vaise

[Luke 42706]

2026-06-14 23:22:44.696 Info VideoService-0HNM9NFP6NDPS:00000001: http/1.1 GET http://‌‍‍embyredirect.vaisewilliams.com‌/emby/videos/activeencodings/delete?

Emby apps do not send this request as a GET, so something in your chain is misconfigured somewhere.

[vaise 340]

There is nothing specific in the stuff, just forward the requests to the emby server.

Its been working for many years.

This UUID / SSL error is resolved after a reboot of the device once the new client is configured.

My documentation for my users has been tested 6 times now - the first user found the issue, and I updated the doco, they did their other devices and realised its the reboot that fixes it.

I gave the doco to some other users, and they ran through it fine, with the reboot in the right place.

Why would a reboot solve this UUID issue ?

For references, this is the instructions - 6 users are done, another 6 to do (some have more than one device though) :

---------------------------------------------------------------------------------------------------------------

1 - Get the server name, port, your username and your password - if you dont have it, contact me before you start.

 

2 - Access the google play store on your TV/Device.  If this has been updated to the latest release (and no reason why you should not do that), then this can be access by 'Apps' on the top bar, then move to 'search for apps and games'

 

3 - Search for 'Emby', and you will see two hits - The new 'Emby for Android' and the old Emby for AndroidTV'.  Click on emby for android to install that.  They look very similar.  

 

4 - To set this up for my config, you use the infor above (servername, port, then your username, and your password).

 

5 - That should have it working.  And by default it should remember the username and password.  

 

6 - It is possible that the first time you try to play something you get a screen that needs you to click OK to verify the SSL certificate.  Just click OK if you get that - it is a one off.  In some cases, it has been reported that a screen comes up with a GUID error. This may relate to the security methods for the old and new clients.  It seems a full Power off and on are required at this stage to resolve this (note, power off at the wall for 15 seconds, not just the TV as the dongle will still have power).

 

7 - Now you are in, but the client can be optimised to make it better.  Click your profile picture at the top right (fyi, you can upload your own picture if you use the url above).  Then click client app settings, then each of the below - 

 

Click General - Here you can turn off the theme tunes (one of my pet hates but some may love it).  You can also untick 'enable backdrops' if you want a faster scroll through the library. 

 

VIDEO :

Click Playback - Here, set the following - 

Home Streaming Quality - 1080p-6Mbps

Remote Streaming Quality - 1080p-6Mbps

Remote Streaming Quality (Cellular) - N/A - For mobile phones

Chromecast Streaming Quality - 1080p-6Mbps (i doubt anyone casts emby this way)

Prefer Direct Streaming of LiveTV - Tick on.

AUDIO :

Remote streaming Quality - 4 Mbps

Remote streaming Quality (Cellular) - N/A - For mobile Phones

 

8 - You may not know that you can rearrange your installed apps on the androidTV.  I have mine configured like this - 

 

1 - Emby for Android (NEW)

2 - Youtube

3 - TVirl (its an IPTV service for access to all Aus/NZ channels without an aerial needed)

4 - ABC Iview

5 - SBS On Demand

6 - 7Plus

7 - 9Now

8 - 10

9 - TCL ChanneL (if you have a TCL TV, then get hundreds of channels for the world for free)

10 - T-Solo (allow random visitors to stream to TV via bluetooth)

11 - RedbullTV

12 - Many other little used stragglers

13 - Emby AndroidTV OLD (right at the end)

 

Just re-arrange them by holding the centre button on one for a second, then click move.  Arrange them to what suits your viewing habits, but put the old EMBY client to the end until one day you delete it altogether.

 

 

[Luke 42706]

Quote

There is nothing specific in the stuff, just forward the requests to the emby server.

Nonetheless, that is a problem that I would look at resolving.

[vaise 340]

OK - I watched this all into AI, and it said you are correct.  The line in my reverse proxy (that has been there for 8+ years in one shape or another), that AI says is the cause is this - 

# Disable unwanted HTTP methods
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
    return 444;
}
 

It said to change it to this - 

# Disable unwanted HTTP methods (Allowing REST verbs: GET, HEAD, POST, PUT, DELETE)
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$ ) {
    return 444;
}
 

The question remains however - why has this only become an issue now ?  Is it specific to the new android client in some way ?  and why a reboot of the device fixes it ?

 

V. 

 

[pünktchen 1419]

You should change your Cloudflare action from 301 to 308 redirect, because with 301 most clients change POST to GET and do not preserve the request body.

[vaise 340]

13 minutes ago, pünktchen said:

You should change your Cloudflare action from 301 to 308 redirect, because with 301 most clients change POST to GET and do not preserve the request body.

Thanks heaps for that @pünktchen - I have had that set for many years however, this initial config was thought up by @HorsePDF.  

I did (and do not) have the skills to know the exact implications, just that is was working fine for ages.

I googled what you said in AI, and it said you are spot on, so that has been done now.

Thanks again for the assist, and I copied @HorsePDFon this in case he still uses this split connection method (the protection of CF WAF, without the risk of TOS bans).