New QNAP Package for Testing

[OddbOd 21]

For those of you that want to install the official package in parallel with Stephane's build just install the official QPKG, disable it, edit the port numbers in .qpkg/EmbyServer/programdata/config/system.xml and /etc/config/qpkg.conf then re-enable Emby Server. I will not provide any more detail as I believe this info is sufficient for advanced users. Update: The edit to system.xml persists across upgrades (app and QNAP firmware) but the change to qpkg.conf doesn't.
 
Some observations made during installation and setup:-

• The Media Library Select Path window still contains a weird list of filesystem locations including /dev /proc /tmp and /sys/kernel/config. Does anyone see a problem with starting at /share/Multimedia and only listing the system default shares?
• Initial library scan speed seems about the same as Stephane's package, any performance increase is negligible compared to the huge improvement during 3.0.x development.
• Server seems to be stable so far, the local WebUI feels a little more responsive.
• Playing to multiple clients while the initial scan was still running barely raised CPU or memory usage on my 2.13GHz Atom D2701, the only bottleneck I'm seeing appears to be due to metadata retrieval speed which I assume is limited by the data providers.

An unexpected side benefit of using the official build is that my Chromecast is now able to pass-through AC-3 audio correctly to both my TV and Amplifier!
 

why is it scanning files that are already identified?

 
To update metadata that may have changed at the provider's end, sites like TheTVDB, TheMovieDb, IMDb, MusicBrainz and TheAudioDb are constantly changing therefore so must Emby. You can turn this off in your library settings but that largely defeats the purpose of using Emby in the first place.
 

Also, if I delete a file, it's triggering a library scan...shouldn't it just delete the file? Deleting 3-4 files crashes the server.

 
Deleting the files doesn't remove their corresponding entries from Emby's database. Removing data from databases can be very difficult and risky, the method Emby uses may appear dumb but it's safe and simple.
 
If you're seeing server crashes please report them using this post as a guide.

Edited November 17, 2017 by OddbOd

[Luke 37068]

3.2.35 is up. Please see if it improves the restart function. Thanks !

[MariusW 1]

3.2.35 is up. Please see if it improves the restart function. Thanks !

 

Hi Luke,

 

Restart Button works fine.

[Luke 37068]

Thanks for the feedback.

[Luke 37068]

I can understand the library scan miss-identifying files...but when they are corrected, it's reverting some right back to the wrong item with the next scan. I realize

you can lock down a file, but why is it scanning files that are already identified?

Also, if I delete a file, it's triggering a library scan...shouldn't it just delete the file? Deleting 3-4 files crashes the server.

 

hi there @@jimc115, we need to look at specific examples. Please discuss specific examples and attach the corresponding information requested in how to report a problem. Thanks !

[flyingfufu 0]

I confirm: restart button work fine again here as well !

 

Thanks Luke !

[Luke 37068]

Thanks for the feedback.

[Vidarr 6]

Restart button work aswell but i have a serious issue scanning my repertory everytime i does it Emby will crash.

The normal application doesn't have any problem with the same repertory.

Here are the 3 last logs.

 

https://pastebin.com/G5jXZniM

https://pastebin.com/ru5bHcJa

https://pastebin.com/Ss5jvShN

 

Edit : when i was getting the log it crashed aswell so i guess there's something else.

Edited October 29, 2017 by Vidarr

[Fuechslein 3]

3.2.35 is up. Please see if it improves the restart function. Thanks !

 

Restart function works. SSL still breaks the server. When adding an SSL cert the server always crashes after a few minutes, no matter how many times you reboot/restart. Only way to stop the crashes is by removing the path to the SSL cert again. Attached another log.

 

Edit: It's none of the installed plugins because it happens without any plugin too.

Log.txt

Edited October 30, 2017 by Fuechslein

[sstt671 1]

Restart function works. SSL still breaks the server. When adding an SSL cert the server always crashes after a few minutes, no matter how many times you reboot/restart. Only way to stop the crashes is by removing the path to the SSL cert again. Attached another log.

 

Edit: It's none of the installed plugins because it happens without any plugin too.

+1

[Luke 37068]

Thanks for the feedback.

[paolomarino 0]

hi. one suggestion. i have a 870 pro nas with an intel I3. which hardware acceleration i can enable ? thanks.

[Luke 37068]

We have tested VA API with this package. Thanks.

[sectune 9]

Dear Luke, quick question, did you change anything transcoding/streaming related since last test package version and .35? Myself and other users on my server experiencing stuttering/buffering issues since this update (via android emby app is acceptable, through chrome it only stutters). Checked my connection/upload, all is fine. Would you need ffmpeg logs? I will provide you the transcoding logs as soon as I am home.Thanks!

[Luke 37068]

Dear Luke, quick question, did you change anything transcoding/streaming related since last test package version and .35? Myself and other users on my server experiencing stuttering/buffering issues since this update (via android emby app is acceptable, through chrome it only stutters). Checked my connection/upload, all is fine. Would you need ffmpeg logs? I will provide you the transcoding logs as soon as I am home.Thanks!

 

No changes.

[Luke 37068]

3.2.36 is available in the first post. Thanks guys.

[MariusW 1]

3.2.36 is available in the first post. Thanks guys.

Hi Luke, can you give us a short changelog? Thanks :-)

[Luke 37068]

https://emby.media/community/index.php?/topic/51420-emby-server-change-log/

[macvirii 0]

I just tried with the AMD TVS-463 , no dice...
libva info: Trying to open /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so

 

I tryed forcing install from the vdpau driver (http://ftp.nara.wide.ad.jp/pub/Linux/archlinux/testing/os/x86_64/ati-dri-10.2.7-2-x86_64.pkg.tar.xz) just renaming the drivers (I don't really understand how driver work on linux, it was just a fun try).

 

libva error: dlopen of /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so failed: libelf.so.1: cannot open shared object file: No such file or directory

 

I'm way over my head (linux newbie), I know!! But the package seems close enough to work on AMD Radeon too, just need to implement the vdpau backend to link the vaapi driver. 

 

I think the other errors are from the driver loading error

 

[AVHWDeviceContext @ 0xb118e0] Failed to initialise VAAPI connection: -1 (unknown libva error).

Device creation failed: -5.

Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error

 

 

I'm trying emby coming from plex, right now it seems good, keep the amazing work!

 

If you need, I can test some parameters, files , or other things. I know the AMD NAS is not common.

Thank you and good night!!

 

 

 

 

 

 

[Vidarr 6]

The new package still crash with SSL.

[raven-au 17]

Hi,

 

> I just tried with the AMD TVS-463 , no dice...
> libva info: Trying to open /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so
 

That's because the needed Radeon vaapi driver is not present in the Emby server package directory.

 

> I tryed forcing install from the vdpau driver (http://ftp.nara.wide...6_64.pkg.tar.xz) just renaming the drivers (I don't really understand how driver work on linux, it was just a fun try).

 

What is this and where did you get it?

What is it meant to do?

How do you think this package will provide the needed drivers?

What are they, vaapi, vdpau ....?

 

You can't just install a separate package on an embedded device (not on the qnap anyway) and expect it to apply to other installed packages.

Neither can you rename a vdpau driver and expect it to behave like a vaapi driver.

 

But maybe you did do this right .....

libva error: dlopen of /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so failed: libelf.so.1: cannot open shared object file: No such file or directory

 

What did you rename?

 

This just means the libelf shared library can't be seen by the driver, it's probably in the location the qpkg was installed too.

Ths would have happened before anything attempted to use the shared library though.

But, like I said, vaapi needs a vaapi driver ....

 

I built the r600_drv_video.so and all the related shared libraries only to get:

ERROR - [FFMPEG] - B frames are not supported (0x1).

 

So, judging by a quick web search, the mesa Radeon vaapi implementation is not up to scratch (or possibly) the hardware is limited or I got the package configuration wrong (possibly not though).

 

> [AVHWDeviceContext @ 0xb118e0] Failed to initialise VAAPI connection: -1 (unknown libva error).
> Device creation failed: -5.
> Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error

 

Irrelevant I think since there's no driver at all.

 

It's taking way to much of my time so nothing is likely to happen anytime soon.

 

But there is a package, libva-vdpau-driver, that might provide the needed vaapi interface using the mesa vdpau drivers but my first attempt at building it and "all" the dependent shared libraries failed miserably, not even an error message in the log, Emby silently fell back to software transcoding.

 

Ian

[macvirii 0]

Hi,

 

> I just tried with the AMD TVS-463 , no dice...

> libva info: Trying to open /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so

 

That's because the needed Radeon vaapi driver is not present in the Emby server package directory.

 

> I tryed forcing install from the vdpau driver (http://ftp.nara.wide...6_64.pkg.tar.xz) just renaming the drivers (I don't really understand how driver work on linux, it was just a fun try).

 

What is this and where did you get it?

What is it meant to do?

How do you think this package will provide the needed drivers?

What are they, vaapi, vdpau ....?

 

You can't just install a separate package on an embedded device (not on the qnap anyway) and expect it to apply to other installed packages.

Neither can you rename a vdpau driver and expect it to behave like a vaapi driver.

 

But maybe you did do this right .....

libva error: dlopen of /share/CACHEDEV1_DATA/.qpkg/EmbyServer/lib/dri/r600_drv_video.so failed: libelf.so.1: cannot open shared object file: No such file or directory

 

What did you rename?

 

This just means the libelf shared library can't be seen by the driver, it's probably in the location the qpkg was installed too.

Ths would have happened before anything attempted to use the shared library though.

But, like I said, vaapi needs a vaapi driver ....

 

I built the r600_drv_video.so and all the related shared libraries only to get:

ERROR - [FFMPEG] - B frames are not supported (0x1).

 

So, judging by a quick web search, the mesa Radeon vaapi implementation is not up to scratch (or possibly) the hardware is limited or I got the package configuration wrong (possibly not though).

 

> [AVHWDeviceContext @ 0xb118e0] Failed to initialise VAAPI connection: -1 (unknown libva error).

> Device creation failed: -5.

> Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error

 

Irrelevant I think since there's no driver at all.

 

It's taking way to much of my time so nothing is likely to happen anytime soon.

 

But there is a package, libva-vdpau-driver, that might provide the needed vaapi interface using the mesa vdpau drivers but my first attempt at building it and "all" the dependent shared libraries failed miserably, not even an error message in the log, Emby silently fell back to software transcoding.

 

Ian

As I said Ian, I was way over my head, I just tried renaming one .so file because I saw somewhere on the internet people talking about a direct compatibility between va-api and the vdpau, it was a long shot. I saw some discussion about using the vdpau driver act as an interface between the va-api driver too, I will try to improve my knowledge on this matter.

 

HW acceleration on the Radeon nas is a pain right now, and your response on trying to compile the driver and get the b-frame error I think I saw somewhere else. I would've tried to install the whole vdpau driver if the Linux in qnap wasn't so restricted.

 

The qts 4.3.4 announcement with gpgpu support may tip the scales on the compatibility with drivers and multiple gpus, but that is my wishful thinking right now.

[Syvedris 2]

@@macvirii the beta of 4.3.4 is available, you can try it and see if it has improvement.

- When QTS 4.3.x is installed on NAS models running on 64-bit Intel and AMD processors, some applications may not be supported. To check if installed apps on your NAS are compatible with QTS 4.3.x, download the QTS 64-bit compatibility tool and install it on your current QTS build. (https://download.qnap.com/QPKG/CF64_0.1-1114.qpkg.zip)

- Added support for discrete GPU cards. A GPU card can improve trascoding performance, and enables your NAS to run HD Station and Linux Station (only supported on TS-1685 and TS-x77 series NAS, but not supported on Linux Station 1.4). 

https://www.qnap.com/nl-nl/releasenotes/

 

Regards

[alucryd 216]

@@macvirii Indeed, copying files from a random distro isn't going to cut it, especially on weird NAS architectures. Unlike windows, linux actually has rules

 

@@Syvedris The next QTS isn't going to change anything, even if they did supply drm drivers, they probably won't be compatible with our libva version (the latest and greatest 2.0.0).

 

I did however build the r600 vaapi driver and will include it in our next package, hopefully it works as is on AMD models.

Edited November 3, 2017 by alucryd

[raven-au 17]

@@Syvedris The next QTS isn't going to change anything, even if they did supply drm drivers, they probably won't be compatible with our libva version (the latest and greatest 2.0.0).

 

I did however build the r600 vaapi driver and will include it in our next package, hopefully it works as is on AMD models.

 

Actually you can get away with quite a bit as long as the library entry points match.

Although there is library versioning (which I don't quite understand) that can cause problems, best idea is to match glibc versions as close as possible.

 

It looks like there's a limitation with B-frame support with the r600 vaapi driver.

But I was using an oldish version of mesa, I'll try with a newer one.