-
Notifications
You must be signed in to change notification settings - Fork 6k
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
CacheUtils: Cache a task with priority #5573
Comments
At what point are you making the cache thread wait? In other words, from what you explain above, i'd expect something along the lines of
But I don't see where that's happening. Can you clarify. It would also help if you removed any irrelevant piece of code in the sample. |
In
The |
I think that the sample don't have irrelevant piece of code. |
CacheUtil.readAndDiscard()
PriorityTaskManager.proceed()
DefaultLoadControl.shouldContinueLoading()
I add logs at these points. |
@AquilesCanta Did you already had the time to look into this issue? Is there anything I can do to support you? |
Is there anyone looking at this issue? I think this is a bug. Is there anything I can do to support you? |
I'd suggest you make your version of the demo app available on GitHub somewhere, so we can easily reproduce what you're seeing without having to spend a lot of time replicating what you've done. Thanks! |
Sorry, lost track of this. @erdemguven could you take a look? @Romantic-LiXuefeng, please provide a minimal fork as @ojw28 suggests. It will allow us to look into this faster. |
@erdemguven @AquilesCanta @ojw28 As suggests, I make a demo project. Thanks for your help ! |
Can confirm when the cache download pauses and the resumes because of priority switching, the Hopefully, it's just the value that is wrong and everything else is working correctly. Edit: Ran some tests and good news. It looks like just the value is wrong, but the file sizes of the downloaded items are correct. |
It looks like only a reporting problem. Already cached data is recounted when caching resumes. A fix will be committed soon. |
When caching is resumed, it starts from the initial position. This makes more data to be reported as cached. Issue:#5573 PiperOrigin-RevId: 250678841
Thanks! I'll close this issue. |
When caching is resumed, it starts from the initial position. This makes more data to be reported as cached. Issue:#5573 PiperOrigin-RevId: 250678841
Before filing a bug:
My user case: A playback task with priority
PRIORITY_PLAYBACK
, and at same time, a backgroundtask with priority
PRIORITY_DOWNLOAD
.As the state of the playback task changes between the buffering state and the ready state, the state of the background thread also changes in the waiting state and the running state.
The issue is: when the background task thread is in waiting state, the
totalCachedBytes()
return value changed.Reproduction steps
Using the
PreCacheProgressivePlayerActivity.java
to replacePlayerActivity.java
in demo.At the beginning, when the background task thread's state is waiting, the
totalCachedBytes()
return value unchanged.But there are some abnormal situations. Look at these lines filtered by TAG["progressive_downloader"]. the
totalCachedBytes()
return from 56499512 to 106171816.The text was updated successfully, but these errors were encountered: