We call SbDrmSessionUpdateRequestFunc() to request license, then CDM tries to parse keys from the string in SbDrmUpdateSession(const void* key), but an error occurs in CDM.
And we check the code in CDM, it is dued to unmatched format when parsing the string.
[cobalt]>[INFO:../../../core/src/cdm_engine.cpp(295)] CdmEngine::AddKey
[cobalt]>[ERROR:../../../core/src/crypto_session.cpp(529)] CryptoSession::LoadKeys: OEMCrypto_LoadKeys error=29
[cobalt]>[ERROR:../../../core/src/cdm_engine.cpp(344)] CdmEngine::AddKey: keys not added, result = 99
[cobalt]>[ERROR:../../../cdm/src/cdm.cpp(670)] Unexpected error 99
Is the process related to the version of Protobuf? As our CDM statically use a lower version (2.5.0) than Cobalt Release 9's Protobuf (3.0.0).
If it is not related to Protobuf version, what may influence the content of key passed by Cobalt?
Cobalt doesn't process key requests or responses in any way (it treats them as opaque blobs), so the version of Protobuf that Cobalt uses should be irrelevant to this issue.
I suggest to compare CDM responses you are getting through Cobalt and another browser. I also suggest you to contact Widevine team and verify that the version of Widevine client you are using is compatible with YouTube (I presume this is why you are doing Cobalt port).
Related
am getting this type of error while moving to NET 6.0
Grpc.Core.RpcException : Status(StatusCode="Unknown", Detail="Exception was thrown by handler. OperationCanceledException: Read was canceled on underlying PipeReader.")
package: Google.Protobuf v (3.21.12)
NET 6.0
I tried different solution while downgrading the version of the package
but still facing the same issue
Message SOMETHING doesn't provide the generated method that enables WriteContext-based serialization. You might need to regenerate the generated protobuf code.
This comes from here
The problem here is that you're using (significantly) older generated code which does not support the pipe APIs; you should regenerate the code from the .proto, after updating protoc or Grpc.Tools or whatever mechanism you've used to turn the .proto schema into C#. This must include any nested message types; the SOMETHING in the above message tells you about any that are still needed.
I want to create a straightforward extension for Firefox.
User hovers over some word on any page
Pull the dictionary definition of that word from a file inside the extension
Display it while still hovered
I am new to Firefox add-ons and WebExtensions, so here's what I'm wondering:
I want the dictionary file(s) used by the extension to be local, instead of referring to some online website each time.
Any given user might be interested in a different part of the entire dictionary (it contains entries in different languages, users might only want their own 1 or 2 languages) so I want to avoid forcing every user to download the entire dictionary base.
The way I have seen similar add-ons handle that before Firefox 5.* is that they offer the search-and-display add-on separately from the dictionary files which are each available as add-ons in their own right, only actually doing stuff if you have the master add-on installed.
However, none of those examples seem to have been updated for the WebExtensions API and do not support more recent versions of Firefox.
I have also been unable to find how to communicate between web extensions so far.
My question being, how can I share information between 2 or more coorperating extensions to achieve what I described.
And actually, if this seems really stupid for some reason I'm unaware of, do point out any more reasonable alternatives that allow me to handle the dictionary files separately from the main extension.
Possibly related questions I found:
Communicating between 2 Firefox Add-Ons (Cross-Extension Communication)
This one is from 2010 however, thus out of date as far as I could tell.
Mozilla Addon Development - Communicating between windows with different domains
Kind of a similar situation, but they want to pull the definitions from an online source, rather than a local one.
The closest thing I found on the Mozilla browser extension website is communicating between add-on and some native applications, not quite what I need I think.
Communicating between add-ons is a normal part of the functionality of runtime.sendMessage(), runtime.connect(), runtime.onMessage, and runtime.onConnect.
Both runtime.sendMessage() and runtime.connect() have as their optional first parameter:
extensionId
For runtime.sendMessage(), this is:
string. The ID of the extension to send the message to. Include this to send the message to a different extension. If the intended recipient has set an ID explicitly using the applications key in manifest.json, then extensionId should have that value. Otherwise it should have the ID that was generated for the intended recipient.
If extensionId is omitted, the message will be sent to your own extension.
For runtime.connect(), this is:
string. The ID of the extension to connect to. If the target has set an ID explicitly using the applications key in manifest.json, then extensionId should have that value. Otherwise it should be have the ID that was generated for the target.
Both runtime.onMessage, and runtime.onConnect provide a sender property or parameter, either with the message, or as part of the port. This parameter/property is a runtime.MessageSender which includes an id property which is:
id
string. The ID of the extension that sent the message, if the message was sent by an extension. If the sender set an ID explicitly using the applications key in manifest.json, then id will have this value. Otherwise it will have the ID that was generated for the sender.
Note that in Firefox, before version 54, this value was the extension's internal ID (that is, the UUID that appears in the extension's URL).
does NSURLSession send user-agent automatically has an answer that describes the NSURLSession default HTTP User-Agent string for iOS. I want to know the default format for macOS (preferably with supporting documentation), and the default format for NSURLConnection as well.
I'm seeing some very old User-Agent strings on my site, and I'm trying to verify potential sources.
It follows that same code path as the iOS one.
nsurl/887 CFNetwork/887 Darwin/17.0.0 (x86_64)
$(CFBundleName)/$(CFBundleVersion) CFNetwork/$(CFNetworkVersion) Darwin/$(DarwinVersion) ($(Architecture))
If the program doesn't have a CFBundleName, its executable name is used instead. For missing CFBundleVersion, (unknown version) is used. This typically occurs when a command line tool without a bundle calls CFNetwork.
I don't think there is any documentation for this, and the default User Agent should be treated as a debugging facility instead of a specified behavior.
I'm trying to repackage a proprietary app that consists of several libraries, COM interfaces and a COM automation server.
My stripped down distribution doesn't work.
Using the function call monitor (RohitLab API monitor), I've established that a call to
IGlobalInterfaceTable::RegisterInterfaceInGlobal returns a zero value for the cookie in the stripped version; while in the correct full install, it always returns 256.
The documentation says that "The value of an invalid cookie is 0."
It is very interesting, but the application ignores the zero return value and uses 256 instead (always?) for IGlobalInterfaceTable::GetInterfaceFromGlobal, and doesn't work later, because it's trying to connect the NULL pointer returned for the interface to other COM objects.
It doesn't crash though, just wouldn't work as expected.
Question:
Why would RegisterInterfaceInGlobal return a zero value? The dll which contains type library for this interface is registered using regsvr32. Btw, it seems to load another dll which is also a COM library, but without a type library in it.
I'm using DotNetKit 1.2.6.5 and SagePayIntegration.Validation() is rejecting a customer email that uses the new .online domain (eg: foo#bar.online) with
CustomerEMail is invalid.
Is this fixed in 1.2.6.7 or is the source code for SagePay.IntegrationKit.DotNet.dll available somewhere so I can fix it?
Despite access to the source code (many thanks to #DavidG) SagePay Support have confirmed that the actual Gateway does not support all these new domains - so even if I modified the DotNetKit it would still be rejected by the Gateway.
SagePay support were very helpful but ultimately the
"... email domain foo#bar.online is not yet supported on our gateway.
We run development sprints continuously and although there are some
domains we may not yet support, we look to in future, dependent on
impact and demand..."
The SagePay Integration Kit uses this regex to validate email addresses:
[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*#(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+(?:[a-zA-Z]{2,4})\b
Which does unfortunately not allow extra long TLDs. Fortunately I have the source code for the kit and I've added it to my GitHub account (along with a bug fix which is why I had to get it in the first place as SagePay are not updating it). You can find it here:
https://github.com/WiredUK/SagePay.IntegrationKit
And the Regex you need to edit is this file:
https://github.com/WiredUK/SagePay.IntegrationKit/blob/801f61cf965c391a98a025aa632949719084cef0/ApiRegex.cs
For info, you need to edit the very last part of the expression from 2,4 (which matches 2 to 4 characters in the TLD) to allow more, for example 2,30.
Edit: And just because I can, I opened an issue and fixed it.