Unneeded escaping in ToJSON?

[DanAustinGH]

I am trying to use this with Emby. While not 100% certain. it appears that Emby does not like the escape characters being added to the JSON output, which prevents a clean discovery and a failure to integrate the channels into the EPG. Being neither a JSON or Delphi expert, not sure if this is an easy fix or complicated...

True HDHR (works)
{"GuideNumber":"61","GuideName":"kasw wb","VideoCodec":"MPEG2","AudioCodec":"AC3","Favorite":1,"URL":"http://192.168.1.16:5004/auto/v61"},

CetonProxy (Fails, no guide entries created)
{"GuideNumber":"61","GuideName":"kasw wb","URL":"http://192.168.1.1:5004/auto/v61"}

[DanAustinGH]

Handy. The editor re-encoded the escaped url when I posted, making it look correct. Te CetonProxy URL looks like this
http:\/\/:ip-address:port\/auto\/v61

[mpatriche]

Would you be able to provide the Emby log? On Nov 17, 2020, at 5:06 PM, DanAustinGH <notifications@github.com> wrote:  Handy. The editor re-encoded the escaped url when I posted, making it look correct. Te CetonProxy URL looks like this http://:ip-address:port/auto/v61 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#22 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOSF7PGSXHVR5S45FARNJGLSQMM4JANCNFSM4TZJKCHA>.

[DanAustinGH]

The log is not super helpful, but attached at the bottom. One of the lead Emby developers has confirmed that they might not be handling escaped URLs properly. I am not sure that they will spend much time on it, as physical HDHR does not escape its URLs and examining a couple of the other HDHR proxy/emulators, they do not escape URLs either. The little bit of research I have completed suggests that the URL should be escaped in a JSON response, but if the device being emulated doesn't escape them, software that supports that device likely won't either. Emby doesn't use the XML formats, but they look fine. I do wonder if adding the VideoCodec and AudioCodec fields might speed up tuning.

It looks like fixing the discover.json will be fairly straight forward. The TLineup.ToJSON would be a bit harder, but I think I get the gist of that function and making a loop to construct a raw string seems the 'right' solution.

Emby log (no other errors in the log)
2020-11-17 00:15:00.002 Error HttpClient: Error getting response from http://192.168.1.1/discover.json
*** Error Report ***
Version: 4.6.0.5
Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby-server -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-rpm_{version}_x86_64.rpm
Operating system: Linux version 5.4.12-1.el8.elrepo.x86_64 (mockbuild@d6a0ae7d44e9421cadcedb6618508490) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Tue
Framework: .NET Core 3.1.7
OS/Process: x64/x64
Runtime: opt/emby-server/system/System.Private.CoreLib.dll
Processor count: 16
Data path: /var/lib/emby-server
Application path: /opt/emby-server/system
System.Net.Http.HttpRequestException: System.Net.Http.HttpRequestException: Connection refused
---> System.Net.Sockets.SocketException (111): Connection refused
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
Source: System.Net.Http
TargetSite: Void MoveNext()
InnerException: System.Net.Sockets.SocketException: Connection refused
Source: System.Private.CoreLib
TargetSite: Void Throw()
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)

[mpatriche]

Cool...thanks for posting it. Just want to compare it with my setup. I also use Emby and channel discovery works...curious what the difference is.

[mpatriche]

Would you be down to do a quick Zoom conference? If so, my email is under my profile. Would like to check something out on your setup.

[DanAustinGH]

I (very) rarely use zoom, but have it up and running. I can email you a meeting id if that was your thought

[DanAustinGH]

User error. Emby can ask physical HDHR for just the channels marked as Favorite, and I assumed that the selection process in the GUI was in fact setting favorites, not setting 'only these channels'. Clearing the 'Favorites Only' option in Emby has is working as expected. Might be worth a foot note in the documentation to not set that option if using Emby.

[mpatriche]

Nice. It was good talking....and glad it was a simple fix. 👍