Bug 505365

Summary: Seeking to a specific position in a song causes playback to start from the beginning instead of the selected position.
Product: [Applications] audiotube Reporter: Suresh S <suresh45808>
Component: generalAssignee: Jonah Brüchert <jbb>
Status: REPORTED ---    
Severity: normal CC: nikolay_anzarov
Priority: NOR    
Version First Reported In: 25.04.2   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

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.