-
Benachrichtigungen
You must be signed in to change notification settings - Fork 373
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
currentMediaItem is empty when a CastPlayer is being used #25
Kommentare
This is a known issue which becomes more sever with AndroidX Media3 For right now I'm afraid I can't really give a better advice than that you need to maintain your own list of Somewhat aside: I think an approach to have a -- There is an unwritten contract that a
|
Thank you very much @marcbaechinger for the idea of the custom Thanks again! |
@spun Could you elaborate how you managed to solve the empty |
Hi @NielsMasdorp. Unfortunately, I decided to wait until the issue is fixed. I'm currently running a modified version of the library with some changes made to You could try the custom If you can wait, when this issue is fixed, we should be able to at least retrieve the |
@spun Thanks for the update. In the meantime i've decided to tackle the problem as well. I am currently working on my own implementation of a custom |
The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline. When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`. Issue: #25 Issue: google/ExoPlayer#8212 #minor-release PiperOrigin-RevId: 460325235
The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline. When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`. Issue: androidx/media#25 Issue: #8212 #minor-release PiperOrigin-RevId: 460325235
Issue: #25 PiperOrigin-RevId: 460476841
Issue: androidx/media#25 PiperOrigin-RevId: 460476841
Fixed by the commits above. |
The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline. When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`. Issue: androidx/media#25 Issue: #8212 #minor-release PiperOrigin-RevId: 460325235 (cherry picked from commit 02e1484)
Issue: androidx/media#25 PiperOrigin-RevId: 460476841 (cherry picked from commit d6659e9)
The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline. When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`. Issue: #25 Issue: google/ExoPlayer#8212 #minor-release PiperOrigin-RevId: 460325235 (cherry picked from commit 30fbc3a)
Nice work |
@marcbaechinger Sorry to open this again, but during active play of This means we still have to resort to locally caching the |
When the remote media client is set to null the timeline is updated and set to an empty timeline. I agree that's surprising and unfortunate for a
I think this is a known behaviour though. However, now that we support the media items in the timeline with I don't know when we come around to look into this I'm afraid . |
Thank you, seems logical. I was just verifying to be sure I didn't miss anything. I'll keep an eye on improvements in the future. |
Thank you for this comment @marcbaechinger. I stumbled upon it accidentally, I wish I could have read it before e.g. in README, it would have saved me a lot of time and debugging. |
Just wondering if there were and updates on The empty media item issue? It presents quite a significant problem, when resuming of a session is required. Caching a copy of the playlist, for the purpose of recovering from a Cast connection loss, if fairly ugly and highly prone to issues. I am working around it by retaining a playlist of current items, which I reference rather than metadata on castplayer. I do this to avoid re-pushing a play queue if a resume is required. It's not ideal, due to potential to become out of sync, if queue items change for example. Have to be very careful to keep that list in sync on queue edits and so forth I have noticed that the notification published by media 3 seems to have awareness of metadata post resume. I Was wondering how the notification is obtaining this information? Cheers |
Was wondering if you had any updates or further advice on this issue, as yet? Cheers |
I'm using a
MediaLibraryService
that switches the player from ExoPlayer to CastPlayer when a CastSession is available. When the ExoPlayer is active, callinggetCurrentMediaItem()
from aMediaController
returns the correctMediaItem
, but if the same call is done when the CastPlayer is the active one, I receive an emptyMediaItem
.The method
getWindow(...)
insideCastTimeline
is the one creating and using an emptyMediaItem
instead of the expected currentMediaItem.The text was updated successfully, but these errors were encountered: