Jellyfin v10.9

[bigun]

I've tested the 'pre-2' version
Jellyfin version 10.9.1 installed on Debian 11 via deb package
NextPVR version 6.1.5.231022 installed on Windows 10

Order of operations:
Replace old .dll with new
Restart Jellyfin
Check the guide (empty)
Check the recordings list (empty)
Run task to refresh guide
Waited for completion
Check the guide (full)
Attempt to play live TV (successful)
Check the recordings list (full)
Attempt to play past recordings (failure)
Continue to attempt past recordings on different devices (always fails)

I looked through the logs and noticed a different URL pattern for live vs recordings.
I tried to play /live?recording=40556 in VLC but it failed.
Then I tried /live?recording=40556&client=jellyfin.1&sid=f4ed76ec07e6456b8c1e87ff293dd0a8 in VLC and it successfully played the recording.
Further testing reviled that the client argument was not needed, but the sid is.

I have attached the main Jellyfin log, as well as the FFmpeg transcode logs from successfully playing live tv, and attempting to play a recording.

[mvallevand]

Thanks for the report @bigun. Things look pretty good.

Are your recordings on a remote server, you aren't using localhost? I have posted a few time here and also on the Jellyfin forum that because recordings don't come back to the addon to get a sid you need to disable security on NextPVR server with "Allow unauthenticated access for streaming Live TV / Recordings" on the Settings->Access page. Make that change and I think the recordings will play and you can continue testing. Alternatively on the same server change the streaming protocol to filename. Technically to maintain security in filename mode if the mounted filename in NextPVR and Jellyfin are the same it will work on different machines.

That being said I am surprised that ffmpeg showed error 500 and not 401 so if that doesn't work, we might need to see the zipped NextPVR logs as well.


Martin

[bigun]

Correct, the NextPVR host and the Jellyfin host are separate machines.

My access settings are already set to allow unauthenticated access, and changing the plugin settings "Recording Protocol" to filename did not change anything.

Further experimentation in VLC shows that any 3+ characters for the sid will work. Such as:
/live?recording=40556&sid=abc

[mvallevand]

Sorry I forget there was a regression sometime last year which introduced the "any" sid requirement I am testing with a pre-release where it is fixed.

Are you running 6.1.5? (This is why I like NextPVR logs too)

Martin

[bigun]

NextPVR is version 6.1.5.231022

[mvallevand]

Ok I couldn't find a patched NShared from sub so try the attached update that adds &sid=jellyfin  Unfortunately I don't have 6.1.5 installed to test against the regression.

You will probably have to manually run the Scan Media Library task to have the new URL stored.

Martin

[bigun]

I loaded up the new plugin, refreshed all the things, and it seems to be working.

I can play both live tv and recorded.

[mvallevand]

Great thanks for the report, hopefully other will have the same success.

Martin

[mvallevand]

OK here is another update. I changed the logic to not use a global, and to connect to NextPVR if Jellyfin calls recordings before channels are loaded.

Martin

[luguber]

First, thank you for the quick turn around!
I have tested the pre-3 update briefly, and it seem like everything is working fine with this one.
Tested livetv, playback of old recording, scheduled new recording, artwork, guide.

For info, I run Jellyfin and NextPVR on "separate machines" as well. Separate linux containers on same machine to be presice (Proxmox LXC). Both containers run Debian 12.
Jellyfin v1.9.1 and NextPVR v6.1.5.231022