Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log DRM provisioning/network requests to AnalyticsListener #5399

Open
noamtamim opened this issue Jan 16, 2019 · 6 comments
Open

Log DRM provisioning/network requests to AnalyticsListener #5399

noamtamim opened this issue Jan 16, 2019 · 6 comments
Assignees

Comments

@noamtamim
Copy link
Contributor

noamtamim commented Jan 16, 2019

I'm implementing AnalyticsListener in ExoPlayer 2.9.3 and I've noticed DATA_TYPE_DRM is not used in onLoadXXX events for DRM loads. Looking at the code, the only reference to this symbol is in HLS-AES encryption keys.

I believe POST events to license servers should include this type.

@ojw28
Copy link
Contributor

ojw28 commented Jan 16, 2019

I don't think key requests cause the onLoadXXX methods to be called. So perhaps this is a feature request to do so, rather than an issue where the correct constant isn't being used?

@noamtamim
Copy link
Contributor Author

Looking deeper into this, indeed onLoadXXX methods are indeed not called for key requests.

Anyway, the documentation says this value is "A data type constant for drm or encryption data", and in reality it's only used for retrieving AES keys.

The type appears in MediaSourceEventListener.MediaLoadData.dataType.

Bottom line -- I guess this issue can be a feature request instead.

@ojw28 Should I open a new issue or rename this one?

@ojw28 ojw28 changed the title C.DATA_TYPE_DRM is not used for DRM actions Log DRM provisioning/network requests to AnalyticsListener Jan 17, 2019
@ojw28
Copy link
Contributor

ojw28 commented Jan 17, 2019

[Note: We should wait until after planned DRM refactoring before doing this]

@noamtamim
Copy link
Contributor Author

@ojw28 is there a roadmap to this refactoring, so we know when to expect major API breakage?

@kgrevehagen
Copy link

[Note: We should wait until after planned DRM refactoring before doing this]

@ojw28 Will DRM refactoring also fix #2394 and #5619 ?
Any news(or tickets or description) on the status of this refactoring project? I understand that you can't give any dates or anything, but e.g. will it happen this year or is that not doable at all?

Would love to know that so I can decide whether or not to try to implement a temp solution or if I should wait for you.

Thanks in advance!

@tonihei
Copy link
Collaborator

tonihei commented Jul 4, 2019

@kgrevehagen
Both issues will hopefully be addressed by the refactoring. We are actively working on it, but can't give any concrete release dates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants