Bug 505365 - Seeking to a specific position in a song causes playback to start from the beginning instead of the selected position.
Summary: Seeking to a specific position in a song causes playback to start from the be...
Status: REPORTED
Alias: None
Product: audiotube
Classification: Applications
Component: general (other bugs)
Version First Reported In: 25.04.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Jonah Brüchert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-09 04:55 UTC by Suresh S
Modified: 2025-09-08 08:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Suresh S 2025-06-09 04:55:13 UTC
---

**SUMMARY**  
Seeking to a specific position in a song causes playback to start from the beginning instead of the selected position.

---

**STEPS TO REPRODUCE**

1. Open AudioTube and play any song.  
2. Try seeking to a specific timestamp (e.g., drag the progress bar to 1:30).  
3. Observe the playback behavior.

---

**OBSERVED RESULT**  
The song restarts from the beginning regardless of where you seek.

---

**EXPECTED RESULT**  
The song should continue playing from the selected timestamp.

---

**SOFTWARE/OS VERSIONS**  
Linux/KDE Plasma: Yes  
KDE Plasma Version: 6.3.5  
KDE Frameworks Version: 6.14.0  
Qt Version: 6.9.1

---

**ADDITIONAL INFORMATION**  
* AudioTube version: 25.04.2
Comment 1 Nikoichu 2025-09-08 07:50:41 UTC
Can confirm the same is happening on the Flatpak version of Audiotube 25.08.0 on Nobara 42.
However, I also tried it on the native package (also 25.08.0), and seeking works fine there. No idea what could be causing this. Is it possible it's a flatpak permission issue or something of that nature?
Comment 2 Jonah Brüchert 2025-09-08 08:32:33 UTC
(In reply to Nikoichu from comment #1)
> Can confirm the same is happening on the Flatpak version of Audiotube
> 25.08.0 on Nobara 42.
> However, I also tried it on the native package (also 25.08.0), and seeking
> works fine there. No idea what could be causing this. Is it possible it's a
> flatpak permission issue or something of that nature?

Seeking in the streams from YouTube was always a bit finicky in GStreamer, so this was probably just improved upstream. 
It will likely be fixed on the flatpak as soon as we update GStreamer there as well.