ACG-Player v2.6.6.8(20190608); Certain actions acted in the trashcan caused the app to crash.
Project Information
- Repository:
https://github.com/AugustToko/ACG-Player - Project Name: ACG-Player
Describe the bug
I'll try to be concise in my description of the bug. I performed certain actions in the trashcan and the app crashed. I added a song to the trashcan. In the trashcan, I accessed the options(while in the trashcan), and there was an option to add a song(already in the trashcan) to the trashcan. I tried it out, and nothing happened. I went ahead to delete the song. I left the trashcan and accessed it again, and the song I deleted was still there. I accessed the options menu and clicked "more info" and the app crashed.
To Reproduce
- Add a song(you are willing to lose) to the trashcan
- Access the trashcan. It is located in "Playlists"
- In the trashcan, access the options menu.
- Select the "drop to trashcan" option.
- Access the options menu again. But this time, delete the song.
- Exit the trashcan, and access it again. You will find the song you deleted still there.
- Access the options menu and select the "more info" option.
- See error.
Expected behavior
Firstly, I didn't expect the option "drop to trashcan" to still be available in the trashcan page. But even if it was possible for it(the option) to be there, I expected a toast message saying that the song was already in the trashcan.
Secondly, I expected that after I deleted a song from the trashcan (even after the stunt I performed), it should no longer be available in the trashcan.
Screen recording
Test Environment:
- Device: Redmi Note 5 Pro
- OS: Android 9.0
- Software Version: ACG-Player v2.6.6.8(20190608)
Logcat
at java.lang.Enum$1.create(Enum.java:272)
at java.lang.Enum$1.create(Enum.java:262)
at libcore.util.BasicLruCache.get(BasicLruCache.java:58)
at java.lang.Enum.getSharedConstants(Enum.java:289)
at java.lang.Enum.valueOf(Enum.java:244)
at java.io.ObjectInputStream.readEnum(ObjectInputStream.java:1745)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:373)
at android.os.Parcel.readSerializable(Parcel.java:2935)
at android.os.Parcel.readValue(Parcel.java:2722)
at android.os.Parcel.readArrayMapInternal(Parcel.java:3045)
at android.os.BaseBundle.initializeFromParcelLocked(BaseBundle.java:288)
at android.os.BaseBundle.unparcel(BaseBundle.java:232)
at android.os.BaseBundle.getSerializable(BaseBundle.java:1236)
at android.os.Bundle.getSerializable(Bundle.java:1034)
at com.sothree.slidinguppanel.SlidingUpPanelLayout.onRestoreInstanceState(SourceFile:3)
at android.view.View.dispatchRestoreInstanceState(View.java:18635)
at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java:3823)
at android.view.View.restoreHierarchyState(View.java:18613)
at b.o.a.i.restoreViewState(SourceFile:2)
at b.o.a.x.a(SourceFile:169)
at b.o.a.x.i(SourceFile:9)
at b.o.a.x.l(SourceFile:13)
at b.o.a.x.Wb(SourceFile:2)
at b.o.a.x.dispatchActivityCreated(SourceFile:3)
at b.o.a.k.onStart(SourceFile:6)
at b.c.a.n.onStart(SourceFile:1)
at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1392)
at android.app.Activity.performStart(Activity.java:7252)
at android.app.ActivityThread.handleStartActivity(ActivityThread.java:2970)
at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:180)
at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:165)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:142)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:70)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1831)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:201)
at android.app.ActivityThread.main(ActivityThread.java:6810)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)
Caused by: java.lang.NoSuchMethodException: values []
at java.lang.Class.getMethod(Class.java:2068)
at java.lang.Class.getDeclaredMethod(Class.java:2047)
at java.lang.Enum$1.create(Enum.java:268)
... 40 more
Hi, @harry-heightz. Thank you for your contribution. This is very descriptive and precise. Well done. Thanks for providing a log as well. It is very helpful.
I look forward to your next report.
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Chat with us on Discord.
[utopian-moderator]
Thanks for your very swift review @knowledges. However, I'm quite unsatisfied with your review and I need clarity. Overtime, I've produced logcats and the review was that I was able to pinpoint the cause but didn't provide a solution. Recently, the reviewed changed to "I tried to pinpoint the cause but without success". I've requested clarity on the issue but the moderator @fego didn't give me a reply. But I'd love to know why the new review pattern. And one more thing, in this case, the cause of the error is explicitly available in the logcat.
Although I can't read and understand codes, I know the developer understands perfectly.
Hi, @harry-heightz. Thank you for your reply. Although the log-cat provide helpful logs to narrow the search of the actual bug, we expect you to be more specific by describing the real cause of the crash explicitly. Check out the following contributions for example:
@knowledges thanks for your reply. But I think it's quite unfair judging the report of someone who can read and understand codes. We could call him a developer. Indirectly creating a divide between normal bug hunters and people with dev skills. This same divide is evident in the blog category and I complained about how unfair it was giving certain people special privileges. I think the review system of any category should be a level playing ground for every contributor. And I also understand the need for utopian to maintain quality. But let's be fair and logical, those points in the questionnaire doesn't really affect the quality of a contribution. Well, what do I know? Rules are rules. Thanks for replying.
Hi, I do not see how this is unfair. How do you expect to get the same point/review score with a person who explicitly describes a bug process, and also gave the cause of the bug in great detail? Even in a college, you can not expect a pupil who refused to study hard, for an exam to have the same score with the one who came prepared for the same exam. Providing log-cat is an attempt to get the cause of a software crash or bug. Going further to explain the cause of the crash earns you more score. And yes, special privileges will be given to project owners/collaborators who are very much involved in a specific project. This is because they know more about the project more than anyone else. Did you know that project owners/collaborators are not allowed to submit a bug report to their own project? That is a limitation to avoid spam and abuse. I am sorry if you are not satisfied with the review score. However, I have no plan on making any changes to it. Thanks.
Thanks for replying again @knowledges. Well, I've already made my peace with the review score and I'm not actually trying to fight it. I tried with the blog category and it didn't work. I finally accepted that's the way you want it to be. And I'm okay with it. But likening utopian to a college where student read and excel and others don't is still unfair. You definitely were in college right? Prolly a science student. Were you ever asked to write social science exams? I guess not. Now imagine someone like me who has zero idea of coding. And someone who studied it. But same exams are set for us. You know who'll have the highest score right? I'll stop here. I think you already got my point. And you can see the divide I'm talking about. It'll be good if you just said only people with knowledge of code can submit bug reports. Well, I rest my case. Debating over this issue won't cause you to change your mind, as you outrightly said. I'm not even a natural bug-hunter.
Hey @knowledges as like @harry-heightz i also don't understand code.Do you know the owner of those contribution is a pro level programmer?He can read the bug and understand why happening it.We are not programmer but just trying to contributing in open source project.
Thank you for your review, @knowledges! Keep up the good work!
Hey, @harry-heightz!
Thanks for contributing on Utopian.
We’re already looking forward to your next contribution!
Get higher incentives and support Utopian.io!
Simply set @utopian.pay as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!
Hi @harry-heightz!
Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server