Acknowledged

Music playback from custom position with ActiveContent not working

I've run into a new bug, that I think was introduced with the last firmware update (on Fenix 7 Pro Solar)

My podcast app has a feature to store playback position, and when resuming play later I set it through ActiveContent.

This used to work well, but I noticed that it's been acting up lately. It will display the correct time (in my test case 48:20), but the progress bar and actual playback is about halfway that, around 23:20. Edit: I did some further testing, and it always seems like the real playback is about halfway to where it should be (ie playbackpos is set to 28:20, so it displays that, but plays at 14:10 etc).


It seems to me that this is a firmware issue, as the time displayed is correct, but the playback and progress bar is wrong.

My code to create the ActiveContent looks like this:

        var metadata = content.getMetadata();
        // override metadata with data from podcast rss
        metadata.title = episode[Episode.TITLE];
        metadata.artist = episode[Episode.PODCAST_TITLE];

        var playbackPos = episode[Episode.PROGRESS];

        return new Media.ActiveContent(contentRef, metadata, playbackPos);

Parents
  • I found an old example that shows this:  on github primetime00/garminPlaybackStart (forum doesn't allow me to post link)

    It seems to only be happening to mp3. I can understand and accept if the playback position would be a few seconds off, but as it stands now, its 20 minutes off, and completly unusable. It's not possible for me to work around it either, as setting a higher start position than what would be needed will lead to the content iterator requesting next file early.

Comment
  • I found an old example that shows this:  on github primetime00/garminPlaybackStart (forum doesn't allow me to post link)

    It seems to only be happening to mp3. I can understand and accept if the playback position would be a few seconds off, but as it stands now, its 20 minutes off, and completly unusable. It's not possible for me to work around it either, as setting a higher start position than what would be needed will lead to the content iterator requesting next file early.

Children
No Data