Jump to content

Recommended Posts

TMCsw
Posted
On 12/20/2025 at 11:07 PM, TMCsw said:

f I were betting on this, I'd take it to be here before Santa.😀

Santa, you were late...

Can I hope for more this Year??😃

  • Haha 3
SHSPVR
Posted
On 1/7/2026 at 9:24 PM, TMCsw said:

Santa, you were late...

Can I hope for more this Year??😃

Good luck with that But as I say better late than not at all

  • Like 1
Posted

For those who missed it:

 

  • 2 weeks later...
chesterseenes316
Posted

how the beta going

SHSPVR
Posted

I have wait in tell their support for Bazzite for now

Posted
5 minutes ago, SHSPVR said:

I have wait in tell their support for Bazzite for now

I'm afraid, there's no change to be expected. The RPM packages can be installed via rpm-ostree, but officially, Bazzite is not supported and won't be.

SHSPVR
Posted
3 minutes ago, softworkz said:

I'm afraid, there's no change to be expected. The RPM packages can be installed via rpm-ostree, but officially, Bazzite is not supported and won't be.

That bummer as it the best option for my Steam Library is Emby still plan for Flatpack ?

Posted (edited)

I installed the beta on my Bazzite box and it ran fine.

Edited by richt
  • Like 1
CrappyUserName
Posted

I've got emby theater running on an Allwinner h618 tv box with Armbian installed. 

I've managed to get video acceleration enabled in MPV and it plays great with that player. To get it working involved installing specific ffmpeg and mpv versions.

The issue I have is Emby is still a choppy mess. I have video output set to libmpv and the acceleration set to unset (for mvp.conf).

I've set MPV to save a log and after playing the same file in each player and comparing the log, it seems Emby is using it's own version of mvp and ffmpeg

				mpv			emby
MPV				0.35.1			0.38.0-dirty
ffmpeg				5.1.8-0+deb12u1		n6.0.1-180-gf4af3f1cbb
libavutil			57.28.100		58.2.100
libavcodec			59.37.100		60.3.100
libavformat			59.27.100		60.3.100
libswscale			6.7.100			7.1.100
libavfilter			8.44.100		9.3.100
libswresample			4.7.100			4.10.100

The emby ffmpeg version fails with the following errors and and reverts to software rendering. 

[   0.028][v][libmpv_render/drmprime] drmprime hwdec requires at least one dmabuf interop backend.
[   0.028][v][libmpv_render] Loading failed.
[   1.422][v][ffmpeg] Unable to open any dma_heap device
[   1.422][e][ffmpeg/video] hevc: Failed to set destination format: S265 1920x1080
[   1.422][e][ffmpeg/video] hevc: Failed setup for format drm_prime: hwaccel initialisation returned error.

I've searched the system and can only find one copy of ffmpeg but I don't really know what I'm doing. If I run ffmpeg --version in the terminal it reports the versions MPV is using.

Is there any way to make emby use the versions in the mpv column above or is it baked into the emby-theater exe?

Alternatively does anyone have a solution for the dma issues in the newer ffmpeg version?

The mpv.conf file uses hwdec=drm. In regards to dma and drm the MPV ffmpeg has the following features enabled and the emby version only has dmabuf-interop-gl, drm. egl-drm

dmabuf-interop-gl
dmabuf-interop-pl
dmabuf-wayland
drm
egl-drm
drm-is-kms
vaapi-drm

I've spent so much time getting this box functional and this is the last hurdle I need to clear. Someone here is my only hope!

  • Thanks 1
CrappyUserName
Posted

Figured it out.

Added an external player

/usr/bin/mpv

arguments:

--ontop

--no-border

{path}

Now I just need to reconfigure the ir remote to interact with mpv as well as emby which shouldn't be too hard.

Happy days!

  • Thanks 1
  • 2 weeks later...
ZanderKeen
Posted

@softworkzIt looks like wayland is adding the persistent window positioning protocol... finally...

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

5tudthr.png.9ec3d197b59d0b5ca55f16587734c390.png

  • Thanks 2
Posted
17 hours ago, ZanderKeen said:

@softworkzIt looks like wayland is adding the persistent window positioning protocol... finally...

Yeah, I know this thread. This is about positioning only and it doesn't work while dragging, etc.

What we need is sync of:

  • Position
    realtime while dragging
  • Size
    realtime while dragging
  • Un/Minimize
  • Un/Maximize
  • Fullscreen
  • virtual desktop
  • stacking order

When we extrapolate from the positioning API - which took 5 years from when the issue was filed - and with 7 remaining items, this means...

....we will have that in 2061 (applause! applause!)

 

  • Haha 4

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...