(2024-04-22, 10:02 PM)bitmap Wrote:

(2024-04-17, 05:23 PM)bitmap Wrote: Having a weird thing with scans. I'll try to grab logs next time it happens, but posting it here in case anybody else has the same experience.

I imported a new series, but replaced an episode for consistency's sake. When I replaced the episode (with Sonarr), Jellyfin picked up the replacement episode when I used "Scan All Libraries" but failed to note that the file it replaced was gone. So I had two episodes in my season list with zero indication which was correct, but trying to play one resulted in a generic playback error. I quadruple-checked and there were not two files for that episode in the season folder.

Scanning the individual library where that series lives seemed to clear up the issue, but this has happened a few times since moving up to 10.9. I'll offer more info if/when it happens again.

Okay, so I figured out the root of this issue. I replaced series episodes -- manually and via *arr -- and I can recreate this issue over and over. Jellyfin reports duplicates of episodes when there is an orphan NFO file. For instance, if I upgraded from DVD to BR quality, there might be an orphaned NFO depending on how I replaced the media. Jellyfin presents the NFO as a full-fledged media file when looking at that media via a client (WebOS, web, Roku). Playing the phantom file, which is actually an NFO, results in a playback error since NFO files are not media.

Is this expected behavior? I've not seen it in previous iterations, through 10.8.13, but it's happening repeatedly in 10.9. Worth a bug report?

A red herring was that "Recordings" (which is empty) was removed as a library and there was a missing folder that "Scan All Libraries" expected (/config/data/root/default/Recordings). I did not descend into the /config dir and remove this folder, so I'm not sure where it went, but creating it fixed that issue.

ETA: This also happens when names are changed by a *arr and you get leftover NFO files as well. Scan All Libraries will NOT resolve this issue, you're left with phantom duplicates. You can scan the individual library to remove those duplicate entries. I have not checked whether the NFO files are removed, but I would assume so. This may be an unintended consequence of using Servarr apps to manage media (i.e., standard naming and folders, identification, metadata, NFO files). It seems like I may have Servarr apps fighting with Jellyfin for who makes and breaks the NFOs.

(2024-04-28, 07:11 AM)OddMagnet Wrote:

(2024-04-22, 10:02 PM)bitmap Wrote:

(2024-04-17, 05:23 PM)bitmap Wrote: Having a weird thing with scans. I'll try to grab logs next time it happens, but posting it here in case anybody else has the same experience.

I imported a new series, but replaced an episode for consistency's sake. When I replaced the episode (with Sonarr), Jellyfin picked up the replacement episode when I used "Scan All Libraries" but failed to note that the file it replaced was gone. So I had two episodes in my season list with zero indication which was correct, but trying to play one resulted in a generic playback error. I quadruple-checked and there were not two files for that episode in the season folder.

Scanning the individual library where that series lives seemed to clear up the issue, but this has happened a few times since moving up to 10.9. I'll offer more info if/when it happens again.

Okay, so I figured out the root of this issue. I replaced series episodes -- manually and via *arr -- and I can recreate this issue over and over. Jellyfin reports duplicates of episodes when there is an orphan NFO file. For instance, if I upgraded from DVD to BR quality, there might be an orphaned NFO depending on how I replaced the media. Jellyfin presents the NFO as a full-fledged media file when looking at that media via a client (WebOS, web, Roku). Playing the phantom file, which is actually an NFO, results in a playback error since NFO files are not media.

Is this expected behavior? I've not seen it in previous iterations, through 10.8.13, but it's happening repeatedly in 10.9. Worth a bug report?

A red herring was that "Recordings" (which is empty) was removed as a library and there was a missing folder that "Scan All Libraries" expected (/config/data/root/default/Recordings). I did not descend into the /config dir and remove this folder, so I'm not sure where it went, but creating it fixed that issue.

ETA: This also happens when names are changed by a *arr and you get leftover NFO files as well. Scan All Libraries will NOT resolve this issue, you're left with phantom duplicates. You can scan the individual library to remove those duplicate entries. I have not checked whether the NFO files are removed, but I would assume so. This may be an unintended consequence of using Servarr apps to manage media (i.e., standard naming and folders, identification, metadata, NFO files). It seems like I may have Servarr apps fighting with Jellyfin for who makes and breaks the NFOs.

Did you already report this bug?
I've got a similar problem, not sure if it's the same bug.
When sonarr grabs a new episode and then immediately grabs an upgrade for it Jellyfin shows the same episode twice, where one is working and the other is not (since it tries to open the file that sonarr removed in the upgrade)

I'm not using NFO files though (at least haven't enabled it in the library settings), so this might be a different bug then?

(2024-05-06, 10:40 AM)nyanmisaka Wrote: If you don't plan to use iGPU, then don't pass its corresponding renderD128 to docker.
In addition, according to the libdrm code, 129->128 mapping is strongly not recommended, please do 129->129. The cardX is not required.

host:
/dev/dri/renderD128 # iGPU
/dev/dri/renderD129 # dGPU
/dev/dri/card0
/dev/dri/card1

docker:
/dev/dri/renderD129 # dGPU
/dev/dri/card1 # optional, not required

BTW the QSV on Linux is based on VA-API.