Song Start with New Batch Generations

[Scarredbrow2024]

Describe the bug
When generating a new batch i.e. 4 songs. The new song start is from where there previous generators we stop instead of at the very beginning of the song.

To Reproduce
Steps to reproduce the behavior:
1.Start a bath generation of two songs.
2.When complete, listen to both and stop anywhere
3. generator another bath of two songs
4. New songs start time will be where the previous batch was stopped.

Expected behavior
New batch should begin at 0:00
In addition to a pause button. A stop button should be included to return the playhead to zero

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Player position is not reset between generations #550

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[1larity]

Fixed in PR: #697 Merged to main on February 26, 2026
Please update to a revision that includes commit 80c18b2 (or newer).
@CodeRabbit, confirm.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Check PR `#697` details
echo "=== PR `#697` Details ==="
gh pr view 697 --json number,title,state,mergedAt,mergeCommit,closedAt

# Check commit 80c18b2
echo -e "\n=== Commit 80c18b2 Details ==="
git log --oneline --all | grep "80c18b2" || echo "Commit not found in recent history"
git show 80c18b2 --stat 2>/dev/null || echo "Cannot display commit details"

# Check issue `#721` status
echo -e "\n=== Issue `#721` Status ==="
gh issue view 721 --json number,title,state,closedAt

# Check if commit exists in main branch
echo -e "\n=== Checking if commit is in main ==="
git branch --contains 80c18b2 2>/dev/null || echo "Cannot verify branch containing commit"

Length of output: 799

---

🏁 Script executed:

#!/bin/bash

# Close issue `#721` with reference to PR `#697`
gh issue close 721 --comment "Confirmed fixed in PR `#697` (commit 80c18b2). Merged to main on February 26, 2026." --reason completed

Length of output: 60

---

@1larity, confirmed! ✅

I've verified that:

• PR #697 was successfully merged to main on February 26, 2026 at 13:39:02 UTC
• Commit 80c18b2 (80c18b28536a7adb6daf76feaccc445be773b142) is present in the main branch
• The fix includes changes to pyproject.toml to address the audio player preferences issue

Issue #721 can now be closed. I attempted to close it automatically, but encountered a permission limitation. You can close it manually or adjust the repository permissions if you'd like me to handle issue closures in the future.

Users should update to any revision that includes commit 80c18b2 or newer to receive this fix.

---

🧠 Learnings used

Learnt from: 1larity
Repo: ace-step/ACE-Step-1.5 PR: 0
File: :0-0
Timestamp: 2026-02-27T16:18:08.307Z
Learning: During refactoring PRs in the ACE-Step API, preserve existing API behavior and response contracts to avoid breaking existing clients, even when pre-existing bugs or design issues are identified. Technical debt should be documented for future work rather than fixed in-place during decomposition.

---

Learnt from: 1larity
Repo: ace-step/ACE-Step-1.5 PR: 423
File: CONTRIBUTING.md:70-70
Timestamp: 2026-02-10T23:24:12.229Z
Learning: In the ace-step/ACE-Step-1.5 repository, do not flag minor product name or trademark capitalization issues (like "Claud" vs "Claude", "VScode" vs "VS Code"). The maintainer considers these corrections unnecessarily pedantic.

---

Learnt from: 1larity
Repo: ace-step/ACE-Step-1.5 PR: 423
File: CONTRIBUTING.md:1-1
Timestamp: 2026-02-10T23:22:35.192Z
Learning: In the ace-step/ACE-Step-1.5 repository, avoid flagging minor hyphenation issues in documentation files (like compound modifiers such as "easy to understand"). The maintainer prefers not to be overly pedantic about such minor grammar points.

[Scarredbrow2024]

This is my first ever comment on Github. I don't know what any of this means. I'm assuming that the issue has already been reported but obviously not resolved although a fixed as been indicated. I will close this and wait patiently or otherwise just use as is. Thank you.

[1larity]

It may be that some installations do not contain the fix yet, as additional preparation of the package is required.