Erratic Queue Behavior #99
Labels
No labels
Bug
Cleanup/Refactor
Core Feature
Documentation
Feature
Performance Improvement
Security Improvement
UX/Accessibility
Unreproducable Bug
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: rainbownapkin/canopy#99
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The queue seems to start playing unlisted phantom items.
This most likely has to do with an issue relating to the refreshNextTimer() function.
We should monitor said function to see WTF is going on with it.
Edit: This bug has potentially been solved and is being watched.
A good way to re-create the issue seems to be queueing a playlist multiple times, then manually deleting each item individually.
These items don't seem to be in the queue (live or DB), though they do save to the DB once they start playing (but not the queue)
Having a hard time re-creating this. I'll watch it as I continue development...
This seems to be easily re-created by queueing two items from a playlist in rapid succession, deleting the first, then starting the second partially the way through.
From then it likes to stop early.
Noticed sync being emitted twice a second when this happens. Looks like the queue function might be being called twice. Will continue to work on this.
Commit 'e34dcbdec70971808e169745afac4fef9aa0bdc8' has fixed the issue with media being started twice, thus causing it to end half-way through.
Not sure how much this will effect ghost items starting in the queue especially since it's been a while since I've seen one.
I'll keep the issue open for now and close if we don't see one for a while....
MOTEHRFUCKER I just had a ghost item start again, an item that was randomly queued than dragged to start late, re-started ~20 minutes after it ended (about the length of the items total duration.)
Seems to have started at the same time stamp it would have originally, only playing for the 3 or so minutes it was originally scheduled for.
Restarting the server while it plays seems to correct the behavior, indicating it at-least isn't infecting the playlist, nor does it show up in the queue panel indicating it isn't hitting the playlist in RAM either...
Unfortunately this took place while running 'dev' and not the 'verbose-queue' branch...
More testing required!
Alright 'ef0344942bea9f3b7d818196135b810478b866d1' seems to have done it...
It looks like 'refreshNextTimer()' from 'queue.js' was only clearing stale timers when re-setting the timer, but not when starting a new piece of media or falling through on nothing.
Moving it to run every time 'refreshNextTimer()' was called seems to have fixed this issues. If a timer is needed after the function is called, it will set it self up one, if not it will clear it and let it be.
Leaving the issue open so we can watch it while working on other shit.
changed the description
changed the description
It's been over a week since this was last touched. Since then we've been through an entire public test and several other bugfixes and feature-adds. I think we can finally put this one to bed.