[Bug]: Duration info for Windows SystemMediaTransportControls incorrect

[Schtenk]

Preflight Checklist

• I use the latest version of YouTube Music (Application).
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.
• I understand that th-ch/youtube-music has NO affiliation with Google or YouTube

YouTube Music (Application) Version

3.6.2.0

Checklists

• I use the portable version of the YouTube Music Application.
• I can reproduce this issue in the official version of (WEB) YTM.

What operating system are you using?

Windows

Operating System Version

Windows 11 23H2 22631.4460

What CPU architecture are you using?

x64

Last Known Working YouTube Music (Application) version

No response

Reproduction steps

1. Listen to multiple tracks in a row without manually changing tracks.

Expected Behavior

Position, StartTime and EndTime in SytemMediaTransportControls to be that of the current playing song/media.

Actual Behavior

Position and EndTime time in minutes seems to increase seconds stays correct.

For example:
first song 3:32
second song 3:41
EndTime in SystemMediaTransportControls 5:41 on the second song

Enabled plugins

1. Ad Blocker - In Player
2. API Server - Authorize at first request, no hostname set, no port set
3. Exponential Volume
4. In-App Menu
5. Navigation
6. Precise Volume - local arrow keys
7. Taskbar Media Control

Additional Information

Since this seems to be an issue with music.youtube.com both in MSEdge and Firefox I understand that it's unlikely you can do anything about this, but if you can do something that would be highly appreciated.

Thanks in advance for any of your time!

[jbhannah]

This happens in macOS as well, both in-app and when using the website in a browser, so it's likely an issue in the website code itself.

[1000Delta]

I found some details about this issue, if the music natually ended and begin play the next one, Youtube Music website will reuse the same HTMLMediaElement (the <video> tag), you can get it from console:

document.querySelector('.video-stream')

And they not reset the state of media element, seems like they only append new audio data slice to the src and continue playing, so the duration and currentTime of media will still increasing, check the progress:

let duration = new Date(document.querySelector('.video-stream').duration*1000);
console.log(duration.getMinutes()+":"+duration.getSeconds()); // 15:40

let currentTime = new Date(document.querySelector('.video-stream').currentTime*1000);
console.log(currentTime.getMinutes()+":"+currentTime.getSeconds()); // 14:38

But if we pressed the next music button, they will create a new <video> tag to replace the old one, with a new src, so the internal state of media element will not as same as the old one, the issue will not happend.

---

Some solutions:

• Trigger "next music" once when current music ended, but this may need some time to buffer the next music if in weak network (maybe they do not reset the media element is that they want to buffer the next music earlier, anyway this is a bug about the usage of media API)
• Debug and hook the internal logic of Youtube Music's js to handle the music switch logic, more complex.

Maybe someone can have better idea to fix this issue.

I also send a feedback of this issue to Google, hope they can fix this ASAP :)

[Schtenk]

Nice find! I did fill in a feedback form to google/youtube about this when I created this issue, it does kinda feels like putting a bottled message in the ocean when doing it so I didn't have much hope :(

[Schtenk]

This may have been fixed from Youtubes side, anyone else who can confirm if they still encounter this or not?
Nvm still occurs with Youtube music in msedge, so not fixed from Youtubes side, also occurs in this application too now when I'm testing but I felt like I hadn't seen it in a while.