Testing 10.9.0

[Prayag]

Reported https://github.com/jellyfin/jellyfin/issues/11441

[_Mayhem_]

I somehow managed to get three collections created that simply will not go away under 10.9.0:2024041505 . The movies I was trying to add never showed up in the collection, and none of the three are shown in Admin > Libraries. I'm running these in Docker.

Neither restarting the server nor the container makes them behave. Nor does recreating the container with a re-pull in Portainer. 

I see this in the log:

[2024-04-27 18:38:43.077 -05:00] [ERR] [35] Jellyfin.Api.Middleware.ExceptionMiddleware: Error processing request: "Could not find a part of the path '/config/root/default/Collections2'". URL "POST" "/Collections".
[2024-04-27 18:39:29.858 -05:00] [INF] [35] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "192.168.4.115" closed
[2024-04-27 18:39:30.446 -05:00] [INF] [37] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "192.168.4.115" request
[2024-04-27 18:42:22.150 -05:00] [ERR] [34] MediaBrowser.Controller.Entities.BaseItem: Error refreshing owned items for "/config/root/default/Collections"
System.IO.DirectoryNotFoundException: Could not find a part of the path '/config/root/default/Collections'.

[thornbill]

@_Mayhem_ this is a known issue that should be fixed before the final release: https://github.com/jellyfin/jellyfin/issues/11258

[OddMagnet]

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?

[JohnDorian]

Are there any news about the Release? Since the weekend of the hopefully final RC is over, I'm wondering when there will be an official announcement for 10.9.

thx for the reply

[niels]

We will release 10.9 when it's ready. Right now we still have some finishing touches to work on.

[bitmap]

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?

I have not reported this as a bug, that was my question. The behavior you've described sounds exactly like what I've experienced, however, most of my recent experience comes from my own encodes managed with Sonarr.

[bitmap]

Posted this in the wrong spot...whoops.

I've been running 10.9 for a hot minute now and had decent luck. One thing that bugged me is that I swapped over to my A380 for transcoding while I was re-casing my machine. Almost everything seemed to work, but I got some errors on AV1 media. I have a LOT of AV1 media and I'm encoding more every day.

I thought it was the fact that I enabled Allow AV1 Encoding, so I disabled. No dice, same result. So I double-checked my host setup, revised my docker-compose to not map the device and card differently (129->128, 1->0). Everything is just fine, no issues. So I started thinking that Jellyfin might be using the wrong device despite not actually having another option for QSV.

Last step, I set HWA to VA-API and changed the device to renderD129 (matched with my A380 mapped into the container), saved + swapped back to QSV, and voila, everything works. Beautifully, I might add. I didn't have this issue before, however, I was using my iGPU and that meshes with renderD128, which is what VA-API was set to previously.

So...does this sound like a bug? Can anybody else reproduce? I will try to reproduce and grab some of the failed ffmpeg logs, as the errors were "Generic error in external library." I've used ffmpeg enough to know how sublimely unhelpful documentation and errors are, but this is next level...

[nyanmisaka]

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.

[bitmap]

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.

Thanks for the info! And yeah, I only pass one device at a time. The situation I described is with only passing my dGPU. I'm aware Linux QSV is Intel's implementation of VA-API. I figured my trying to be smart with 129->128 was probably a pitfall, which is why I changed it. No need to complicate things like that.