Amazon-Sourced MP3 Playback Issues

michaelcresswell commented 10 months ago

Software Versions

Jellyfin Server Version: 10.8.13
Roku Client Version: unstable (#1622 aka 2.0.1 plus some changes)

Describe the bug

Playback after seeking forward or backwards in Amazon-sourced MP3 files may start at a different time than the playback time shown on player. Seeking to within a few seconds of the end of the song may lead to no playback at all.

How To Reproduce

Download an Amazon Music purchase as an MP3.
Add the file to a Jellyfin Music library
Play the song on a Jellyfin Roku client
Use the scrubber to seek as close to the end of the track as possible
Bug occurs

Expected behavior

MP3 files sourced from Amazon playback, seek, etc. the same as from other sources.

Logs

Screenshots

Screenshots do not demonstrate the issue.

Connection Information

Is server local or remote? Local
Is server connection HTTP or HTTPS? HTTP to a reverse proxy, HTTPS from the reverse proxy

Additional context

The scrubbing capability added by Pull Request #1622 exposed playback issues with Amazon-sourced MP3 files. Additional testing showed that the Roku Media Player behaves the same way so the issue is either the MP3 files or the Roku Media Player, not the Jellyfin client. Windows Media Player also exhibited similar strange playback.

The files were downloaded from Amazon in the 2022-2024 time period.

ffprobe of an Amazon song that does exhibit the issue:

ffprobe version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2007-2021 the FFmpeg developers
  built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)
...
Input #0, mp3, from '<path_to_file>':
  Metadata:
    <metadata tags>
  Duration: 00:03:26.55, start: 0.025056, bitrate: 265 kb/s
  Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 263 kb/s
    Metadata:
      encoder         : Lavc58.35
  Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 600x600 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn, 90k tbc (attached pic)
    Metadata:
      comment         : Cover (front)

The most similar looking ffprobe of a non-Amazon song that does not exhibit the issue:

ffprobe version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2007-2021 the FFmpeg developers
  built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)
...
Input #0, mp3, from '<path_to_file>':
  Metadata:
    <metadata tags>
  Duration: 00:03:47.11, start: 0.025056, bitrate: 349 kb/s
  Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 320 kb/s
    Metadata:
      encoder         : Lavc58.35
  Stream #0:1: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 1440x1440 [SAR 118:118 DAR 1:1], 90k tbr, 90k tbn, 90k tbc (attached pic)
    Metadata:
      comment         : Other

1hitsong commented 10 months ago

I've done some testing and there is nothing in the data that gives any indication of any issues. Additionally, the media player component on Roku does not have the built in smarts to know the user is attempting to seek past the media's length. It simply hangs. My guess is players on other clients have more error handling capabilities than we do on Roku.

The only thing I can think to do is to create a buffer timer and when the user attempts to scrub to a new time, we start the timer and if playback doesn't start after x seconds, we assume an error has occurred.

That's my best idea thus far.

1hitsong commented 9 months ago

Further test findings

At the start of playing, the player's duration property is almost 2x the real duration. It then changes throughout playback.

It's wild. My personal MP3s, the duration gets set on play and is rock solid. The Amazon MP3, the duration is a moving target.

As far as I can tell, there is no property we can read to know if/when Roku is doing this so we can warn the user.

The only idea I have so far is keep a running log of all the different duration the player provides, and use the highest one.

michaelcresswell commented 9 months ago

keep a running log of all the different duration the player provides

If we can observe changing durations, isn't that enough to detect that the issue is happening?

The client seems to report the correct total duration (3:26 on the right side) so deviations from that could be a clue as well?

I'm guessing since its Roku we can't do a lot about it though.

Is there someone (possibly on the server team) that would be able to look at an mp3 and find a specific issue we could report to Amazon? (Not sure how helpful Amazon would be but if we can pinpoint something I'm willing to try)

1hitsong commented 9 months ago

The client seems to report the correct total duration (3:26 on the right side)

The 3:26 value is from the Jellyfin API, not the audio player duration property.

If we can observe changing durations, isn't that enough to detect that the issue is happening?

Maybe, I've only begun to investigate. I don't know if it's a reliable method or not. The next problem comes up, even with this data, what do we do with it?

jellyfin / jellyfin-roku