Skip to content

If list has mixed folder and non-folder items, "Play all from here" might play incorrect items #7583

@CircuitCoder

Description

@CircuitCoder

This issue respects the following points:

  • This issue is not already reported on GitHub (I've searched it).
  • I agree to follow Jellyfin's Code of Conduct.
  • This report addresses only a single issue; If you encounter multiple issues, kindly create separate reports for each one.

Describe the bug

If a folder is the first item in a view, "play all from here" breaks for all following items.

Reproduction Steps

Construct a library or folder with the following hierarchy:

  • /the-folder/a/a.mp4
  • /the-folder/a/b.mp4
  • /the-folder/c.mp4

Set sort by name. So the folder displays as the first item. Choose "play all from here" on c.mp4.

b.mp4 gets played instead.

Expected/Actual behaviour

The item that initiates "play all from here" gets played / queued first.

Logs

This seems like a purely frontend bug. Here is my understanding of the cause of this bug:

The action handler for playallfromhere is in src/components/shortcuts.js. The entire list gets pulled and fed into PlaybackManager.play, with a startIndex.

However, in playbackmanager.js: PlaybackManager.play, the input item list gets flatten, specifically in the function call items = await translateItemsForPlayback(items, options);. If the first item is a folder, the getNonItemTypePromise gets called. The frontend asks backend to return a recursively flattened list of current list.

Note that the flattening is done before calculating adjustedStartIndex, therefore making startIndex incorrect. Actually we have no reliable way to compute adjustedStartIndex, because we have no way of knowing the entire recursive size of subfolders.

Server version

10.11.5.0

Web version

10.12.0

Build version

Commit 49da73d

Platform

Windows

Browser

Chrome 146.0.7670.2 (Windows), Firefox 147.0.3 (Windows)

Additional information

Working on a fix.

The most obvious fix is to just slice the items before feeding into playback manager. However the existence of the startIndex option in the first place makes me worry that there are other restrictions on the input.

Further discussion may be needed in the PR.

Maybe related: These issues about mixed-type lists may be related. More specifically, may also be caused by the way that filters gets set based on first item in the list when flattening the list in translateItemsForPlayback.

The fix proposed above may relieve these issues, as we're forcing the selected item to be the "first item" passed into playback manager, therefore guaranteeing that it's returned from the backend, and in the right place (index = 0)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions