Improve playlist sorting stability and performance

[SethCohen]

Summary

This PR refactors the playlist sorting logic to make it more deterministic, faster, and resilient to YouTube’s dynamic DOM behavior during drag-and-drop operations.

YouTube frequently updates and rerenders the playlist DOM during drag operations.
The previous approach relied heavily on static positions, which could lead to:

• incorrect ordering
• broken sorting runs
• excessive drag operations

This update ensures the script remains accurate and consistent even under those conditions, while also improving sorting speed, resulting in:

• More reliable sorting across all playlist sizes
• Improved performance with fewer drag operations
• Greater resilience to DOM changes and edge cases
• Cleaner and more maintainable sorting logic

---

Key Improvements

• Stable video tracking

  • Introduces a video ID–based system to track items across DOM rerenders
  • Prevents incorrect sorting caused by shifting or recreated elements

• Deterministic sorting algorithm

  • Precomputes the final sorted order
  • Places each video directly into its correct position instead of performing repeated swaps
  • Ensures stable ordering using original index as a tie-breaker

• Improved performance

  • Reduces unnecessary drag operations by avoiding swap chains
  • Minimizes redundant DOM reads
  • Results in faster sorting, especially noticeable on medium-to-large playlists

• Increased reliability

  • Handles YouTube rerenders between drag operations without losing state
  • Adds guards for missing elements, partial loads, and non-standard entries
  • Retries safely when the DOM changes mid-sort instead of failing

• Robust duration parsing

  • Supports both mm:ss and hh:mm:ss formats
  • Non-timestamped entries (e.g., upcoming or unavailable videos) are handled predictably

• Auto-scroll fix

  • Correctly parses boolean values from select input to avoid unintended behavior

---

I've tested this several times against a variety of Watch Later playlist conditions from small (10-20 videos) to large (100+) playlists, with unavailable videos, etc. So far, so good. Changes are stable.

[KohGeek]

I'm so sorry about the lack of replies or accepting this PR. Do you wanna just take over the development for now or just have me merge the code? I can piint to your fork specifically if you wish, I clearly don't have the time or will to maintain this specifically

[MobyGamer]

I would be wary of accepting this without more tests; it smells heavily of AI, and when I tested it, I noticed no actual functional or performance improvements. The code changes feel like someone asked an agent "improve this" and this PR was the result.

The most recent version of the script is still working fine.

[SethCohen]

I'm so sorry about the lack of replies or accepting this PR. Do you wanna just take over the development for now or just have me merge the code? I can piint to your fork specifically if you wish, I clearly don't have the time or will to maintain this specifically

No worries. I'd rec doing a few more tests like @MobyGamer said before merging, imo, I've only tested this against Watch Later playlists sub <150 videos. I'm not sure how it performs on playlists of extremely large sizes like 300 or 400. I also don't really have much time to maintain the project either, but I thought I'd atleast contribute because the old method was way too slow for my tastes. My biggest issue was that when my Watch Later playlist got to around 90ish videos, it'd struggle to load the DOM and sort.

[SethCohen]

I would be wary of accepting this without more tests; it smells heavily of AI, and when I tested it, I noticed no actual functional or performance improvements. The code changes feel like someone asked an agent "improve this" and this PR was the result.

The most recent version of the script is still working fine.

The most recent version is working aceptable enough, but it does fail at times. Im genuinely surprised you didnt notice any functional improvements. I've been petpeeved for months because the tool would struggle to sort on larger-sized playlists, either completing failing to sort or just be very slow.

The previous implementation would track items by their positions and element references, then performed a sequence of drags/swaps based on those original positions, but then YouTube would rerenders/rebuilds the playlist rows after drag-and-drop, breaking the sort often if it couldnt properly load the new DOM (Common on larger playlists).

The most critical addition to this PR was that the new implementation precomputes the sort order before sorting, thus eliminating the care for any rerendered DOMs as its sorting. Which also ends up making it complete sorting faster.

What were your test conditions?

[MobyGamer]

What were your test conditions?

The same number of items as your tests, but after some consideration, I think my situation is not appropriate for performance testing. I run on a very performant rig, and I also have fast bandwidth with very low latency. My results are likely not typical for that of the average user, so I think some more testing is prudent. (I sometimes run the script as fast as only 200ms in the delay field without trouble.)